[robn_fastmail]

If you read the spec closely, you'll note that it provides support for arbitrary challenge/response auth mechanisms. Its conceptually the same as SASL in that respect.

Yes, we're assuming a secure transport. Most of the internet currently does. Most of the passwords you send over encrypted channels right now are plaintext. This is not something we're trying to solve with JMAP (if it even needs solving, which is debatable).

[groby_b]

I wouldn't ask you to solve it. I would've hoped for simply deferring the problem to somebody else. (I.e. OAuth)

Authentication is an incredibly hard problem. Including it in the spec encumbers it. And allowing for arbitrary challenge/response auth mechanisms gains you exactly one thing - guaranteed incompatibility as the protocol gains popularity :)

[brerlapn]

Having worked in identity management and access control, I can't emphasize enough how important your second paragraph is, and why Fastmail's approach of leaving authentication out of the protocol is the right way to go. Over and over we run into solutions that are borked from the start because they have a basic, bare-bones authentication component that is included because customers expect to be able to log in "out of the box" but then can't be replaced with a sophisticated authentication module because that basic bare-bones piece has its crappy insecure tendrils entwined throughout the rest of the product. Mikhailt said it in this discussion, too--modular components that do their single job well, and don't cram them all into one protocol.

[illumen]

Plain text passwords. No amount of blablabla can excuse that.

Plain text passwords.

[robn_fastmail]

So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?

[mback2k]

The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.

[brongondwana]

hashed passwords are security theatre unless you have a challenge-response in which password is hashed along with a challenge from the server, otherwise you don't need the password - you only need the hash to gain access. I've MITMed a system like that before when I wrote a nice interface to the awful timesheet system at a previous job.

Mandating specific security mechanisms isn't future proof. Authentication is almost a side issue to JMAP itself. Getting a securely authenticated and protected channel is phase 1, sending and receiving the JMAP protocol items is phase 2.

The reality is that almost everyone is sending plaintext passwords over SSL these days, and the reason isn't that they hate you - the reason is that it means they can bcrypt the password on the server side.

An interesting factor about most of the challenge response protocols out there - the server side needs to know either the plaintext password or something pretty reversible about the plaintext password. That's how the server can have a little chat over the wire with your client about the shared secret that they both know.

Since my security protocol design credentials aren't that much greater than the average internet commentator, I don't trust myself to design, or the average client writer to implement, a fancy security protocol that nobody has used before. Tried and true please.

[groby_b]

Mostly agree with you, but minor nit: The server doesn't need to know anything reversible about the password. A message digest is enough.

And your final paragraph is the reason I posted my original comment in the first place. Don't design a auth/security protocol when you design a mail protocol. Delegate to OAuth, move on. (Then again... debate rages there, too[1]. Auth is not fun(tm))

[1] http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h...

[icebraining]

What prevents an attacker from using the hashed password (without decoding it) in his/her own requests?