Encrypted passwords (crypt)

Posted by Zeno on Tue 09 Mar 2004 11:42 PM — 9 posts, 25,697 views.

Zeno USA Tue 09 Mar 2004 11:42 PM #0

I don't know much about crypt, so here it goes. Why does crypt not generate a unique "word"? Here's an example.


formpass Kuja omdearirox
Those two arguments encrypted result in:  om9Ml5p7UxIwg


formpass Kuja omdearirx
Those two arguments encrypted result in:  om9Ml5p7UxIwg

This means that if that persons pass is "omdearirox" and they enter "omdearirx" it will still log them in. This is frustrating, and I don't like how thats done. I feel like removing pass encryptions, but I'm not sure if I should. Can I get some insight about this?

David Haley USA Wed 10 Mar 2004 01:22 AM #1

Crypt is an "encryption" (actually a hash) which is meant to be irreversible, which means that you can't obtain the original password from the crypted version. There's a lot of math behind how all that works, but one thing for example is that you might have collisions.

What's intersting here is that two very similar words produced the same hash. I suspect that if you play around with it some more, you'll see different hashes showing up.

It's also a little more complicated than that, because when you crypt something, it takes the something you're crypting and a "salt". The "formpass" command might use the same salt in both cases, or something like that; also, when you log in, it crypts the password against itself as a hash or something like that.

It could be complete coincidence that those two words produce the same hash. I'd just suggest you play around with it a bit and see what happens; I'm pretty sure it's just chance that gave the same hash value for those two. Or, it could just be a poor usage of crypt in "formpass".

Zeno USA Wed 10 Mar 2004 01:28 AM #2

Actually I asked that question wrong, heh. I know that it comes out with different results most of the time, but sometimes it doesn't. And when this is used with passwords, thats never a good thing. Many words that are similar come up with the same result. Its quite annoying. I may just rip the password encryption out of the mud...

Samson USA Wed 10 Mar 2004 03:18 AM #3

Ripping the encryption out of the mud isn't exactly the best choice either. Doing so would cause passwords to be stored in plain text, which could be read by anyone. If you're on a shared host with lax security, this is a Bad Thing(tm). The encryption is there for your protection. It would be strongly advised for you to continue using it.

Now, with that in mind, if crypt() producing this one single anomaly bothers you this much, you could always beef things up and use MD5 instead. :)

Greven Canada Wed 10 Mar 2004 04:09 AM #4

I actually beleive that most of the muds crpyt functions only looks at the first 8 charaters of the salt string, if the salt is as close as those word, then it won't be different.

David Haley USA Wed 10 Mar 2004 04:42 AM #5

I just read the manpage for crypt and found out some interesting and disturbing things...


       crypt  is  the  password  encryption function.  It is based on the Data
       Encryption Standard algorithm with  variations  intended  (among  other
       things)  to discourage use of hardware implementations of a key search.

       key is a user's typed password.

       salt is a two-character string chosen from the set [a-zA-Z0-9./].  This
       string  is used to perturb the algorithm in one of 4096 different ways.

       By taking the lowest 7 bits of each of the first  eight  characters  of
       the  key, a 56-bit key is obtained.  This 56-bit key is used to encrypt
       repeatedly a constant  string  (usually  a  string  consisting  of  all
       zeros).   The returned value points to the encrypted password, a series
       of 13 printable ASCII characters (the first  two  characters  represent
       the salt itself).  The return value points to static data whose content
       is overwritten by each call.

       Warning: The key space consists of 2**56 equal 7.2e16 possible  values.
       Exhaustive searches of this key space are possible using massively par-
       allel computers.  Software, such as crack(1), is available  which  will
       search  the  portion of this key space that is generally used by humans
       for passwords.  Hence, password selection  should,  at  minimum,  avoid
       common words and names.  The use of a passwd(1) program that checks for
       crackable passwords during the selection process is recommended.

       The DES algorithm itself has a few quirks which make  the  use  of  the
       crypt(3)  interface a very poor choice for anything other than password
       authentication.  If you are planning on using  the  crypt(3)  interface
       for  a cryptography project, don't do it: get a good book on encryption
       and one of the widely available DES libraries.

(underlines are by me.)

So yeah. If you can guess the first 8 letters of a password, then... you've cracked the password according to this algorithm. (Icky!)

However some protection is still better than no protection! You'd be much better off getting a more robust hashing algorithm like MD5 if you're really interested in high security.

Nick Gammon Australia Forum Administrator Wed 10 Mar 2004 05:42 AM #6

Quote:

This means that if that persons pass is "omdearirox" and they enter "omdearirx" it will still log them in. This is frustrating, and I don't like how thats done. I feel like removing pass encryptions, but I'm not sure if I should. Can I get some insight about this?

As has been mentioned above, the crypt function only processes 8 characters, and you are supplying differences in the 9th upwards. Thus they will match.

You may be better simply hashing the password, where the hash could be of any length string. By storing the hash people cannot find the passwords if they happen to get read access to the player files, and the hashes cannot be reversed.

Also see this post:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3166

This mentions that crypt passwords *can* be reversed.

It is simpler and safer to hash the password, and store the hash. Then when the player logs in you hash the password they type, and compare that the two hashes are the same.

David Haley USA Wed 10 Mar 2004 06:45 AM #7

Actually, I don't think they can be reversed. Whiteknight is incorrect on that point: the password never gets decrypted, in SMAUG at least.
One simple example of why it can't be reversed to the original password is that if two different passwords give the same key, and you have the key, how do you know which one the original password was?

An interesting thing that I also just saw in the manpage is that, apparently with glibc2, if you put "$1$" as the first 3 bytes of the salt, then it will use the MD-5 algorithm instead of DES, and will also take into account the whole password string (and not just the first 8 bytes.)

Nick Gammon Australia Forum Administrator Wed 10 Mar 2004 08:29 PM #8

Hmmm - looks like you are right. :)

Oh well, the people who decode passwd files probably do it with a dictionary attack.

Anyway, the MD5 option sounds good for a more secure password.