Password authentication systems

[neokosmos]

This may only be tangentially related to Python, but since I am coding
a password authentication system in Python, I thought I would ask here.

In Linux (and presumably other *NIX systems that support it), when
shadow passwords are enabled, the actual password is not stored.
Instead an encrypted version is stored. Then, to authenticate the
password, the system re-encrypts the user's input to see if it matches
the stored, encrypted version.

Presumably, this is done using the crypt() system call (and,
fortunuately, Python has a builtin crypt module!). Presumably, as
well, this is at least somewhat secure, assuming a source of
cryptographic randomness to use to choose the salt. Are SHA1 and MD5
suitable for this sort of thing as well, or would I need to move to
something more "industrial strength" from, say, the pyCrypto module if
I wanted to avoid a dependency on the crypt module?

[Paul Rubin]

ne*******@gmail .com writes:

Presumably, this is done using the crypt() system call (and,
fortunuately, Python has a builtin crypt module!). Presumably, as
well, this is at least somewhat secure, assuming a source of
cryptographic randomness to use to choose the salt. Are SHA1 and MD5
suitable for this sort of thing as well, or would I need to move to
something more "industrial strength" from, say, the pyCrypto module if
I wanted to avoid a dependency on the crypt module?

The salt doesn't really have to be cryptographical ly random.
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:

hash = hmac.new(secret _key, password).hexdi gest()

will give you a hex digit string; or if you prefer, you could use
..digest() instead of .hexdigest() and base64 encode it if you want
printable output. Keep in mind, though, that if the secret key leaks,
you effectively have an unsalted hash. You could add a salt if
you want (untested):

import os
salt = os.urandom(8) # 8 random bytes
hash = (salt, hmac.new(secret _key, salt + password).diges t())

note that the salt and hash are both binary. You may want to encode
them (e.g. base64) if you need printable chars.

[neokosmos]

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
interoperabilit y. 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.

[Paul Rubin]

ne*******@gmail .com writes:

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.

If you're going to broadcast passwords in the clear over the network,
that's a pretty big leak as well, that obscuring the stored
server-side checksums won't help with. Will the game players use a
special client program? If yes, use SRP (http://srp.stanford.edu).
This has already been implemented in Python several times.

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.

Yeah, this issue is traditionally a nuisance, especially if the server
has to restart itself after a crash. If you start the server
manually, you can type in a passphrase.

[neokosmos]

Paul Rubin wrote:

ne*******@gmail .com writes:

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.

Yeah, this issue is traditionally a nuisance, especially if the server
has to restart itself after a crash. If you start the server
manually, you can type in a passphrase.

Ah, yes, I see I failed to mention that I would like the server to at
least try and restart itself after a crash. Hence, my earlier
apprehension at using a stored secret key.

I realize that having the players communicate with the server via plain
telnet is a huge security hole. For a commercial server, I'd probably
do things differently, but, again, for a free game server, the idea is
to allow players with ordinary telnet or MUD clients to connect without
problems.

My goal is to keep user passwords as safe as possible, assuming someone
did decide to steal the password files. I'm willing to punt versus
attacks that will intercept the password between the player and the
server in order to allow the player to connect with a non-custom
client. This requirement might evolve in the future, but, for now,
that's how I'm envisioning things.

[Paul Rubin]

ne*******@gmail .com writes:

My goal is to keep user passwords as safe as possible, assuming someone
did decide to steal the password files.

How often will new accounts be added? I have an idea I might try to
code up.

[neokosmos]

Paul Rubin wrote:

ne*******@gmail .com writes:

My goal is to keep user passwords as safe as possible, assuming someone
did decide to steal the password files.

How often will new accounts be added? I have an idea I might try to
code up.

Frequently, I hope. Realistically, when I open my personal MUD server,
what I expect is an initial flurry of new accounts (say, up to 100 a
day, just to overestimate), then slowing down to a steadier state
(again, say 10 per day, to overestimate).

I'm curious about this idea, in any case. :-) If you decide to "code
it up," that's great... otherwise, I'd appreciate if you emailed me to
discuss it away from comp.lang.pytho n.

Thanks!

[AlbaClause]

ne*******@gmail .com wrote:

This may only be tangentially related to Python, but since I am coding
a password authentication system in Python, I thought I would ask here.

In Linux (and presumably other *NIX systems that support it), when
shadow passwords are enabled, the actual password is not stored.
Instead an encrypted version is stored. Then, to authenticate the
password, the system re-encrypts the user's input to see if it matches
the stored, encrypted version.

Correct me if I'm wrong, but I believe that all Linux passwords are
encrypted whether you enable shadow passwords or not. I believe that when
you enable shadow passwords, the encrypted passwords are stored in a file
other than 'passwd'. Is this not correct?

[Paul Rubin]

AlbaClause <yo*@cogeco.caw rites:

Correct me if I'm wrong, but I believe that all Linux passwords are
encrypted whether you enable shadow passwords or not. I believe that when
you enable shadow passwords, the encrypted passwords are stored in a file
other than 'passwd'. Is this not correct?

Yes.

[Tim Scheidemantle]

Enabling shadow passwords stores them in /etc/shadow which is not world
readable unlike /etc/passwd. They would be encrytped regardless of the
file they are in.
AlbaClause wrote:

ne*******@gmail .com wrote:

>This may only be tangentially related to Python, but since I am coding
a password authentication system in Python, I thought I would ask here.

In Linux (and presumably other *NIX systems that support it), when
shadow passwords are enabled, the actual password is not stored.
Instead an encrypted version is stored. Then, to authenticate the
password, the system re-encrypts the user's input to see if it matches
the stored, encrypted version.

Correct me if I'm wrong, but I believe that all Linux passwords are
encrypted whether you enable shadow passwords or not. I believe that when
you enable shadow passwords, the encrypted passwords are stored in a file
other than 'passwd'. Is this not correct?