Perimeter
6/11/2012
03:57 PM
Amy DeCarlo
Amy DeCarlo
Commentary
Connect Directly
RSS
E-Mail
50%
50%

LinkedIn: Making Insecure Connections

The recent breach of millions of LinkedIn passwords highlights an all-too-common issue

We spend a considerable amount of time in the security industry talking about sophisticated security protections and innovative practices that can be applied to protect critical information. Biometrics, cryptography, secure tokens, and a variety of other technologies can go a long way toward assuring organizations their data is safe. Yet for all the emphasis on innovations in security and safeguarding the highest value data, too often the basics are left uncovered.

The breach of a reported 6.5 million LinkedIn passwords last week is a prime example of what at least initially appears to be a failure at three levels: in policy, in practice, and in communication.

LinkedIn, which doesn’t have a chief information officer, much less a chief information security officer, clearly applied what appears to be a substandard policy to securing passwords of users, many of which may be high-value targets in and of themselves given the power and influence of many of the professionals associated with those access codes. The breach, which was discovered when the passwords showed up on a Russian hacking forum last week, exposed whatever cryptographic controls the social business network used to secure the passwords was far too simplistic.

Communications from LinkedIn about the breach were also unclear. In a blog post written by Vicente Silveira, a director at the company, LinkedIn admitted that “a small subset of the hashed passwords was decoded and published.” It wasn’t able to quantify how many. While the company is investigating the incident, the company’s ambiguity about the breach -- or apparent security expertise or leadership -- is hardly a confidence-inducing move. In the meantime, LinkedIn cancelled the passwords it believed were “at the greatest risk.” Also in a somewhat confusing move, the company says it “is disabling the passwords of any other members that we believe could potentially be affected.”

LinkedIn dug a deeper hole for itself by admitting that it isn’t sure whether any other data was compromised. Nor apparently does the company seem to understand that just because the hackers haven’t apparently been able to crack the cryptographic code for all the passwords that they won’t be able to do so eventually. After all, they have the most important element in their possession already: the passwords themselves.

Most data breaches like the one that befell LinkedIn are too commonplace to make headlines. What distinguished this from the run-of-the-mill password hack attack was the target. Essentially, the breach revealed surprisingly poorly executed security controls by a company that until now has been trusted by millions of professionals to keep them connected.

If anything positive comes of the incident, it is that it serves a reminder to everyone about the importance of being vigilant about managing their own passwords well. Simple tips like resetting passwords frequently and not reusing passwords can go a long way toward protecting their data, and with it, their identities.

Amy DeCarlo is principal analyst for security and data center services at Current Analysis

Amy brings 17 years of IT industry experience to her position as Principal Analyst, Security and Data Center Services. Amy assesses the managed IT services sector, with an emphasis on security and data center solutions delivered through the cloud including on demand ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.