[JDEV] Re: Account information storage, plaintext? ...AND JabberD password storage

[Matthias Wimmer]

Hi Robert!


Go on and implement storage of hashed passwords for SASL-MD5 as it may
help to get Jabber users feeling better. I am tired of this discussion.

But I want to note that we will not really get additional security of
it. If the hash is calculated the way you describe it, you don't need
more to authenticate against the server (or any other server using SASL
with MD5) than this hash. Therefore something that has to be protected
as hard as plain text passwords are again in the storage.

I just can hope that people do not start to make the access to these
files world readable (e.g. because they want to parse vCards in PHP
scripts on their web servers) because they think that nothing security
relevant is in the stored data.

The only thing we might get from it (if admins keep protecting the data)
is that admins can't get the plain text password in the hope that a
users uses it for other services as well. But if it really wants to
hijack the password nobody stopps him from disabling password hashing,
forcing plaintext authentication (and sniffing the login) or things like
that.


Tot kijk
    Matthias

Robert Norris schrieb am 2003-09-17 07:54:36:
> OK, I've looked into, and it seems fairly straightforward to add a
> config option to j2 to tell it to store SHA1-hashed passwords, with the
> caveat that the "digest" method will no longer be offered.
> 
> On its own, this scares me, so we'd also need an option to require
> SSL/TLS before auth can happen. This is slightly more difficult (due to
> limitations in the current codebase), but really necessary for this.
> 
> Also, it appears I may have been mistaken with regard to DIGEST-MD5.
> I've just reviewed the spec (RFC2831), and it has this as part of its
> calculations.
> 
>   A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
>        ":", nonce-value, ":", cnonce-value, ":", authzid-value }
> 
> The username, realm and password values will be static, in most cases,
> which means that it should be possible to store this hash rather than
> the password, and then used this value rather than recomputing it from
> the passowrd each time. I think this will place a restriction (a single
> user cannot appear in multiple realms), but that doesn't seem to be too
> much of a problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20030917/7255c428/attachment-0002.pgp>