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

DON'T! Just don't.

Encrypting user credentials in JS is probably even worse than parsing HTML with regular expressions: http://stackoverflow.com/questions/1732348/regex-match-open-...

Just send it in cleartext, but over properly verified https.

Or, use TLS and get it for free. Crypto on JS is a scary, scary world.

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.

I believe vBulletin actually does this.

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.