On Tue, Oct 02, 2007 at 09:10:40PM -0700, Chris Travers wrote:
> Client-side MD5 of passwords is almost always seriously wrong. In fact I
> cannot think of a case where this would be acceptable. Such a system would
> be vulnerable to replay attacks at the very least. See Seneca's post above
> as to why.
I disagree here. I mentionned the SPIP CMS as a good example on how to
do client-side, here's the actual url, in french unfortunatly:
http://www.spip-contrib.net/AuthentificationDansSpip
Such a system *is* vulnerable to a replay attack, unless you change the
random seed at every operation, which might create problems with
concurrent requests.
But a HTTP Auth + session cookie (to pick one) setup is *also*
vulnerable to a replay attack, if you have access to the raw data, so I
don't take the "replay attack" argument very seriously...
> The reason why we need to be able to access the plain text password on the
> server is that we need to use that to do pass-through authentication against
> the db. This way App User == DB User and so db permissions can be used to
> provide real access control. The same issue of hashing is why PostgreSQL
> can't be passed an MD5 response to a password challenge when using PAM or
> LDAP authentication.
Of course, that's the root of this issue: we need the password in clear
text somewhere...
Our only protection, in retrospect, is SSL. Any other system is going to
have its weaknesses.
(Well.... SSL also has its weaknesses, but that's another story... :)
--
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
"Coup de cafard..."
Attachment:
signature.asc
Description: Digital signature