Password authentication systems

neokosmos at gmail.com neokosmos at gmail.com
Thu Aug 10 10:46:24 EDT 2006


First, I'd just like to say, wow, and thanks to both you and Sybren for
your fast responses. :)   Twenty minutes is less time than it takes to
get an answer from some companies paid tech support. ;)

Paul Rubin wrote:

> There are two main issues:
>
> 1) Unix password hashing uses several different algorithms depending
> on version and configuration.  Do you need to interoperate, or are you
> just trying to do something similar?
>
> 2) Even with salting, computers are fast enough thse days to run
> dictionary searches against unkeyed hashed passwords, so Unix now uses
> a non-publicly-readable shadow password file.  You're best off hashing
> with an actual secret key, if you have a way to maintain one.  I'd
> suggest using the hmac module:

To answer your questions, 1. there's no need for any sort of
interoperability.  Otherwise, the obvious thing to do is to look up the
particular system(s) I needed to interoperate with and find out what
algorithm(s) are used there.  This is a password authentication system
intended for a game server (a MUD/MMOG, in fact).  The real limiting
factor here is that I want to keep the server accessible via pure
telnet protocol.  Otherwise, using SSH would make sense.

For my particular use case, simply using crypt() or MD5 or SHA1 would
certainly be adequate, as I don't intend to charge money for people to
play on my particular server. But, there is always the possibility that
someone might want to do so, and, when money is involved, it always
pays to be extra careful.  (Of course I do realize that it would make
sense to have any credit-card verification system isolated on a
separate server entirely, not accessible to the internet, simply so
that if the game server is compromised, it's much harder to get credit
card details.  But, I digress.)

I had considered the hmac module.  The thing that bugs me about it is
that I'd have to keep this secret key around someplace accessible to
the server.  Most likely, this means storing it in a file.  I'd guess
that if someone could steal a file containing all my users' passwords,
then they could also access this (since the server itself would need
access.)  Essentially, I guess it's an issue with maintaining the
secret key that I haven't fully considered yet.




More information about the Python-list mailing list