Live data from Hacker News

LinkedIn Intro: Doing the Impossible on iOS

engineering.linkedin.com

231–240 of 309 posts

Re: LinkedIn Intro: Doing the Impossible on iOS

#231
post #225

Earlier quoted context omitted.

That LinkedIn not violate one of the simplest, most fundamental notions of security: never ever give your credentials to a third party . Part of being a semi-decent citizen of the internet is also not encouraging users to give third parties their credentials It is a neat hack. I'd love this if it was "here's how we integrate LinkedIn into our email clients internally". It is novel and it does use CSS in weird and new…

To be fair, they specifically mention that they use OAuth for Gmail/GApps. It seems like they're aware of this but it's hardly their responsibility to avoid building a hack such as this just because Google are the only provider to allow IMAP access with OAuth. If more e-mail providers would allow such authentication, I'm sure LinkedIn would be happy to extend the support.

It seems like they're aware of this but it's hardly their responsibility to avoid building a hack such as this...

Is that so? "Fsck the world, we got a business to run?"

Re: LinkedIn Intro: Doing the Impossible on iOS

#232

Earlier quoted context omitted.

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.

Interestingly in a world of front-end JS frameworks you could fix this by encoding client-side before submission.

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.

Re: LinkedIn Intro: Doing the Impossible on iOS

#233
post #110
post #75

I don't think I've ever gagged quite like that while reading a technical article describing a "neat hack". At first I'm thinking, oh, I wonder how they convinced Apple to let them use some private APIs, and then... curiosity turns to revulsion as soon as I saw that proxy diagram. Good god... LinkedIn MITM IMAP. That is truly terrifying. How would you even go about installing that on the user's phone? Oh, that's in th…

Nerd outrage hyperbole much? This is an OPT IN service. You know, only for people who WANT to use it? If it causes you this degree of apoplexy, you are in luck: you don't have to use it.

Right, so I should be ok about a company that recently lost 7 million passwords that were 'encrypted' using only SHA1, suddenly getting access to a whole raft more passwords?

Access to this many passwords is a threat even if my password is not one of them.

Finally, it may be opt in, but are they going to explain to the user that they get to keep a password for an account to which they have no legitimate right?

Re: LinkedIn Intro: Doing the Impossible on iOS

#234
I don't understand why trusting LI with all your email is worse than trusting Google with all your email.

Sure, if you do it for your corporate email, you may be violating the rules of your employer, but that's between you and your employer, and not enough reason to keep others from using an amazingly useful service for their own personal email.

Lost in all this discussion is just how awesome Rapportive is - the desktop gmail version has concretely and significantly changed my life for the better, and that's not hyperbole. Being able to research people without leaving my inbox has saved hours of time in my life, made my communications with those people more effective, and prevented me from making at least a couple serious errors.

All that is worth the added risk, especially for my personal email. Curious: does everyone in this thread have equal outrage for those widgets that log into your email clients so that you can invite your friends?

Re: LinkedIn Intro: Doing the Impossible on iOS

#235
post #232

Earlier quoted context omitted.

Interestingly in a world of front-end JS frameworks you could fix this by encoding client-side before submission.

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.

In theory, you could use something like MD5 auth, but really there's not much point.

Re: LinkedIn Intro: Doing the Impossible on iOS

#236

Earlier quoted context omitted.

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

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.

It's a proxy. It doesn't need to store anything. The server asks for a password, the proxy asks the client.

Re: LinkedIn Intro: Doing the Impossible on iOS

#238
post #75

I don't think I've ever gagged quite like that while reading a technical article describing a "neat hack". At first I'm thinking, oh, I wonder how they convinced Apple to let them use some private APIs, and then... curiosity turns to revulsion as soon as I saw that proxy diagram. Good god... LinkedIn MITM IMAP. That is truly terrifying. How would you even go about installing that on the user's phone? Oh, that's in th…

It's funny, I read all through that with my rose tinted glasses thinking they'd created a local IMAP server on the phone, which would have been clever (and, I think, doable)... in fact I was running this perception until "Our proxy server is written in Ruby using EventMachine, which allows it to efficiently handle many concurrent IMAP connections" And I thought, why the heck would one phone be issuing so many concurr…

I was thinking the same thing. This solution didn't even cross my mind because… well who would ever use anything like this?

Re: LinkedIn Intro: Doing the Impossible on iOS

#239

I don't understand why trusting LI with all your email is worse than trusting Google with all your email. Sure, if you do it for your corporate email, you may be violating the rules of your employer, but that's between you and your employer, and not enough reason to keep others from using an amazingly useful service for their own personal email. Lost in all this discussion is just how awesome Rapportive is - the desk…

LinkedIn has a pretty poor history because of their SHA1 "encrypted" password leak.

They also have numerous business practices that I find shady. Passing your email through them offers yet another conflict of interest.

Re: LinkedIn Intro: Doing the Impossible on iOS

#240

For all those calling this a "hack", it is not. It is simply a "man in the middle" attack. It is wrong. It is a total violation of trust. It is gross.

I would only say that it is a violation of trust if they somehow installed the certificate on your phone when installing the linkedIn app...

If a user knowingly installs this, with the understanding that linkedin is essentially a proxy for their entire email ecosystem - then they are knowingly trusting linkedin.

To be honest, I can see this being used by sales reps. They are often interested in connecting to people and understanding peoples backgrounds. They also move quite freely between organisations, and don't have a religious tie to their email and/or privacy (in the sense of their corporate email privacy).

Post reply on HN