Hacker News Reader

Comment by iwantagrinder | Hacker News Reader

I' m interested in this from a security perspective. What does this new protocol offer in terms of better control around what makes it to the inbox? Would IMAP>JMAP translation before hitting the user give us better ability to filter out malicious items/spam?

View on HN

I think the only thing this particular protocol should be concerned with is reliably providing a method for communicating between client and server. Most spam and malicious mail filtering should happen as early in the process as possible, hopefully during the initial connection.

There is a a protocol named Sieve ( http://www.ietf.org/rfc/rfc5228.txt ) which provides for delivery stage filtering rules. It is similar in capability and usage to procmail, but formalized and somewhat more modern (and not capable of running arbitrary system commands), and supported by some modern IMAP/POP servers, like Dovecot. Presumably if JMAP gets integrated into those servers, Sieve would also be available.

And, I would hope there wouldn't be an IMAP/JMAP translation layer, but instead servers would implement JMAP directly. Though I guess in the short term there might be some sort of proxy.

Sieve is the native filtering engine used by FastMail, so I'd say it integrates quite well with JMAP, from my experience. :)

So am I. From looking at http://jmap.io/spec.html#authentication, it looks like the password will be transmitted in plain text. (See the text below the 200 response)

That makes me extremely queasy. Yes, HTTPS theoretically provides transport layer security, but a single breach of transport layer security results in the attackers permanent access to your mail.

I.e. run a MITM attack in a coffee shop, snoop up JMAP passwords, make use of them at a latter point in time.

I really hope I'm missing something important, or misread the spec.

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).

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

Plain text passwords.

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

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.

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

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.

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...

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 :)

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.

Reply on news.ycombinator.com