Re: Plaintext passwords

On Fri, Oct 10, 2008 at 1:43 PM, Simon Friedberger
<[email protected]<simon%[email protected]>
> wrote:

> > Because it makes it simpler and easier to make it possible to confirm
> that
> > the client knows the same password without having send it over the wire
> when
> > authenticating, (or encrypt it before sending).
> > Another reason is that it doesn't matter how the password is encrypted,
> if
> > the jabber server binary can read it, then so can the server admin.
>
> What kind of verification procedure do you have in mind? Why not send a
> hash as usual?
> The same problem holds for all password authentication systems. Again it is
> usually solved using a hash.
>

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.


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

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.

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.

I am not a security expect, but I know enough to know it's hard, really
hard, but in summary: You have to have plaintext somewhere, either on the
server (vulnerable to attack on the server), or on the wire (vulnerable to
MITM attacks), or you make the user's life difficult when you want to
upgrade their password strength (vulnerable to social engineering).

Much like physical security, I'm not sure there is a 100% secure way, you
can just make it technically in-feasible to attack, and/or not as attractive
as other targets.

-- 
- Norman Rasmussen
- Email: [email protected]
- Home page: http://norman.rasmussen.co.za/

_______________________________________________
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]
_______________________________________________