Re: Plaintext passwords

Hi again, everybody,

first I would like to clarify one thing.
I do not suggest replacing connection encryption with hashed passwords.
It seems you might have misunderstood me that way.

I would simply like to store the passwords as a hash. To have an
additional layer of security in case the server is compromised. It has
been done with unix passwords for decades and I wonder why that concept
has been abandoned.


This my original answer to Norman's post which I realized all came down
to the fact that I don't want to change the authentication process only
the server-side storage.
> It depends on what type of hash, if you send an unsalted hash, then that's
> replay-able.  I can record the hash, and send it back to the server, and get
> access.  The reason why digest-md5 is safer, is because the hash is also
> derived from two random nonces (both server and client add randomness to the
> hash via their nonce).  Very simply, the hash is derived from: username +
> realm + password + server-nonce + client-nonce (with a lot more real hashing
> to get the final value, read RFC 2831 for details).  The problem is that the
> server needs to store at least the hash of username+realm+password.
Since I don't want to replace encryption thwarting replay attacks is out
of scope.
 
> > > The only non-plaintext storage that makes any sense, is probably
> > digest-md5.
> > >  Although then the only way to 'upgrade' a password from say md5 to sha1,
> > if
> > > for the client to provide a plaintext password - which is what we're
> > trying
> > > to avoid.
> > Why would anybody want to 'upgrade' a password to a different hash?
> > Assuming the hash is broken new passwords should be given out anyway.
I don't know what you're quoting here but again if the authentication
process is not in focus hashing a password in comparison to storing it
in plaintext simply increases security no matter how bad the hash is.

> The idea on upgrading a password hash is to do it before the database is
> compromised, not after.  If you suddenly turn around and ask everyone to
> pick new passwords without having the old one around, then there's a
> weakness.  There might only be a theoretical weakness in old-hash, but not a
> proven one, or old-hash might be 10 years old, and easy to brute force.  So
> you want to transparently upgrade the server database from old-hash to
> new-hash without disturbing the existing user-base.
Sorry, I don't see the weakness in asking users to pick new passwords.

> The way that's generally done, is to check if the user has a new or old
> style hash, if they have a new-hash, then everything proceeds as normal.  If
> they have an old-hash, then the password is checked against the old-hash,
> and if it matches, then a new-hash is computed, stored, and the old-hash is
> removed.  So in this method, you gradually 'upgrade' the security of your
> user passwords as they log in, and they didn't even notice.  This upgrade is
> only possible if you know the plaintext password, so it doesn't work is the
> client logs in using a hash.
Or you could just write them a message saying "For security purposes
please enter your password again." and have the new hash computed by the
client and sent to the server which in turn may store it. (Though that's
just something I came up with right now so it may be inherently flawed.)

Ciao
	Simon
_______________________________________________
JAdmin mailing list
FAQ: http://www.jabber.org/discussion-lists/jadmin-faq
Forum: http://www.jabberforum.org/forumdisplay.php?f=19
Info: http://mail.jabber.org/mailman/listinfo/jadmin
Unsubscribe: [email protected]
_______________________________________________