Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
PasswordEncryption
Edit
PageHistory
Diff
Info
LikePages
Encrypting passwords is an interesting subject, since you don't need to ever decrypt them, just check to see if the password you got is the password that the user entered. Under unix this is done with the crypt(3) function call, and passwords are usually stored either covered by a one way hash using DES, SHA-1 or MD5. A problem with just hashing passwords is that people can take a dictionary of commonly used passwords and hash them all, then when they get a password file[1] they can compare the passwords in the password file against their list of hashes to find common passwords. To combat this people add "salt" to their password, ie: they add a random prefix to the password when they encrypt it, and then check to see if it's the same. For example, if we're using the password __samsam__ we might add the salt of __q6__. So we hash __q6samsam__ and get __LHtEJQdGJW2__. Then we put the salt onto the beginning of this string to give us __q6LHtEJQdGJW2__, and this would go into the password file. When someone logs in we want to check to see if the password they presented is the same as in the password file, so we take the password hash in the password file __q6LHtEJQdGJW2__, remove the first two letters (q6), add them to the beginning of password that the user entered (samsam), and hash __q6samsam__ and get __LHtEJQdGJW2__, we compare this against the rest of the password hash, see that it's a match, and then let !SamJenson login. There are 4096 different possible salts under Unix, which means that while you could generate a huge password hash list, it would have to be 4096 times larger than a normal one. Nowadays, though, this is hardly a hindrance anymore. MicrosoftWindows doesn't use salts for its passwords and is more vulnerable to this kind of attack. ---- [1]: Much harder to do now that everyone has shadow files.
One page links to
PasswordEncryption
:
CryptographicHash
