Home  »  Log   »   How to Hack Sciencedirect Password Free

How to Hack Sciencedirect Password Free

By | May 28, 2022

Generated Password

Explore

Jayson E.
Street
, …
Marcus
Carey
, in


Dissecting the Hack, 2010

Randomly Generated Passwords

One of the best practices to implement to secure your accounts is to develop randomly
generated passwords
for each account. Many people use the same passwords across multiple sites, and even if using unique and strong passwords develop a sequential habit for passwords. Today’s 1c4nhAzCh##z#burger1 can tomorrow be 1c4nhAzCh##z#burger2. If an attacker notices this trend, they can build a custom brute force password set geared for your password habits.

Obviously, creating random passwords is not for everyone. You will need to have a proper password safe in place to remember the passwords for you; it will be humanly impossible to remember your passwords at this point. Using KeePass, as described just above, is one of the best solutions for this. Inside KeePass is a random password generator, as shown in
Figure 3.12. You can set the various strength requirements of your password and even use entropic seeding (random keyboard presses or mouse movements) to improve its security.


FIGURE 3.12.
KeePass Password Generator



Register an account onto a Web site, and when it asks for your password, note the password requirements. Enter them into the KeePass password generator to get your new password, then copy and paste it to the Web site to complete the registration and store the password into your password vault.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597495684000031

The Nessus User Community

Russ
Rogers
, in


Nessus Network Auditing (Second Edition), 2008

Creating and Logging In to a Bugzilla Account

While you can query Bugzilla anonymously, you must log in to a Bugzilla account to report a new bug or update an existing one. To create an account, visit
bugs.nessus.org/createaccount.cgi
and enter your e-mail address (see
Figure 12.7).


Figure 12.7.
Bugzilla Account Creation




Bugzilla will create the account and send you an e-mail with your login name (typically your e-mail address) and a randomly
generated password. After this, you can change your account password or preferences using the form at

http://bugs.nessus.org/userprefs.cgi.

NOTE

As currently configured,
bugs.nessus.org
does not accept Web traffic encrypted with SSL. Exercise care if you decide to change your Bugzilla account password.

To log in to your Bugzilla account, visit
bugs.nessus.org/query.cgi?GoAheadAndLogIn=1
or click on the
Log In
action at the bottom of any of Bug Tracker’s pages. Bugzilla uses cookies for authentication, so make sure your browser is configured to accept them, at least from
bugs.nessus.org. Enter your e-mail address (or account name, if different) and password, and then click
Login. (If you have forgotten your password, you can fill out a form in the middle of the page to submit a Change Password Request.) Once you’ve authenticated, Bugzilla will display the general query page.

Tools & Traps…

Cookies

By default, the cookies that Bugzilla uses for authentication last, for all practical purposes, indefinitely; even across machine reboots. This can be a problem when accessing Bugzilla from a shared machine. To have a browser forget those cookies, visit
bugs.nessus.org/relogin.cgi
or click on the
Log out
action at the base of any of Bug Tracker’s pages. This link appears only if you’re actually logged in.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492089000125

DNA-based authentication to access internet of things-based healthcare data

Sreeja
Cherillath Sukumaran
, in


Recent Trends in Computational Intelligence Enabled Research, 2021

5.4.1

Password file compromise attack

In the proposed method, computing the hash value of passphrase along with other additional credentials

ensures protection from password file compromise attack as the attacker will not be able to retrieve the password from the hash value. OTP generated for device authentication also enhances security. The DNA sequence method for stegonagraphy also plays a vital role in resisting password file compromise attacks.

Algorithm 1A: Registration Phase for the User

UR1: Registration request to the AS by the U.

UR2: AS displays the registration interface to U.

UR3: U has to set the information for registration including user ID (IDU), mobile number UID, a healthcare ID which is a unique ID such as National ID of the user.

UR4: U selects Password, pwdU.

UR5: Applying DNA coding method for DNA sequence enhances security. AS selects the DNA coding as the default method given in
Table 5.1. U can customize the sequence values for additional security. However, in this case, U should recollect the assigned values as an additional credential. U can also select the option for receiving OTP during authentication.

UR6: For U, AS selects a DNA SeqU
from the digital database.

UR7: Depending on the credentials U has nominated throughout the registration, AS computes the key:

 
 
 
 
Key= HASH [Stego DNA [U]] where,

Steg DNA [U]=[Encoded [binary [pwdU
+ DNA seqU]]] injected into the DNA SeqU.

UR8: U completes the registration and AS notifies U regarding the same.

Algorithm 1B: Registration Phase for the Medical Device

MDR1: The medical device (MDU) for the user U should be registered with the AS using the electronic product code of the device MDEPC

MDR2: AS computes h(MDEPC)|| h(UID) and stores the value in the device details table and the registration of MDU
is successful.

Algorithm 2A: Authentication Phase

L1: U enters username—IDU.

L2: If IDU
is valid, the system displays an interface to enter UID.

L3: If it is valid, U can enter the pwdU
else go to L1.

L4: If U had selected UR5 during registration. U has to enter the binary code sequence for DNA after entering pwdU
otherwise U can proceed to L5.

L5: Based on the IDU, UID, and pwdU.
AS picks the DNA seqU
from the database and performs DNA steganography.

L6: DNA steganography(DNAs)=Encodes[code[pwdU
→ DNA] → DNA seqU].

L7: Computes h(DNAs), using a secure hash algorithm (SHA-256) and hash value will be collated against the hash value generated in the registration process. If both values match, then the authentication is granted for the user U, otherwise access will be denied.

Algorithm 2B: Authentication Phase of Medical Device (MDU)

L1: After successful user authentication AS sends an OTP to the U.

L2: Ur enters the OTP into the MDU
and the AS validates the OTP and upon successful authentication, the session is established.

Algorithm 3: Password Change Phase

PC1: U enters—IDU.

PC2: If IDU
is valid, one system produces an interface for UID.

PC3: If UID is effective, correct U can enter the pwdU
else go to P1. If the user forgets pwdU, it can be recovered using the registered mobile number or email ID.

PC4: Depending on IDU, UID, and pwdU. AS preferences the DNA seqU
from the database and performs DNA steganography.

PC5: DNA steganography (DNAs)=Encodes[code[pwdU
→ DNA] → DNA seqU].

PC6: Computes h(DNAs). Computes using a secure hash algorithm. The hash value will be compared against the hash value generated and stored during registration. If both values match, then the authentication is granted for the user U otherwise access will be denied.

PC7: After a successful process, the user can generate a new password pwdU1.

PC8: After setting pwdU1, AS performs operations defined as per PC5 and P6 and stores the newly generated hash value (Fig. 5.3).


Figure 5.3.
Proposed architecture.



Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128228449000086

Data Hiding Using Encryption Techniques

Nihad Ahmad
Hassan
,
Rami
Hijazi
, in


Data Hiding Techniques in Windows OS, 2017

Password Generation Tools

There are many free services and tools that offer secure password generation services, although such services are very secure and produce passwords that are almost impossible to crack. We recommend not using such services for your top-secret password (like bank account or your PC encryption passphrase); in this case we recommend following our guide for creating a secure password created by using a human brain (your brain in this case), which remains the best secure and unpredictable technique that no automated machine can crack.

Norton Identity Safe Password Generator

This tool creates highly secure passwords that are difficult to crack or guess. Just select the criteria for the passwords you need, and click
Generate Password(s)
(https://identitysafe.norton.com/password-generator).

Strong Password Generator

This offers a free service for generating secure passwords. The new
generated password
is generated on the user’s browser and does not travel across the Internet to reach the user’s computer (

http://strongpasswordgenerator.com).

RANDOM.ORG

The passwords generated by this service are transmitted to your browser securely (via SSL) and are not stored on the
RANDOM.ORG
server. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs (https://www.random.org/passwords).

PWGen

PWGen
is a professional password generator capable of generating large amounts of cryptographically-secure passwords:
classical
passwords, pronounceable passwords, pattern-based passwords, and passphrases consisting of words from word lists. It uses a
random pool
technique based on strong cryptography to generate random data from indeterminate user inputs (keystrokes, mouse handling) and volatile system parameters.
PWGen
provides lots of options to customize passwords to the users’ various needs.

You can download this software from
http://pwgen-win.sourceforge.net/downloads.html.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128044490000051

Samhain

In

Host Integrity Monitoring Using Osiris and Samhain, 2005

Pairing Agents with the Yule Server

Now that you have built a network-aware Samhain agent, you need to establish trust between that Samhain agent and the Yule server. To accomplish this, embed a shared key (password) into the agent executable, and then register that key with the Yule server. The
yule
executable is used to generate new passwords, and then a utility named
samhain_setpwd

embeds that password into the Samhain agent executable. Finally, the Yule configuration file is updated with a string that contains the
generated password
so that it can be used to authenticate communications with that particular agent. This process must be done for every host communicating with the Yule server.

On the Yule server, generate a random password:

Your password should be different. Next, generate a configuration file entry for this agent, using the generated password as input (again, your output should vary):

This output must be placed into the configuration file with
HOSTNAME
replaced by the hostname for this agent. You can add this to the configuration file directly, or you can generate the password, replace the hostname, and add this data to the configuration file automatically with the following command:

You have to replace
example.com
with a hostname or IP address for the agent you are configuring. Verify that the correct information was added to the
yulerc
file:

Now, you need to update the Samhain agent executable. On the host where you just installed the Samhain agent, navigate to the Samhain source code; the samhain_setpwd executable should be in the root of the source tree. This executable takes a “samhain” executable and a password as input and then outputs that same executable with the password replaced. By default, the password is arbitrary. The password must be generated in the preceding Yule server, as shown previously. Reset the password with the following commands:

This command leaves
/usr/local/sbin/samhain
unmodified and creates
/usr/local/sbin/samhain.new. Your output will vary with respect to the password, but the results should be similar. Now, replace the old
samhain
executable with the new one:

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597490184500149

A Novel Infrastructure for Synergistic Dataflow Research, Development, Education, and Deployment: The Maxeler AppGallery Project

Nemanja
Trifunovic
, …
Ali R.
Hurson
, in


Advances in Computers, 2017

8

Defining the AppGallery Processes

There are seven different processes that can be executed using the AppGallery website:

1.

User Registration Process;

2.

PI Registration Process;

3.

Developer Registration Process;

4.

Developer Approval Process;

5.

User & PI Approval Process;

6.

App Submission Process;

7.

App Review Process.

The rest of this section will provide a detailed explanation of each one of the seven different AppGallery processes. For each process, there is a list of actions or steps that need to be performed for successful execution. Every step of process execution will be explained in detail.

8.1

User Registration Process

Anyone can send a request to become a Registered User by filling out a form on the user registration page, as shown in
Fig. 27.

Fig. 27.


Fig. 27.
Screenshot of the User Registration page. Fields marked with
asterisk
(*) are obligatory (http://appgallery.maxeler.com/#/userRegister).



Once the registration request is submitted, the UA is notified about the pending registration and can approve or decline the request. When the UA finishes processing the request, the user receives an email with an automatically
generated password, as shown in

Fig. 28, which can be used by the user to log onto the AppGallery website.

Fig. 28.


Fig. 28.
Screenshot of the received email confirming AppGallery registration approval of the user John Doe. The user is provided with an automatically generated password that he could change during their first log-in.



8.2

PI Registration Process

In order to register, the PI needs to send an email to the UA requesting to register as a PI. The UA responds by sending an email with the link to the PI registration page. After this, the PI fills in the PI registration form, as shown in
Fig. 29.

Fig. 29.


Fig. 29.
Screenshot of the PI Registration Page. Fields marked with
asterisk
(*) are obligatory. (URL: The link to the PI registration form is not shown on the AppGallery website, the link to the PI registration form is sent by User Administrator. The link to be sent:
http://appgallery.maxeler.com/#/PIregistration.)



The UA is then notified that there is a PI registration request to be reviewed. When the UA approves the request for the PI account creation, the PI receives an email with an automatically
generated password
and a link where developers can register. The PI’s Administrator (PI-A) is automatically created and the PI needs to fill in information about the PI-A email address.

8.3

Developer Registration Process

In order for developers to register they first have to receive the registration link from their PI or PI-A. On this link, the developer has to fill in an online developer registration form, as shown in
Fig. 30.

Fig. 30.


Fig. 30.
Screenshot of the Developer Registration page. Fields marked with
asterisk
(*) are obligatory. (URL: No static link; developer gets the registration link from their PI or PI-A.)



Once this has been finished, the PI or PI-A is notified about the registration and can approve the request. When the PI or PI-A finishes processing the request, the developer receives an email with an automatically
generated password
which can be used to log into the AppGallery.

8.4

Developer Approval Process

The PI or PI-A can see the list of pending developers with all details about a new user and approve or decline their registration request, based on those details.

The PI and PI-A have a possibility to approve or decline more than one developer at once, as shown in
Fig. 31. To approve or decline more than one developer at a time, select all desired developers for Approval/Decline and click on the Approve or Decline button. A pop-up will show how many developers have been selected for approval, how many for decline, and ask for confirmation. Once confirmed, all the selected developers will be Approved/Declined.

Fig. 31.


Fig. 31.
Screenshot of the Developer Approval Page (URL: different for each PI;
http://appgallery.maxeler.com/#/user/<PI>/myDevelopers).



8.5

User & PI Approval Process

User administrator can look through the list of pending users and PIs, as shown in
Fig. 32. By clicking on the “View signature” button, next to the PIs, the administrator can see: (1) signatory name; (2) signatory role; and (3) download scanned letter of intent for the current user.

Fig. 32.


Fig. 32.
Screenshot of the User & PI Approval page (URL: depends on the user admin;
http://appgallery.maxeler.com/#/userAdmin/<useradmin>/MAXusers).



The user administrator can select which users are for approval and which are for decline, and when ready can approve or decline them by clicking on the Approve/Decline button. Once the Approve/Decline button has been clicked, a modal pop-up appears with a question to confirm this decision and after clicking OK, users/PIs are approved/declined.

8.6

App Submission Process

In order for an app to be submitted, it needs to have a unique name and a form for uploading application has to be filled out. The form consists of (1) the upload icon, (2) description and additional info, and (3) documentation and archive, as shown in
Fig. 33.

Fig. 33.


Fig. 33.
Screenshot of the app Submission page.



Again, issues related to extensibility and scalability are given top priority.

At any moment, the developer can save the current work and finish the application creation at any time by clicking on the
SAVE
button, as shown in
Fig. 33.

Once the developer finishes filling in the app submission form, the application can be published, as shown in
Fig. 34.

Fig. 34.


Fig. 34.
Screenshot of the app Submission page, publish confirmation.



8.7

App Review Process

Content administrator can see a list of pending applications with a short description of every application. By clicking on the application icon, a modal pop-up appears with further application details and an Accept/Decline option, as shown in
Figs. 35 and 36.

Fig. 35.


Fig. 35.
Screenshot of the MAX Applications page.



Fig. 36.


Fig. 36.
Screenshot of the MAX Applications page, click on the app.



If the CA decides to decline the application, he/she can write feedback to the developer where he/she could state reasons for declining the application and possible improvements to the application, as shown in
Fig. 36. After clicking on the Accept/Decline button in the modal, the modal will close and this application will be checked on the list for decline/approval. Finally, the CA can approve/decline all the processed applications by clicking on the Approve/Decline button. After clicking on the Approve/Decline button, the CA would be asked to confirm his/her decision. Once confirmed, all the applications selected for approval will be accepted and the ones selected for decline will be declined.

In case that the application has been declined, the developer receives an email saying that his/her application has been declined and that he/she has to log in to see more information. The developer goes to My Applications page, enters the application that has been declined, and then he/she can see content administrator feedback as shown in the screenshot. If the application is approved, it becomes visible on the homepage and on the author profile page.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/S0065245817300177

Data in the Cloud

Aaron
Wheeler
,
Michael
Winburn
, in


Cloud Storage Security, 2015

1.3.2

Case Studies: Comparison of Cloud Storage Security

We now compare security features for a number of cloud storage providers.
Table 1.1
does not provide a complete list or an endorsement. Instead, we want to indicate the range and availability of some important security features.


Table 1.1.
Selected Security and Privacy Features of Free Cloud Storage Providers


Provider Two factor EV for HTTPS Encryption Zero Knowledge Compliance Data Centers
Amazon Cloud Drive
https://www.amazon.com/clouddrive
no no no no Safe Harbor
Box
https://www.box.com/
yes no AES-256 no Safe Harbor, APEC
Copy
https://www.copy.com/
no no AES-256 no
Dropbox
https://www.dropbox.com/
yes yes AES-256 no Safe Harbor
Google Drive
http://www.google.com/drive/
yes useless no no Safe Harbor
iCloud
https://www.icloud.com/
yes yes AES-128
 
min
no
OneDrive
https://onedrive.live.com/
yes yes no no
Mega
https://mega.co.nz/
no no AES-128 yes Safe Harbor EU, NZ
SpiderOak
https://spideroak.com/
yes no AES-256 yes
a,b
Safe Harbor, HIPAA capable
Tresorit
https://tresorit.com/
yes yes AES-256 yes Safe Harbor EU
Wuala
https://www.wuala.com/
no no AES-256 yes
a
Swiss DPA/DPO Switzerland, Germany, France
a
Shared files get decrypted on their servers.
b
Zero-knowledge encryption via client application.

The cloud storage providers we compare all have some amount of free (non-trial) storage, and we compare their security on these plans. Note that in some cases, paid plans will have additional security options.

We compare security based on the criteria of two-factor authentication, Extended Validation (EV) certificates, encryption strength, zero-knowledge encryption, regulatory compliance, and location of data centers. We do not delve in to the details of how individual providers maintain security in their data centers.

Two-step or two-factor authentication requires the user to enter two pieces of information to login, a password and a one-time passcode sent to the user by text, email, or retrieved by the user with an app. As a variation on this method, the Google Authenticator App has users store a shared secret from the website on their device. To log in to the site, users must provide their username, password, and a one-time password generated by the app.

In addition to the above two-factor authentication strategies, Google will optionally remember your computer and use it as the passcode. Google Chrome also supports USB security keys for two-step verification. Once you register this key with your Google account, it unlocks your account similarly to a house key that unlocks your house, after you provide your username and password.

Extended Validation (EV) certificates provide an extra level of security that verifies you have no one intercepting your data while in motion between you and your cloud storage. Note that Google probably does
use EV certificates, but their infrastructure prevents browsers from providing confirmation to users that they have a secure connection with Google. This makes Google EV useless for privacy and security from the user’s perspective with respect to independent confirmation from a CA.

Encryption strength describes the algorithm used to encrypt your data. NIST recommends AES-256. Server-side encryption may use convergent encryption. This approach uses a cryptographic hash of the unencrypted file as the encryption key. The hash itself gets encrypted with the user password. This results in the same file always having the same encrypted form. Cloud storage providers use this technique for data de-duplication because the same file only gets stored once. However, it means a third party can check if you have a file by following the same procedure on their own file. If their encrypted file matches yours, then they know you have the file.

Zero-knowledge encryption means the cloud storage provider does not have the ability to decrypt your data. Data encryption occurs on the client, then gets sent via a secure connection to the provider. This protects your data in transit and at the provider’s data centers. Since only you have the decryption key, your data cannot get decrypted without your knowledge (unless someone guesses or steals from you your decryption key!). Zero-knowledge encryption protects cloud storage providers too, because they have no way to know the content of the files they store and this makes them less vulnerable to legal issues.

However, zero-knowledge encryption does not always apply to shared data. Some cloud storage providers who advertise zero-knowledge encryption break this promise for file sharing. To share your files, these providers might get your decryption key and decrypt your file on their servers and distribute it in cleartext to those who you shared it with. Finally, providers may only offer zero-knowledge encryption when using their client application and not when using a browser interface.

Participation in regulatory compliance provides evidence for a commitment to privacy and data security. Many standards exist for data privacy and security. Here we consider only the ones most commonly offered in free cloud storage accounts.

Safe Harbor compliance indicates that the cloud storage provider meets the data privacy and security requirements of the EU Data
Protection Directive. The Swiss Data Protection Act (DPA) and Data Protection Ordinance (DPO) have more strict data privacy and security requirements. The Asia-Pacific Economic Cooperation (APEC) has its own standards for data exchanged between its member countries. The Health Insurance Portability and Accountability Act (HIPAA) specifies how cloud storage providers should secure personal health data. Note that many cloud storage providers do offer guarantees of regulatory compliance in paid plans.

We include data center locations in our security comparison because laws regarding privacy and security can vary significantly from country to country. Storing your data in the cloud in your country could put your data under the jurisdiction of another country. We prefer that cloud storage providers give their customers a readily accessible and exhaustive list of the countries with their data centers. You cannot assume that a provider based in your country has data centers only in your country. Often they will lease space with global data centers, so your data could physically reside anywhere in the world. Data privacy and security protections you expect in your country might not apply in countries where your provider stores it.

We looked to the cloud storage provider websites for security information for our evaluation. Our failure to identify privacy and security features does not mean they do not exist. However, we suggest caution when considering cloud storage from providers who do not clearly and obviously state useful details about how they protect your privacy and data security.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128029305000010

Authentication Systems

Christophe
Kiennert
, …
Pascal
Thoniel
, in


Digital Identity Management, 2015

3.2.3

OTP authentication systems

Many systems have now abandoned static password authentication systems in favor of dynamic OTPs. As the name suggests, the OTP method consists of submitting a password, which is only valid once and at a specified time, for authentication.

The user does not therefore choose his or her own password, which generally consists of a pseudorandom sequence, the length of which varies depending on the implementation. The fact that the password is only valid at a given time and does not allow for errors (if an error occurs, another password is required) constitutes a defense against brute force or dictionary attacks, social engineering attacks and phishing. Consequently, an OTP may often be a simple sequence of four or five characters. In addition to being unique, an OTP must also be unpredictable: knowledge of previous OTPs should not allow an attacker to deduce future OTPs.

A range of approaches have been developed for authentication systems using OTPs. In this section, we shall describe a number of these implementations in order to show the variety of possible techniques.

3.2.3.1

The S/KEY protocol

The algorithms used to guarantee the random and unpredictable character of OTPs are somewhat varied. As noted in [ELD 11], the idea of calculating OTPs was first developed by Leslie Lamport in the 1980s, using a one-way function
f, for example a hashing function. The basic principle, as used in the S/KEY [RFC 92b] system, for example, is the successive iteration,
n
times, of function
f
on a seed
s, which constitutes the original secret created by the client and is never transmitted to the server. If an attacker possesses
s, the whole protocol will be compromised.

Once the iterations have been carried out, secret
s
is eliminated, and
fn
(s) is transmitted to the server for reference. The list {f

n 

1
(s),
f

n 

2
(s), …,
f(s)} therefore constitutes an ordered OTP list for the user. Sending
f

n 

1
(s) to the server allows client authentication, as the server can apply
f
to compare the received value to the stored reference value. Following authentication, the server uses
f

n 

1
(s) for reference, and the user must then use
f

n 

2
(s) for authentication, and so on. The principle of the S/KEY protocol is shown in
Figure 3.6.


Figure 3.6.
The S/KEY protocol



The fact that
f
is a one-way function theoretically makes it impossible for an attacker to retrieve the user’s OTP list using passive eavesdropping. However, the S/KEY protocol uses 64-bit hashes, which, nowadays, are too small to prevent space-time trade-off attacks, used to precalculate a set of values in order to speed up the search for
f

i 

 
2
(s) based on
f

i 

 
1
(s).

3.2.3.2

Hardware OTPs

OTPs a currently most widely used for two-factor authentication, i.e. in addition to another authentication factor. Protocols such as S/KEY, where a user may be identified by simply supplying a correct OTP, are no longer particularly popular.

Two-factor authentication using an OTP can take a number of forms, but the most widely (and almost exclusively) used versions involve a combination of “what the user knows” and “what the user has”. Generally, “what the user possesses” is a hardware element, such as an RSA SecurID token, and “what the user knows” is the OTP generated by the token, generally in addition to a token-specific Personal Identification Number (PIN) held by the user.

OTP calculation generally involves a time stamp, deduced from synchronization with the server. The user obtains an OTP that is only valid for a short period, between 30
 
sec and 1
 
min. All tokens must be initialized with a different seed in order to prevent multiple tokens producing the same OTP for the same time period.

The use of dedicated equipment with physical and logical countermeasures means that hardware OTPs offer an additional layer of protection during authentication. The limited validity period for an OTP also invalidates phishing or replay attacks. However, this also imposes constraints on the user, first in financial terms, due to the cost of hardware, and in practical terms, as authentication will not be possible if the user forgets or loses their token.

3.2.3.3

Coding tables

Another manner of using two-factor authentication is to reverse the role played by the OTP, which becomes the “possession” element. This implies the possession of an OTP matrix, in material or logical form, used for authentication. Certain banks use systems of this type, sending paper
matrices (containing random values) to clients to enable additional authentication for sensitive operations, such as money transfers.

This is a challenge-response-type system: the server requests the OTP stored in a certain place in the matrix, and the client must supply this OTP, which will not be requested again. Clearly, this system is too weak to be used alone; in the case of banks, it is used to supplement a classic password authentication system (using encryption, through a TLS tunnel pre-established by the server).

NTX Research has developed a full solution using this paradigm, which is known as “coding tables”. The principle involves creating two OTP matrices for each user, provided to the client and the server, respectively. These matrices are different, but compatible: all OTPs in one matrix must be found somewhere in the other matrix. There is thus a specific shift between the two matrices, deduced using a secret client code and a secret server code. These secret codes may be relatively simple, making them easy to memorize, and are never stored in physical form. Their sole purpose is to initialize the matrices correctly, i.e. with the correct shift.

For example, let us consider a case where a server requests the OTP from square A8. The client enters their secret code. The returned OTP is taken from square B9 (no longer A8) as the secret code has created a (+
 
1, +
 
1) shift for the whole of the matrix. The server has a password that creates a (+
 
2, +
 
2) shift for its matrix, and compares the value sent by the client to that stored in square C10 (and not A8) of its matrix. If the two match, this shows that the client has the correct OTP matrix and knows the secret code required to use the matrix. This constitutes a form of two-factor authentication. The principle of coding tables, implemented for ZigBee sensors, was illustrated by Redjedal
et al.
[RED 11].

This solution offers a number of advantages, notably the fact that theft of the OTP matrix is not sufficient to enable an attacker to use it correctly, and the that the server does not know secret user codes. Moreover, as the secret code is never stored or transmitted across the network, it is difficult to retrieve. However, a dictionary attack would be possible for short passwords (as the secret codes used are designed to be memorable); this may be blocked at server level by blocking a client account after a given number of unsuccessful authentication attempts. However, this type of countermeasure
is never truly satisfactory, as the client loses access to their account for a time and is still therefore a victim of the attack.

Moreover, we need to guarantee that the shift used by the client matrix (generally a transposition algorithm that changes the order of characters in the matrix) cannot be deduced from a sufficient number of passive observations of challenge-response exchanges by an attacker in possession of the matrix. Finally, this solution, like all those discussed above, is entirely vulnerable to MITM attacks.

3.2.3.4

Vulnerability of OTP methods to man-in-the-middle attacks

We have not yet touched on the vulnerability of OTPs to MITM attacks, which presents a significant problem. The possibility of MITM attacks represents the main stumbling block for OTP system models, independently of the algorithms or design choices involved.

The principle behind MITM attacks was discussed in
section 3.1.3.2. Readers should note that this type of attack is one of the hardest to eliminate from a theoretical perspective, as it is all too easy to neglect a parameter which an attacker may use to mount an MITM attack. This attack type was not discussed in the case of static password protocols, where it can, clearly, be used for the simple reason that the countermeasures implemented in this case can be overcome using far more modest means. This is not the case for OTP methods, where phishing, eavesdropping and dictionary attacks are generally unsuccessful. This represents a considerable achievement in security terms, and should be considered as such. In this context, an attacker must use a password as soon as it is obtained, as the data lose all interest at the end of a brief fixed period of time.

In this case, MITM-type attacks exploit the lack of mutual authentication between the client and the server. The client cannot be certain of sending the OTP to the server, and this information can be intercepted by an attacker, who then relays it to the server in the victim’s name. As this type of attack can be carried out in real time, the short validity period of OTPs is of no consequence for the attacker.

One possible countermeasure consists of requiring preliminary authentication of the server by the client, for example using the TLS protocol. However, we should remember that for the purposes of online
authentication, the HTTPS protocol is used; this protocol is also vulnerable to MITM attacks, as seen in
section 3.2.5.3.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781785480041500031

User Accounts and Security

Martin
Moore
,
Steven
Hancock
, in


Tru64 UNIX Troubleshooting, 2003

4.1.2

Password Problems

Apart from users forgetting their passwords—a problem that system administrators can’t do much about—the main types of password-related problems are the following:

Inability to change passwords

Ineffectiveness (the password-change operation seems to work, but the password doesn’t really change)

Corruption of the hashed password database

Missing or corrupted password file

Lost or forgotten root password

We’ll discuss each of these areas in turn in the following subsections.

4.1.2.1

Inability To Change Passwords

Under normal circumstances, nonprivileged users can change their own passwords, while the superuser can change any user’s password. (Using enhanced security, it’s also possible to deny users the ability to change their own passwords.) Some problems in this area affect both root and nonroot users, whereas others affect only nonroot users.

The most common cause of inability to change passwords is the existence of a lock on the password file. This situation produces the error message “password file busy—try again.” In most cases, this is a temporary error caused by other users changing their passwords, default shell, or finger information. It can also be caused by a system administrator performing account maintenance, as described in
section 4.1.4. If this error persists for more than a short time, use ps(1) to list the current processes on the system and check for commands likely to open the password file, such as passwd,
chfn, and chsh. If this doesn’t help, another possibility is to use the fuser(8) command as described in
section 4.1.1.2.

Nonprivileged users will be unable to change local (non-NIS) passwords if the passwd(1) command has the wrong ownership or permissions. The correct values are shown in the following:

The same problem can occur when using dxchpwd(1X), the GUI for changing passwords under Enhanced security. The correct values for this program are as follows:

Under Enhanced security, a user’s ability to change passwords may be restricted or even eliminated. One possible restriction is to specify a minimum time between password changes. This is to prevent users from defeating the password expiration feature by rapidly changing passwords enough times to fill up their password history and then returning to the original password. If a user attempts to change passwords before the minimum time has elapsed, the result is an informative error message:

Enhanced security can also be configured to prevent users from choosing their own passwords. In this case, users must accept system-generated passwords, which can be configured for various options (pronounceable pseudowords, random letters, or random alphanumeric characters). Restrictions can also be placed on user-selected passwords. These restrictions include defining the minimum and maximum length as well as checking for “trivial” passwords: palindromes, login names, group names, and all words defined by the spell(1) program. An additional site-specific password policy (e.g., requiring passwords to include at least two numbers and three letters) can also be used. Attempting to select a password that violates any of these format restrictions will result in an error message that explains why the

password isn’t a valid choice. The “solution” in this case is to have the user choose a password that satisfies the local password requirements.

4.1.2.2

Ineffective Password Changes

Occasionally, users will attempt to change passwords and appear to succeed. However, the new password doesn’t work. Experimentation shows that the user’s old password is still in effect. This is almost always caused by a failure to update the hashed password database. This database consists of two files—/etc/passwd.pag and /etc/passwd.dir—that organize the information in /etc/passwd into a more efficient format for searching by system routines. Without the hashed password database, the system must perform a sequential search of the password file. This can lead to significant performance degradation on systems with a large number of users.

Utilities such as dxaccounts, vipw, passwd, and usermod normally recreate the hashed database to reflect the updated password file. (However, editing /etc/passwd with vi does not.) But if the modification time on /etc/passwd.pag is in the future, the hashed database appears to be current and is not updated. System routines will continue to use the old information in the database, making it appear that the change did not take. Also, if the hashed database is corrupted, it may not be updated properly, leading to similar symptoms.

If a password change appears to be ineffective, try removing the hashed database files (/etc/passwd.pag and /etc/passwd.dir) temporarily. Try the new password again; if it works, this verifies that the hashed database was the cause of the problem. You can then recreate the hashed database with the following commands:

After recreating the database, verify that the new password continues to work.

4.1.2.3

Password Database Corruption

As noted in the previous section, corruption of the hashed password database (or an incorrect timestamp on it) can cause password changes to appear to be ineffective. This is also true of other account maintenance tasks; if the hashed database is not updated properly, the change may not appear to have
worked. The remedy for this type of problem is the one given in the previous section: recreate the hashed password database.

It’s important to note that corruption of the hashed password database can have other, more far-reaching effects. Because the hashed database is used to translate user names to UIDs, corruption can cause files to appear to belong to the wrong user, or just to a numeric UID. In a worst-case scenario, root may not be properly identified as UID 0. This will cause root to lose its ability to perform privileged functions—among them, removing and recreating the hashed database. In such cases, it may be necessary to boot the system from an alternative disk or installation CD-ROM, mount the normal root file system on /mnt, and remove the hashed database files in the /mnt/etc directory.

4.1.2.4

Missing or Corrupted Password File

The previous section discussed corruption of the hashed password database. What about corruption of the password file itself? An incorrect password file entry can cause a wide variety of errors. Fortunately, Tru64 UNIX includes three utilities to verify the integrity of user account information. The pwck(8) and grpck(8) utilities check the password and group files, respectively, while authck(8) checks the enhanced security authentication database. For example, pwck checks each entry in the password file for the proper number of fields; verifies that the user name, UID, and GID are valid; and checks for the existence of the user’s home directory and default shell. These utilities can be extremely helpful in tracking down user login problems. It’s also a good idea to run them periodically as part of regular system maintenance.

If the password file is missing or the root entry is corrupt, the situation is more serious. When this happens, it is necessary to boot the system from another disk or an installation CD-ROM, mount the root file system on /mnt, and restore the password file from backups. If a good recent backup is not available, /etc/.new..passwd contains a bare-bones password file with a null password for the root account. This file can be copied to /mnt/etc/passwd, after which you can boot to single-user mode from the regular boot disk. At this point you can change the root password and, if necessary, recreate other user accounts.

4.1.2.5

Lost or Forgotten Root Password

If the root password is forgotten or lost, the only recourse is to break into the system and reset the root password. This requires access to the system
console and the ability to halt and reboot the system to single-user mode. It is necessary to halt the system because only the superuser can gracefully shut down the system, and in this situation, the root account is inaccessible. If the system is in secure console mode, the process of breaking in becomes more difficult. Secure console mode requires the root password to be entered when the system enters single-user mode. Because the root password is unknown, you can’t just boot to single-user mode and change the password. In this case, it’s necessary to boot from another device, such as a Tru64 UNIX Installation CD-ROM, mount the normal root file system, disable secure console mode, and then boot (from the regular root disk) to single-user mode.

The procedure to reset the root password is as follows:

1.

Halt the system, either by pressing the HALT button or, on some system types, typing the Control-P (^P) key combination from the console. This brings the system to the console prompt, which is usually something like “>>>.”

2.

If the system console is secured with a password, enter the console password:

3.

If you know that the system is not in secure console mode, proceed to step 10. If you’re not sure, go ahead and proceed to step 10 anyway; if you get a password prompt when the system reaches single-user mode, you’ll know that the system is in secure console mode, and you can then return to step 4.

4.

Insert a Tru64 UNIX Installation CD-ROM in the CD-ROM drive and boot the system from that device. Substitute the appropriate device name for DKA400 in the following command:

5.

When the installation software starts up, exit to a shell window. If you are using a serial terminal as the console, select option 3 (Exit
Installation). If you are using a graphics console, pull down the File menu and select Shell Window.

6.

Mount your root file system. If the root file system type is UFS, enter the following command (substitute the appropriate device name for dskla):

7.

If the root filesystem type is AdvFS, you may need to create a temporary domain subdirectory and link it to the appropriate device. (If the installation process has already created the directory and device name link shown below, just skip those steps.) Again, substitute the appropriate device name for dskla:

8.

Edit the rc.config file on the root filesystem and change the value of the SECURE_CONSOLE setting to NO. If there is no SECURE_CONSOLE definition in /mnt/etc/rc.config, add the following line:

9.

Unmount the root filesystem and halt the system to return control to the console:

10.

Boot the system to single-user mode:

11.

When the system reaches single-user mode, mount the local file systems:

12.

Change the root password:

13.

Resume booting the system to multiuser mode by typing the Control-D (^D) key combination.

14.

Log in as root using the newly changed password to verify success.

15.

If you changed the value of SECURE_CONSOLE in step 8, change it back to YES if you wish to continue using secure console mode.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781555582746500052

Usability, security and trust in password managers: A quest for user-centric properties and features

Sunil
Chaudhary
, …
Eleni
Berki
, in


Computer Science Review, 2019

4.5.2

Design a useable password generator

Several PMs are equipped with a password generator, which saves users from creating passwords on their own for the various services they use. However, the problems with password generators are: (i) they are complex to use[42]; (ii) they generate passwords that may be incompatible with a website’s password requirements[71]; and (iii) passwords generated by them are cognitively challenging and, thus, almost impossible for users to memorise[72]. Furthermore, different websites have different requirements for the length and character sets permitted for use in passwords[72]
. Even different organisations can have their own policies and criteria for generating passwords. The incompatibility between
generated passwords
and organisations’ practices can prevent users from using the password generator.

To overcome these limitations, Stobert and Biddle[71]
suggested allowing the users to define and select an appropriate rule-set to generate password(s) for each website. For example, LastPass[73]
allows users to select password rule-sets. The disadvantage of this approach is that users can cause problems by selecting the simplest combination, thus reducing the strength of the password. Therefore, it is important to provide continuous constructive feedback during the password generation process and to incorporate explanations on why an apparently weak password is rejected or is insecure[20]. Such feedback on the password’s strength/weakness can make the system transparent and can also refresh the users’ knowledge of password design and choice procedures.

Read full article

URL:

https://www.sciencedirect.com/science/article/pii/S1574013718302533

How to Hack Sciencedirect Password Free

Source: https://www.sciencedirect.com/topics/computer-science/generated-password

Popular:   Uw Health My Chart Login Page