Safely storing passwords
-
When we need to store passwords for user authentication, the password gets "encrypted" somehow. Typically, a block of random bytes - the "Salt" - is added to the clear text password, next comes a hash algorithm, and finally a textual representation of the bytes received from the hash function is stored. I've seen different ways of such handling: e.g. not using a Salt at all, a string concatenation of password and a textual representation of the Salt, a binary XOR. Not using a Salt at all is considered unsafe. How would you "salt" the password, and why do you prefer your method? How do you store the result in your database - as binary data, converted to hexadecimal, ...? MD5 is said to have some flaws. Do you still use it? Thanks a lot for sharing your experience.
-
When we need to store passwords for user authentication, the password gets "encrypted" somehow. Typically, a block of random bytes - the "Salt" - is added to the clear text password, next comes a hash algorithm, and finally a textual representation of the bytes received from the hash function is stored. I've seen different ways of such handling: e.g. not using a Salt at all, a string concatenation of password and a textual representation of the Salt, a binary XOR. Not using a Salt at all is considered unsafe. How would you "salt" the password, and why do you prefer your method? How do you store the result in your database - as binary data, converted to hexadecimal, ...? MD5 is said to have some flaws. Do you still use it? Thanks a lot for sharing your experience.
IMHO multiple layers of encryption give much better protection than betting everything on a single layer. In addition to character substitution, other techniques such as transposing characters' positions make the decrypter's job exponentially harder. Any salt characters improve security, as long as you can unambiguously identify the salt characters to remove them for decryption.
-
When we need to store passwords for user authentication, the password gets "encrypted" somehow. Typically, a block of random bytes - the "Salt" - is added to the clear text password, next comes a hash algorithm, and finally a textual representation of the bytes received from the hash function is stored. I've seen different ways of such handling: e.g. not using a Salt at all, a string concatenation of password and a textual representation of the Salt, a binary XOR. Not using a Salt at all is considered unsafe. How would you "salt" the password, and why do you prefer your method? How do you store the result in your database - as binary data, converted to hexadecimal, ...? MD5 is said to have some flaws. Do you still use it? Thanks a lot for sharing your experience.
MD5 is not used anymore, not a strong type of hash algorithm. You should use SHA-256 instead. Overall algorithm would depend on your application, for example if you use a captcha I would recommend only using a hash algorithm to store the passwords. But if you don't you could use salt, it is the ultimate answer to brute force attack.
-
When we need to store passwords for user authentication, the password gets "encrypted" somehow. Typically, a block of random bytes - the "Salt" - is added to the clear text password, next comes a hash algorithm, and finally a textual representation of the bytes received from the hash function is stored. I've seen different ways of such handling: e.g. not using a Salt at all, a string concatenation of password and a textual representation of the Salt, a binary XOR. Not using a Salt at all is considered unsafe. How would you "salt" the password, and why do you prefer your method? How do you store the result in your database - as binary data, converted to hexadecimal, ...? MD5 is said to have some flaws. Do you still use it? Thanks a lot for sharing your experience.
You have probably solved this by now, but since you got a recent response, I thought I woudl add my two pence worth. I tend to use the UserID as the salt - not the username, but the unique value I assign in the database table (personally, I tend to use GUIDs for these) and take an SHA hash of the combined id and password. I then store the hash as a comparison value in the DB. If you don't use some salt, then it is relatively easy to spot common passwords (they would all have the same value as a hash) and if you crack one of them (by looking at the hash for common passwords) you have access to all those accounts. For example, if 50% of your accounts have the same hash, change your password to "password" and see what hash your account has. If it matches, then you know the password for 50% of the accounts. MD5 does indeed have some problems - it is officially classed as "broken" and should not be used for new designs. What that means is that there is a way to get a valid input (not necessarily the original input, but valid) from the MD5 hash value. It isn't a real problem, but with security it is a good idea to avoid it as a result. SHA is currently unbroken, and you should use that - the .NET cryptography namespace includes SHA in several sizes.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
