TLS/SSL will be a requirement soon, with some form of "bearer token" auth scheme. At least for the reference implementation.

The MD5 hash is there to mitigate two issues, currently: some (or most) common users won't pay for a certificate, so instead of sending the password in cleartext, it's hashed as an MD5 to avoid exposure—all of this, of course, is no guarantee against MITM. Which leads us to the second issue: most [non–techie] users re–use their password for a _lot_ of things. At least, if the password is intercepted, it won't be reusable.

It's also worth noting that bcrypt is used server–side to store passwords.

Auth (and very possibly a crypto scheme too) is yet to be tackled. Haven't even decided if it should be part of the spec, or left up to each implementer.

Transmitting MD5(password) is really no better than just sending the password (except maybe for the top 20% or so strongest passwords).

Auth is a WIP. Anybody who has suggestions and candidates for auth schemes, is welcome to send them to the mailing list, so we can improve the protocol :) [email protected]

+1 to this. If you're going to send a replayable MD5 hash over the wire, you might as well just drop the pretense and just call it "password" instead - intercepting the "hash" compromises the account just as surely as if you'd leaked the password.

This is especially nasty since the document mentions that not all users will use SSL. If supporting access via a non-secure channel is an absolute requirement, you may want to figure out something more effective...

Sure :) It's something I'm working on: https://news.ycombinator.com/item?id=6798707