Where in the blog post does it say that your credentials are leaving the device in clear text. I know people don't like LinkedIn but I don't think even they would be dumb enough to do this over http.
How are they going to log in to your email account to MITM it, exactly, other than sending your password in cleartext to them? I'm not saying the connection itself is cleartext, but that they will be storing your email password in cleartext(!) to access your account at your email provider...
I think "your password is sent to LinkedIn" sufficiently and accurately describes what's happening. Adding "in cleartext" typically means via an unencrypted channel. Think about. Think about it. Every time you login into a website via password, your browser sends the password to the server. We don't usually call that out for being in plaintext, unless it really is using http.
I think what they're getting at is that LinkedIn has a plaintext copy of your email password, not necessarily that it got there via some unencrypted channel. And because LinkedIn needs to be able to log in again, it has to store it in plaintext, which then leads to the possibility of another incident where they leak millions of passwords[0].
It doesn't actually need to store it to log in again. The next time your phone connects to linkedin's proxy, it will provide the password again. Yes, this is basically the same as omnipresent, but not quite. If the servers are confiscated/stolen in a powered down state, the passwords aren't there to recover. You can immediately limit your exposure by not using the service. There are no backup tapes to accidentally go missing.
Also, while rare, the client could theoretically be using something like kerberos to authenticate, even over tls. The password exchange is secret, but the data contents would not be. I don't think the iphone supports kerberos, though.
(All this is not proof that they aren't your storing password, just that it's feasible for linkedin to merely pass it through. And possible, though not probable, for them to never even see the password.)
I was just musing hypothetically, but can you elaborate on why this is bad? Surely sending an encoded password is better than a non-encoded one, and in a worst case only as bad as sending a cleartext password (i.e. what happens now).
I don't think I was proposing not using TLS, just that if you interpret sending cleartext password over TLS as "plain-text" then sending it encoded over TLS sounds better.
Well, if you hash your password client-side, what's the difference from using clear text? A MITM will intercept your hashed password and use that to login.
It's a good idea IMO, I don't understand why it gets so much flak. A server who doesn't want to know your secret is more trustworthy than one that does, a MITM might be able to hijack your account but he won't see your favourite password and you don't have to trust that the server is hashing the password at their end.
To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent.
Of course that doesn't solve the problem above, but it still ought to be common practice.
"A server who doesn't want to know your secret is more trustworthy than one that does" - I totally agree here, in many ways that's why projects like http://openpgpjs.org/ are fundamentally MORE important that more/newer layers of centralized encryption like TLS that are fundamentally bust in that we have to blindly trust the server. yesyes, i know JS on untrusted/leaky browsers isn't totally bingo but at least someone is TRYING!
They need your cleartext pw in order to create a config profile and that's it. Why would they need to store your pw at all? Once the config profile is setup, the IMAP AUTH request gets proxied through them to the original provider and handled as normal. No need to store any pws at the proxy.
It's worth noting that they specifically state that for Gmail they can use OAuth through the refresh/access token system. Hopefully they do this for all other IMAP servers that support OAuth (there are a couple of them now).
However, for traditional IMAP/SMTP servers your point is well taken. They must store your credentials in a restorable state, which, however carefully you do, has difficult security implications.
In order to inject content into the stream, they must be able to decrypt and interpret the stream. It is not quite as simple as a traditional proxy which may not actually have to know the content it is transmitting. They must have all content you send over the stream for a short period of time in-memory in a restorable (if not plaintext) state in order to read from the client's IMAP stream, interpret, then send over the IMAP server's secure SSL stream. The short period of time over which they must keep it does not free them from the security implications. All an intruder must do is gain access, then monitor the stream. I'm not saying that this is impossible to mitigate, just that you're trusting them to do it right.
