Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

08:00 AM

LinkedIn Lesson: Detail Security First, Feature Fest Second

Memo to businesses with an information security trust deficit: Prove how you're going to keep our data secure.

Memo to any business that wants to handle people's private information: Tell us how you're going to keep our data safe. And, especially if you've mishandled information security practices in the past, provide copious details of your new security approach, so we can decide whether to trust you.

Or you can take an alternate approach, recently practiced by LinkedIn: Talk about how great your new product is, while appearing to gloss over your business's recent security and privacy shortcomings. That was the PR mess the social networking site recently created for itself, after launching its new Intro service via a blog post that extolled the iOS app's feature set, while providing vague assurances about practicing responsible information security.

To be clear: Intro isn't evil. The social networking tool -- an extension of Rapportive, which LinkedIn purchased last year -- offers functionality that people might find helpful. "I've been using Rapportive with Gmail for a couple of years and find it useful for providing social context around my email correspondence, making it easy to see who I'm communicating with and a little bit about them, as well as whether I have an existing social network connection with them or might want to establish one," InformationWeek's David Carr commented when Intro was introduced.

So far, so good. But what about security? As befits any service that wants to play go-between -- in this case, between your iOS Mail app and email service provider -- users should be able to trust that LinkedIn is handling the information in a secure manner, and decide for themselves if the potential privacy tradeoff is worth it.

Trust deficits
Where information security and trust are concerned, however, LinkedIn enjoys a deficit. Last year, notably, the business lost 6.5 million users' passwords, and only spotted the related breach after those passwords surfaced on an underground password-hacking forum. Adding insult to injury, LinkedIn had committed a basic security error by hashing, yet not salting, those passwords, thus making them relatively easy for attackers to crack.

Also last year, researchers at Skycure accused the company of creating a privacy leak, due to an optional feature that allows the LinkedIn iOS app to grab information about people with whom users have scheduled meetings. According to Skycure, LinkedIn's approach didn't just grab information about meeting participants, as would be expected, but also sensitive meeting details -- including time, location, meeting subjects, phone numbers, passcodes, and more -- for anyone who activated the feature.

Fast-forward to LinkedIn's Intro announcement, which included a short and vague "security and privacy" section near the end. "We will do everything we can to make sure that it is safe," wrote LinkedIn software engineer Martin Kleppmann. "Our principles and key security measures are detailed in our pledge of privacy."

But security talk is cheap; what did LinkedIn actually do? "LinkedIn has a documented history of insecure design practice," according to a blog post from security consulting firm Bishop Fox. "As anybody who has ever assessed a vendor would want to know: Who did the security review of the Intro app? Are there outstanding security vulnerabilities? Can we see a copy of a Letter of Assessment?"

All told, Bishop Fox detailed 10 Intro security and privacy concerns, including the fact that two Intro servers used SSLv2 -- a weak cipher -- for transport layer security. "SSLv2 is known to be insecure. In fact, it's a violation of many standards and guidelines, such as PCI DSS, to allow SSLv2," according to Bishop Fox. "We always suggest using strong encryption. Against the large scale, government-backed spying, it may help. It may be your only hope."

Meanwhile, security researcher Jordan Wright detailed how would-be phishers could spoof Intro into saying that an email was from a legitimate connection, even if it was sent by attackers and linked to a malicious website. In other words, he warned, Intro might lull users into a false sense of security.

LinkedIn responds
Three days after Intro's launch, in a blog post, Cory Scott, LinkedIn's senior manager of information security, provided some basic Intro security details. Notably, he said that Intro data was stored on a secure network segment that was separated from the rest of the company's infrastructure, that security consulting firm iSEC Partners was hired to "perform a line-by-line code review of the credential handling and mail parsing/insertion code" in Intro, and that LinkedIn's own security team had pen-tested the app.

LinkedIn also responded to the concerns raised by Bishop Fox and mitigated some related flaws, including discontinuing the use of SSLv2. Likewise, LinkedIn issued a fix to address the phishing vulnerability identified by Wright. He applauded the company's "quick and effective response," though questioned whether attackers might still be able to employ CSS tricks to spoof Intro users.

To date, not every last Intro-related security and privacy question has been settled. "The big question is whether we're really ready to trust our private email communications with a social media company with a strong focus on mining data," security researcher Troy Hunt said. "We worry about sharing small pieces of information with Facebook; are we ready to share every single email -- every single attachment -- with one of the world's largest social media companies?"

Would-be Intro users can answer that question for themselves, knowing that from a security standpoint -- based on the basic details belatedly shared by LinkedIn -- their data is likely relatively safe. Likewise, Intro's security has been further improved in response to flaws spotted by third-party researches, though notably not LinkedIn's own penetration testing team.

Next time, however, when it comes to LinkedIn -- or any other technology vendor or social network provider -- launching a new product or service, why not prevent this type of PR fallout by instead detailing exactly how you're going to keep our information secure? For many would-be users, glossing over security triggers is cause for concern -- especially in these NSA digital dragnet days.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
11/17/2013 | 3:28:00 PM
Where's the outrage?
The problem isn't the lack of security controls, it is the fact that the public doesn't get angry enough about breaches and privacy concerns to move their business elsewhere. More than 617M records... yes 617 MILLION... (according to the Privacy Rights Clearinghouse) have been breached in the past 7 years. But most of the high-profile companies have not been adversely affected by the breaches (think stock prices of breached companies). These companies can ride the bad PR for a while as the news cycle changes pretty quickly. Most consumers don't express thier displeasure with the pocketbooks. Until they do, things won't change.   
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows unauthenticated reflected XSS via the redirect page.
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows unauthenticated eval injection via the queryBCP method of the Auxiliary Service.
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows attackers to obtain sensitive information by reading the IWEBSERVICE_JSONRPC_COOKIE cookie.
PUBLISHED: 2020-02-25
ISPConfig before 3.1.15p3, when the undocumented reverse_proxy_panel_allowed=sites option is manually enabled, allows SQL Injection.
PUBLISHED: 2020-02-25
VDSM and libvirt in Red Hat Enterprise Virtualization Hypervisor (aka RHEV-H) 7-7.x before 7-7.2-20151119.0 and 6-6.x before 6-6.7-20151117.0 as packaged in Red Hat Enterprise Virtualization before 3.5.6 when VSDM is run with -spice disable-ticketing and a VM is suspended and then restored, allows r...