> 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: [EMAIL PROTECTED] Web: http://cataclysm.cx/
pgp00000.pgp
Description: PGP signature
