I'm having trouble understanding the benefits of storing user data in a database table using salting. The process I have set up is as follows:
User creates account with username/password
A random salt is generated.
Username stored in database, password encrypted and stored, salt stored along side password.
Now when a user attempts a login, they provide their username/password and:
Finds salt in database based on username.
Encrypts cleartext password provided using salt from database.
Compares the stored password and user provided password.
This is all fine and dandy, but doesn't a hacker merely have to guess the username and password combo? As long as they can determine a username, they can retrieve the salt. Using a brute force attack they would only need to determine the correct username/password combo. The salt would be retrieved with just the username and added to the provided password in order to compare to the stored password, so whats the point of using the salt anyways? Its not like the hacker has to guess the salt value. The password they provide is automatically encrypted with the salt from the database so as long as they know the username, its just a matter of guessing the password in cleartext.
The point of the salt is to force the hacker to attack each username one at a time rather than allowing him to attack all of them at once. Because each username has a different salt, the very same password would be stored differently for it. This defeats a rainbow table attack.
Related
I've heard a unique salt only provides protection in the event that you have a lot of user credentials stored in the same location. Is there any benefit to salting on a single user application where the password is never sent to the web? Thanks!
Password hashing is used if you don't need to retrieve the original password. For example a website with a account system will hash your password when you register and save the hash of the password in a database. When you login the next time it will again hash the password you entered and compare it to the hash stored in the database. You can use salting to make it even harder to retrieve the original password.
You have a different use case. You want to retrieve the password to be able to decrypt the data that you recieve from the server. To achieve that you have a view options:
Generate a key for the user and store it in plaintext on the disk.
Don't store the password at all but let the user enter it each time he wants to access the data on the server or upload data to the server (potentially store it in memory, you should make sure to completely erease it from memory bevore the program ends).
Generate a key for the user and store on the disk like in option 1 but encrypt it with a password thats handled like the password from option 2.
The 3rd option is definitely the safest of them. You have control over the key generation so you can make sure the key has a decent size to make it impossible for the server to guess while the key is encrypted on the disk.
I have readed this article:
https://crackstation.net/hashing-security.htm
It is said that in a web application, always it is needed to hash the password in the server to ensure that the hash is correct. But if the client hash the password and sends to the server, the server what to do is hash the password, so how can the server hash the password if what it receives from the client is the hashed password?
The other doubt that I have is the basic steps that it is needed to do:
Retrieve the user's salt and hash from the database.
Prepend the salt to the given password and hash it using the same hash function.
Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.
Well, the server get the password from the client, use the salt with the password from the client, hashes it and compare with the hashed password from the database. Well, how the salt is always the same for this user and it get from the database, if a middle man get the password, can use this password and authenticate in the database, because the server will use the salt and get the same hashed password. So no matter if it is the real user or the middle man, the server allow the access.
Another option is if the server receive the hashed password, it just needs to get the hash from the database, so it avoids to hash, saving resources. Then the client instead of send the password, send the hashed password and the server compare this hashed password from the client with the hash of the database. here, a middle man can get the hashed password too and use it to authenticate. At the end, is the same that if the user send the password.
I don't see the benefit to salt and hash the password, because if a middle man attack the connection, he can authenticate in the database. So I think that the important it is to ensure that the connection is safe, and then is the same to send the password in plain text, because the connection is secure. But perhaps I don't understand something because I know that salt and hash the password it is a common practice.
The only real benefit that I see to hash the password if one attacker get access to the database, because he can not get the password from the hashed password, but if a attacker access to the database, he can get access to all the information, so I guess the less important data is the password.
For that reason I am wondering, Is it not enough with a secure connection? because if an attacker can access to the connection, then he can access to the password and can authenticate in the server. If the attacker can not get access to the connection, then why to hash the password in the server? Is waste resources to hash the password because is a hard process.
Thanks.
Hash algorithms are asymetric, which means that you can generate the hash but going from a hash to the login credentials is much harder.
Keeping the password in an unclear form in the database prevents bad-intended people who can access it to get the clear password and authenticate as the user.
Moreover, it's not by accessing the hashed password record in the database that would allow an attacker to steal the account but by accessing the server source code to determine how the password is generated and then be able to regenerate it.
Considering that firebug for example allows you to access the client source code, you don't want to perform the password generation on the client side.
PS : If you implement SSL and HTTPS, then the packets of your request are encrypted.
We need salts. When you try to login, you hash your password client-side and send the hash to the server. They compare your hash to their hash (they also still have your password in plaintext).
What if an attacker captures your hash in transit? A good hash algorithm won't let them go from the hash back to the password, but hackers can use rainbow tables... They can try tons of passwords until they find a password with the same hash.
To stop this from happening - from the attacker from finding your password - we use a random salt. We add some random stuff onto your password before we hash it so that the hash isn't the same as the hash for your password. We send the new hash along to the server with the salt in plaintext. The server adds the salt to their copy of your password and they hash it. If the hash matches what you sent them, you login.
But since the salt is always changing, an attacker will have a hard time cracking your password.
I do not understand some concepts of storing/processing passwords.
For example, our site has a public api for mobile application(iOS, Android, etc) with provided authentication.
No doubdt, we must not store raw passwords in the database and we must not send raw passwords between client and server, so we use hashes and salt.
This way, we encrypt passwords on client and send hashes to server. But, what if a "black hat" steals password hash and authenticates with it to server api?
Should I hash passwords on client, send hashes, then hash them again on server?
What is the common solution of this problem?
Great thanks in advance.
You can use SSL to protect communication channel between client and server, and send password unencryped.
Second approach - to store hashed passwords (without salt) in server, and when authenticate - get random token from server (that will expire in some minutes), calculate hash from client password and use calculated hash to encode received token. Then send encoded token to server. Server does same operation but use hash stored in database instead calculating it from password. This approach has cons - needs to store password raw or hashed without salt. Or send salt to client with token.
But, what if a "black hat" steals password hash and authenticates with it to server api?
This problem is solved by using tokens that will expire after usage.
Do a lightweight hash client side (no salt), then rehash the hash (with unique salt) server side. Store the salt and (doubly) hashed password.
The server side hash should also use something like pbkdf2 or scrypt that can perform thousands of hashing iterations to deliberately slow down the hashing process. This helps prevent brute force attacks of the hashes by slowing down the attack process.
Given a raw password
create an unique salt
append it to the raw password
brcypt / SHA512 this combination using disposable secret key that changes over time
stores the encrypted password and salt in the user table
To verify identity
append the salt to the raw password
bcrypt / SHA512 the combination verify
checks the hashed against the db hashed value
In the verify part, what if the current secret key is no longer the same?
Should I always keep a list of old key and iterate them through to verify that that old password is generated with one of the old keys? If verifier returns true, I will update the new encrypted password.
Also, how can I be sure the salt is unique per-password-per-user?
Is this all I need to do?
Any thing missing? Thanks.
Making sure the salt is unique is easy - you could just hash together the username and the time when the password was last changed.
As for encryption, that's only necessary if for some reason you want to store the user's password, not only be able to verify it. It's more common and more secure to only store a hash of the password and salt. No secret key is necessary and even if an attacker compromises the database, they will have troubling recovering passwords. The only downside is that you can't tell users their passwords, you can only reset them.
Im in the works of updating the login process of a site.
Currently, passwords are stored as md5(password), and i'd like to add a salt,
but the unsalted password is being used to identify possible frauds since they
usually uses the same password for new accounts.
20% of the traffic is from mobile devices, which don't necessarily have the same ip.
Any idea how to identify these possible frauds?
You can still add a salt, but you have to do the comparison to the existing passwords while you still have the plaintext password, i.e. you'll have to loop through the passwords table looking for duplicates (by hashing the other account's salt with the new password) at the time the account is created rather than afterwards.
I would say salting passwords is definitely a major benefit over keeping them unsalted for fraud prevention purposes. However, please use a cryptographically secure slow hashing algorithm, such as bcrypt, scrypt or pbkdf2 - not salted MD5.
But you could have your cake and eat it, why not have another table that contains previous passwords that have been used in fraud attempts? These would be hashed, but not salted and would not have any account association stored.
If a user that uses one of these passwords turns out to be non-fraudulent, you could give them a notification to change their password to something else after you have investigated.
Here's how I imagine it would work for adding new passwords to the fraudulent password list after an account is determined to be used for fraud.
Account is marked as fraudulent.
When this user next attempts to log in, and their hashed, salted password matches the hashed, salted value stored in their account record, the unsalted hashed password taken from their user input is stored in the fraudulent password list.
As the fraudulent password list could reduce the security of the accounts of upstanding users because they are stored in here unsalted, you should make "good" users change their passwords upon login if it matches any in the fraudulent password list.