[JDEV] Account information storage, plaintext?

[Robert Norris]

> 1) No one here is saying that it is possible/practical to use one way
> hashes to store the passwords required by transports on the server.
> (No more explanations of how hashes work, or why one-way encryption
> won't are required!)

Agreed.

> 2) Everyone acknowledges that these passwords aren't going to be 100%
> secure, esp as they are usually required to be sent in plain text to
> the server (which is Bad (tm)).  You have to trust your server admin
> etc etc.

Yes - the admin owns you ;)

> 3) Some people on the list - myself included - cannot understand why a
> simple *two way* encryption method isn't employed so that, at the very
> least, the passwords aren't as easily human readable/recognisable.
> (If there is a good reason, please explain this!)

Because it doesn't provide any actual security. If the encryption is
reversible, then (depending on how its implemented) anyone with access
to the server code or the server configuration (keys etc) can decrypt
the passwords. This doesn't provide any added security - it only makes
it look better on the surface.

Of course, someone will tell me that we could just change the
permissions on the server configuration so that Joe User can't get at
the keys (or whatever) needed to decrypt the passwords. If thats the
case, why not just access control the data store itself?

> 4) It is acknowledged that a) the server will need to translated/send
> these passwords in plain text, b) integration with other apps may
> require password *stored* in plain text. (But please explain if there
> is a good reason why this should be the default)

Both Jabber's digest auth mechanism and SASLs DIGEST-MD5 (the best auth
mechanisms we have to date) require both the client and the server to
have access to the plaintext password. Thats enough reason for me.

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- 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/14f204d1/attachment-0002.pgp>