[Standards-JIG] Re: JEP-0077: In-Band Registration

[Dave Cridland]

On Mon Jul 17 17:19:35 2006, Peter Saint-Andre wrote:
> Piotr Szturmaj wrote:
> >> Sending the password in plain text is not insecure if the 
> channel is
> >> encrypted (SSL/TLS) and that's what the JEP recommends.
> > > > Yes, that's ok. But passwords stored in DB/disk can be easily 
> readed. For > example in client's config file password must be in 
> plain text (eventually > encrypted, anyway decryption is rather 
> easy).
> 
> 
No, that's wrong. If you use DIGEST-MD5, for example, then the client 
need only store the intermediate hash, which is service specific. You 
can crack this by brute force, of course, but it's not as simple as a 
client storing just the password (potentially under some 
non-interactively reversible encryption).


> Well, sure, but if someone has access to server machine then they 
> can
> decrypt the passwords anyway. Clients could encrypt the password or
> never save the password (always prompt the user). Or we could start
> using mutual authentication with X.509 certificates. Etc. And that 
> use
> case in JEP-0077 applies only to systems that store passwords 
> anyway (if
> we did mutual authentication with certificates, it would not apply).

No, this is slightly misleading - JEP-0077 applies to systems that 
initialize the mechanisms with a password. This can involve storing 
the plaintext password, but it needn't at all.

For example, PLAIN and DIGEST-MD5 both need not store a plaintext 
password on the server. (DIGEST-MD5's intermediate hash is plaintext 
equivalent for that server only - if you've cracked the server to get 
it, it doesn't gain you much).

If you move towards mechanisms like SRP, this is even more pronounced 
- SRP's "password" database is very difficult to crack, and involves 
no plaintext equivalents, as I (very loosely) understand it.

However, if JEP-0077 moved data such as a hash between client and 
server, then this data would be close to, if not precisely, a 
plaintext equivalent *and* would not be usable to initialize stronger 
mechanisms.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade