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?

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

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.

Fair enough.

In Linux (and presumably other *NIX systems that support it), when
shadow passwords are enabled, the actual password is not stored.

Same is true without shadow passwords.

Presumably, this is done using the crypt() system call

On old systems, or on systems compatible with those old systems.

Are SHA1 and MD5 suitable for this sort of thing as well

Yup, they are. As a matter of fact, they are more in use now than the
crypt() function. I'd pick SHA1.

Sybren

 

[Paul Rubin]

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 cryptographically 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).hexdigest()

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).digest())

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.

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.

 

[Dennis Lee Bieber]

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.

No... Regular non-shadowed passwords are also encrypted. They are
stored in the passwd file which is world readable.

Shadowed passwords are not stored in the passwd file, but in a
root-only shadow file. This way, crackers cannot copy the passwd file
down, and do a brute force dictionary search for words that encrypt to
the visible password.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Paul Rubin]

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]

(e-mail address removed) writes:

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]

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]

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.python.

Thanks!

 

[AlbaClause]

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]

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.

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

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.

You should realize that when people can stay anonymous (like on the
internet), they often start acting a lot less social than usual. When
it comes to a game, there will be people trying to steal passwords to
get an advantage.

Sybren

 

[Sybren Stuvel]

AlbaClause enlightened us with:

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?

It's correct.

Sybren