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.
Related
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'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.
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.
I am researching how to implement a persistent "remember me" type cookie for a site. I was just wondering is using a GUID for a security token as secure an an md5 hash of username and password?
A GUID is more "secure", because there's no possibility of information disclosure in a random identifier. Otherwise, were the username to be known, the password could be extracted using a per-username rainbow table or a concerted attack since you did not add salt before hashing. NB: MD5 is a rather weak hash at this point.
Long story short, if you don't need to store private information in cookies for really really good reasons, don't. Use a random token instead.
So I need to be able to actually decrypt the password because some old websites don't use OAuth and I need to have some of my users have access to them through there API. Therefore one way hashing does not work for me. I have been told that the best way to store the passwords with AES and using the salted hash of the passwords as the key. How do I store all the keys and where do I store the salt? Basically how would I exactly implement this.
Thank You
If I understand you correctly you have the following situation. Users log in to your system with a username and password. Your system then needs to impersonate these users by logging into another system that you do not control using the user's username and password for that system which they have given to you.
If that is correct, then it might be reasonable to encrypt their credentials for the other websites using AES. In this case, I would not store the key used to encrypt those crendentials. The password that the user uses to access your system should be used as the key, and it should not be stored anywhere. In this way, you have a chance of protecting your users privacy (depending on the design of the rest of the system, of course).
Since you are encrypting rather than hashing, and the encryption key would be differnet for each user, salting is not necessary.
Also, I would encrypt the full credentials, not just the passwords. Your users are showing an incredible amount of trust by giving you their credentials in the first place, so I would do everything possible to justify that trust!
Your approach is essentially to use AES as a hash function but this will not allow you to decrypt the passwords (short of brute force or some yet-to-be-discovered vulnerability).
You might want to consider asymetric key encryption instead (e.g. RSA). You'll need to encrypt the passwords with the public key of each person you expect would need to decrypt it (which would include the user).