Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LinkedIn Intro: Doing the Impossible on iOS

engineering.linkedin.com

Post reply on HN
Print view View original

261–270 of 309 posts

Re: LinkedIn Intro: Doing the Impossible on iOS

#261

Post by gurkendoktor »

_b8r0 wrote: post #113
ivix wrote: post #110

Earlier quoted context omitted.

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.

This service shouldn't exist. It breaks the very concept of email security. They're marketing it as though it's safe. Want hyperbole? Imagine Bayer marketing heroin as safe because you know, it's opt-in.

I understand the opinion, but I don't understand the sudden outrage.

LI, Google and Facebook have always wanted your third-party email credentials for Friend Finder-style features. The only difference is that this time we cannot even hope that they delete them after logging in once. Security-wise, it's all the same.

Re: LinkedIn Intro: Doing the Impossible on iOS

#262

Post by gurkendoktor »

miguelrochefort wrote: post #161

To HN commenters: If you don't trust LinkedIn, fine. Don't use it. But please, don't assume that LinkedIn is universally not trusted, the same way you assume that Microsoft is universally hated. This is a neat feature, and I'm sure that many people trust LinkedIn enough to think that the trade-off is worth it. Would you prefer to not have the choice to have access to this feature, and prevent others from having it to…

> What makes email SO MUCH more important than any other data to be in a category of their own?

The fact that email has become the de-facto master password for our online lives. If an attacker has my github password, they can push shitty code and write messages that I can roll back on the next day. If they have my email credentials, they can take over most of my online accounts anywhere.

Re: LinkedIn Intro: Doing the Impossible on iOS

#263

Post by cJ0th »

codezero wrote: post #227

Also from their FAQ: "For technical reasons, you can't remove the Intro app icon directly from the iPhone home screen." https://intro.linkedin.com/micro/faq This is insane. Not only does the whole setup hijack your mail, it is implemented in a way that makes it very hard for users to remove it.

It is horrible but there is little you can do to stop this trend: Most online services do not want that users can undo decisions and the vast majority will be okay with that. Ever wanted to correct a post on facebook?

Re: LinkedIn Intro: Doing the Impossible on iOS

#265

Post by junto »

junto wrote: post #85

I didn't realise Rappotive had been bought by LinedIn. Time to delete it from Gmail.

It wasn't immediately obvious how to remove it. For anyone else, the instructions are here:

http://rapportive.com/help#installation

Basically, I expected it to be a Gmail plugin, but it was a browser extension.

Re: LinkedIn Intro: Doing the Impossible on iOS

#266

Post by masklinn »

gergles wrote: post #148
chimeracoder wrote: post #94

Earlier quoted context omitted.

Not that we should trust anybody, but let's not forget that LinkedIn already has a history of losing user credentials: http://www.pcworld.com/article/257045/6_5m_linkedin_password...

No, they don't, and you keep posting that they do despite being proven wrong several times in the past. They lost hashed passwords which are not user credentials.

> They lost hashed passwords which are not user credentials.

These passwords were unsalted sha1, that's about as good as rot13. Linkedin has clearly proved completely unable to do things correctly, if that applies to passwords it applies to everything else.

Re: LinkedIn Intro: Doing the Impossible on iOS

#267

Post by davidsong »

hfern wrote: post #229
nopassrecover wrote: post #226

Earlier quoted context omitted.

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

I believe vBulletin actually does this.

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.

Re: LinkedIn Intro: Doing the Impossible on iOS

#268

Post by annnnd »

nopassrecover wrote: post #226
tedunangst wrote: post #212

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.

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.

Re: LinkedIn Intro: Doing the Impossible on iOS

#269

Post by freehunter »

baddox wrote: post #222
freehunter wrote: post #151

Earlier quoted context omitted.

I work in enterprise information security, and my team agreed upon hearing this news that if this was used on our email system, we would consider it a MITM attack . Whether or not the end user opted in, the corporation did not. So, in the context of use in environments where your email address is not fully owned by you, attack would be a valid word. Otherwise, I agree that it's a MITM but not an attack.

I appreciate the data point, but I must admit that sounds very unreasonable, unless you're considering the employer as the attacker. Would the same apply if an employee were using a VPN at work?

We do block VPN on our corporate network, yes. A VPN is a tunnel that hides user activity from our monitoring and DLP tools and use of VPN from our network to the outside is against policy. Likewise, sharing your credentials with a third party is against policy.

The attacker is LinkedIn. The employee is the attack vector. LinkedIn is engaging in a phishing attack.

Post reply on HN