Lessons from LinkedIn BreachSecurity Expert: Outdated Tech Puts Organizations at Risk
Online account breaches, like the high-profile breach of user passwords housed by LinkedIn, prove organizations and institutions need a renewed focus on password protection.
But Araxid's Brent Williams says online password protection doesn't have to be complex. In fact, most organizations could enhance password security and privacy controls with a few simple changes.
For Williams, the future of online security will be built upon trust, not logins and passwords. But trust requires organizations to change the way they think about security, and their users.
"Trust slates are actually looking at identity in a fundamentally different way," he says. "You might be able to pass the authentication, but what other indicators do you have that you might actually be the person that we claim you are, or what indicators are there that you definitely are the person that you claim to be, and even might have the authentication credentials to be?"
Williams says that new level of trust assertion and trusted identities will be the foundation for the next generation of identity management on the Internet.As password vulnerabilities are continually exposed, the industry will have to change its thinking, and move away from antiquated practices, like password hashing, he says.
During this interview, Williams discusses:
- The fundamental security flaws of logins and passwords;
- Why and how hashed password lists can be cracked; and
- How the next generation of online user authentication will rely on trust.
With more than 20 years of experience as a government and industry practitioner, Williams has experience in the global marketplace, including the delivery of secure solutions in Europe, Asia, Africa and the Americas. He has senior-level strategic experience with government information security solutions, which has included drafting national-level policy related to authentication into secure systems for the White House and developing security policy guidelines with the National Institutes of Standards and Technology. Before Araxid, Williams served as the chief technology officer for Anakam Inc., which was acquired by Equifax in 2010.
TRACY KITTEN: We've been talking about vulnerabilities to the commonly used password protection method known as hashing, and it's gotten a lot of attention in the last week after a breach at LinkedIn resulted in the possible exposure of more than 6.5 million passwords associated with the social networking site's accounts. What makes hashing so vulnerable?
WILLIAMS: First of all, hashing in and of itself is not a bad security practice. It's more of the types of hashing algorithms and the hashing mechanisms that people use nowadays. They've modernized significantly in the past few years, such that standards like SHA-256 actually make a far more complex hash, a 256-bit depth hash that actually allows us to protect and secure those kinds of passwords much longer. So if you think about a hashing algorithm in and of itself, it's actually a one-way algorithm. It takes one piece of input and converts it into a result that you can't go backwards and figure it out.
Early algorithms that did that didn't do computational analysis to such a depth that it can't be broken with today's simple computing platforms. The LinkedIn hack, as well as many of the other hacks that have occurred with the hashing algorithm, those hacks are actually occurring using old rudimentary hashing algorithms. What we've done is made that far more difficult for people to hash using new hashing functions, but in the end hashing is not the only thing you want to put in place as a security function.
Salted and Unsalted Hashes
KITTEN: Let's talk a little bit about hashing itself, and there's been a lot of discussion around salted hashes vs. unsalted hashes. What security benefits do salted hashes have when compared with unsalted hashes, like the ones that we saw exposed in the LinkedIn breach?
WILLIAMS: When we look at a salted hash vs. an unsalted hash, an unsalted hash will take the password and actually place the password through the hashing algorithm and present the result in post-hash numerical representation of the password. The challenge is those passwords - if you used a password like HelloBrent as your password - each time somebody used HelloBrent it would result in the same exact hash. The unique piece about password hashing functions is each time they get used they produce the same results. That's how come we use them in the encryption processes and digital signature processes, because we know if you take the same thing in and you push it through on the other side what comes out of the hashing function is exactly the same each and every time, but you can't reverse it to figure out what the password is. So by virtue of pushing what's called a dictionary attack through a hashing function, I can actually figure out what the password is by testing a whole section of dictionary words against an algorithm and then produce all the hashed functions. When the hash function matches, that means that the password was actually what the user used.
Salting actually adds variability to that. We add characters on to the end of your password such that when we hash it, it's different than just your password alone. That steps up the security a little bit. Now the challenge that we have with salting today is that salting with too few characters - say adding just a number sign at the end of somebody's password or adding a couple of characters at the end of their passwords, and it's the same characters for every password - does not create enough variability across the data set that it can't be brute-force attacked.
Further, if you use a salting function that does not have a very strong depth to it, it will be very easily attacked. What we recommend is actually using a salting function that's random; in other words it generates a new salt for each password and the salt is at least as deep as the hashing function itself. So if it's a 256-bit hashing function, your salt function should be 256 bits also. It's essentially a cryptographically secure random number generator that generates that code that goes along with your password that makes each and every hash completely different and unique.
KITTEN: LinkedIn was not the only site to get hit last week. Similar password breaches also affected online dating site eHarmony, online music site Last.fm, and now online gaming site League of Legends. Do you think that all of these breaches are connected and how far back in time might they go?
WILLIAMS: The reality is they probably go back much further in time and they will continue to go on in time. It turns out that they're probably connected by the type of attack used. The type of attack typically used in order to get to a hashing function is actually a SQL injection-type attack because we can actually inject into the database code itself. The SQL attack will actually allow us to test out the series of passwords in the actual SQL injection itself.
Now what we've done is we've said, "Let's back out of this process itself and look at alternatives to the traditional password and username solutions that we've been using for so long." National level policy documents like the National Strategy for Trusted Identities in Cyberspace has long recognized that username and password alone is a fundamental vulnerability, and it's because unsafe coding practices and deceptive types of activities by those trying to get access to those databases have been able to either brute force or push their way through with new technologies or new processing speeds to be able to get through the hashing functions. So consequently what can we do as an alternative?
We've really pushed the limit on creating or trusting different players who have usernames and passwords, so what we recommend instead is actually moving to platforms where we have shared identity providers. Some of the leaders in that space are organizations like Google, Microsoft and eBay and what they're doing is actually getting to the point where their single identity is only used once to use on their website and then that in turn creates a federated token which is fundamentally unique that gets you into the target website that you're trying to get into. Now that works well and good for people who are fundamentally conducting e-commerce and allowing you into a social networking site or a dating website, but there are lots of other technologies that are coming along that I will be happy to share with you that replace even more sensitive websites like bank websites, healthcare websites and government websites.
KITTEN: What would some of those technologies or solutions be?
WILLIAMS: As we've been looking at strong multi-factor solutions, the number of providers in the country who are capable of actually delivering multi-factor authentication in a federated solution where the real identity of the individual is much more important than just their ability to produce a username and password - the fundamental presence of these providers is actually fairly low. What Araxid has actually done is create a trust network where the dependency on the real identity of the individual is significantly higher than say one's Google username and password which may have absolutely nothing to do with who they actually are.
Consequently, these trust slates are actually looking at identity in a fundamentally different way. You might be able to pass the authentication but what other indicators do you have that you might actually be the person that we claim you are, or what indicators are there that you definitely are the person that you claim to be and even might have the authentication credentials to be? This new level of trust assertion and trusted identities is actually the next generation of identities on the Internet.
Storing Hashed Passwords
KITTEN: Let's go back for a second and talk about hashed passwords, because they're still the most commonly used. How are hashed passwords typically stored?
WILLIAMS: In the older types of data structures, they're most commonly stored as the actual hashed function itself. A username or a hashed version of the username will be stored in a data structure alongside relationally with the hashed version of the password. The actual password is never stored, so what ends up happening is the user presents themselves at the websites, enters their username and password and they take the same hashing function that was used to create the stored username and password and they run the username and password back through that same hashing function. If the new username and password post-hash are equal to the username and password pre-hash, then it means that the username and password presented on the repeat attempt getting in are actually equivalent to the ones that were used the first time.
KITTEN: Now when it comes to some of these databases that house or host these hashed password lists, do online entities typically manage those password lists themselves, or do they often outsource to a third party to manage their hashed databases?
WILLIAMS: Here's the reason that trust is so important in this. You never are quite sure who's got control over those databases. If you're building a website, what you typically might do as a new website owner is you might actually code and build that data structure yourself. Eventually what you'll probably do is move that to a directory structure or a validation structure that might be provided by another software provider such as a software service provider that might have an electronic health record system that accesses a username and password repository that's built into the application. In each case, you've got a variety if instantiations. Usually less mature applications either code it themselves or outsource it to a fully independent third party. Moderately mature applications will then move to a data structure that's managed by the application itself, and then fully mature ones will be able to take advantage of much more secure username/password storage schema that are actually much more dependent upon the user interaction as well as the validation of the security of the provider of the system.
For example, the SaaS provider or the software provider or the service provider will have been through an assessment that actually validates that they're using a proper hashing algorithm like SHA-256 or something along those lines.
Managing Third Parties
KITTEN: When it comes to organizations working with third parties or perhaps vendors, what types of questions should organizations be asking to ensure that these third parties they're working with are taking precautions to protect online passwords?
WILLIAMS: That's a great question. Unfortunately, the questions haven't been well standardized and well formatted. Depending upon the type of industry you're in, they have a series of standards that might be used in order to implement the security. We tend to do a lot of assessments like an ISO-27001 assessment or a FISMA assessment where we're not actually validating that the organization is truly secure, but we're validating that they follow a series of processes that should make them secure if their coding was actually done properly. We continue to go back to the failed coding practices.
Further, many of the security vulnerabilities that are created - such as implementing a hashing function improperly - can be as simple as typing a few errors in code and not calling the right routine off of the application stack. In those particular cases, you're really counting on human error and so we go back again to the trust concept. What's the trust and the reputation of the people conducting the development or the operations of the system, and have they ever been assessed by independent parties who actually know how to do the testing? Validating that the SHA-256 algorithm's actually implemented properly or that the salting algorithm's actually implemented properly, there's a series of code providers and organizations like Veracode that do a great job where they're actually validating that the coding practices are done properly.
KITTEN: What are some of the most common mistakes that you see organizations making when it comes to password and login protections?
WILLIAMS: The most common mistakes that they have are seeking more out of the process then they can actually trust. LinkedIn is a great example of an organization that has continued to demand more and more out of their website and their business functionality, at the same time now forwarding any higher level of security or assuredness that the individual actually conducting the transaction is the individual that they intend to be conducting a transaction. To take a look at the services available on the marketplace today, there's an overwhelming amount of authentication capabilities that are out there. Whether you do username and password or you do username and token, or you do username and one-time password to a cell phone, the challenge is we don't know who those tokens are actually issued to. I'm able to set up a LinkedIn account without much validation and verification that I actually exist as a human being. Then, what happens if I'm compromised later on? The ability for me to actually monitor an organization and monitor a user to see if they're doing the things that would indicate to me that they're not who they say they are is completely missing in the marketplace at this point.
Stronger Protection Tips
KITTEN: Before we close, what tips would you offer to organizations listening to this interview about stronger password protection?
WILLIAMS: The first thing I would offer to an organization is take advantage of what I call the level-one identity providers that are on the marketplace today. The level-one identity providers are the Google's, the Microsoft's or the eBay's of the world that have built a federated identity management platform where you can use their authentication login in order to get access to your site and not have to create a new identity in your system. Actually use people's systems that you can actually trust and don't force the creation of a new username and password in your system. A guy like me would actually have to have 2,000 unique usernames and 2,000 unique passwords in order to create differentiation, because what I end up doing is creating one username and one password, one I use all the time on most of my major sites. Instead, move to the point that you're actually using the open ID login availability from a lot of the other IT providers so you're actually consolidating down to one login and one identity service provider. That's great in the instance that it's what we call a level-one identity, one where I really don't care if you're Tracy that much because I just want to make sure the person who created the account is continuing to use the account.
In the world where we're actually trying to create trust with identities, whether it's getting access to your healthcare information, your government benefits information, your money or other private information, the world's significantly different. In those worlds, we've got to actually create trusted environments where we know that the carbon-based life form that we intend to be doing business with on one end of the transaction is actually the carbon-based life form we intend to be doing business with. Further, we have to be able to attach them logically to the real records inside the system. What we've got to start looking to as an organization or as organizations in the e-commerce marketplace is building those trusted connections between the real end users, not just usernames and passwords, but the real end users and their data sets that are used to conduct transactions within our enterprise.