Putting an end to the password jungle

With my blog audience all being experts in the IT industry (I presume), I think we are all too familiar with the problems of classic password security mechanisms.

Humans are just not good at remembering long meaningless strings of tokens, especially if they need to be changed every so many months and having to keep track of many of those at the same time.
Some security experts blame humans. They say you should create strong passwords, not use a single password for different purposes, not write them down on paper – or worse – in an unencrypted form somewhere on your computer.

I disagree. I think the fundamental problem is within information technology itself. We invented computers to make life easier for ourselves – well, actually, that’s not true, ironically we invented them primarily to break military encryption codes. But the widespread adoption of computing happened because of the promise of making our lives easier.

I myself use a password manager (KeePass) to make my life a bit easier. There are many password manager tools available, and they solve part of the problem: keeping track of what password was used for what purpose. I now only need to remember one (hopefully, strong enough) password to access the password database and from there I just use the tool to log me in to websites, corporate networks and other services (let’s refer to all of those as “cloud servers”).

The many problems with passwords

The fundamental problem remains – even when using a password manager: passwords are no good for protecting our sensitive data or identity.

Plus, even the best password managers (I’ve tried a few) are not easy to work with for most people. For me being an IT expert it works reasonably well and I know how to set up auto-fill forms and stuff like that. For non-IT people it is a mission impossible to use such tools to generate a new password and make it work if some website or application asks for that. Not even mentioning the burden it can be to have a password changed on a server and keeping it in sync with the password manager. Or the de facto method of resetting a lost password: you get a new password sent to you via (completely unencrypted) plain-text email!

And there are more fundamental problems with the concept of user id/password combinations. For starters, each server has to store a server-side database with user ids, passwords and other information. If that database gets compromised, then the strongest password – based on the best security standards – is not going to protect us from severe issues. Also, in many cases such a breach will go undetected – or the owners of the service might keep their mouth shut about it to prevent negative publicity. There are issues with Man-in-the-middle or Man-in-the-browser attacks – even if both client and server are using strong authentication, if someone can sniff your passwords or session tokens, you still are in trouble. There is no good way to delegate access rights to someone without revealing your entire password. There is no way (at all) for cloud services to verify the true identity of the user (depending on your point of view, anonymity might be a good or bad thing – or both at the same time) – unless they implement expensive ways of validation (many banks do this for their customers and many companies as well for private network access – think security tokens, two-factor authentication and the like).

End users are vulnerable to viruses, Trojan horses and social engineering (phishing) – again, you might argue that this is not an IT problem, but denying our responsibility doesn’t lead us to a solution. With 75% of the worldwide population online on the internet, we cannot expect billions of people to use strong passwords and honor all the other best practices.

And now because of PRISM-gate, we are all too aware of the fact that we can no longer trust web services, PCs, laptops, our tablets and smartphones. We need to realize that security agencies have full access to our private information, and this includes password databases stored either on our devices or in the cloud in some way. Other obscure organizations (foreign governments, organized crime) might have similar access to our equipment and the problem is twofold: they probably use access to our data to get to our password information, and they use password information saved elsewhere to get access to our devices.

Which brings us to the next problem: If a password is static (in between periodic changes) then there is no way to know if it has been compromised. So obscure organizations might be able to use our passwords without us knowing about it. Perfect recipe for identity theft and other nasty problems.

Existing (and upcoming) solutions

So why is the majority of IT solutions still using some form of user id and password mechanism for authentication? Probably because there is no alternative, at least not a simple one. An alternative for passwords is way, way overdue but until something better emerges on the horizon, we’re stuck.

Many individuals and organizations have tried to solve the problem and some solutions are announced and in the making. Mentioning a few:

• (Online) password managers – They claim all kinds of things but they mostly are a) proprietary, b) single point of failure, c) still generating user ids and passwords to be used to log in to other servers. They are not password alternatives, they are a password problem workaround (but they solve a big part of the problem)
• Biometric authentication – In my opinion, these will never become mainstream because of obscurity of the algorithms and the fundamental problem of what to do when your biometric information (say, a fingerprint) gets compromised. You cannot just expire your fingerprint and request a new one
• 2-factor authentication – Works well but is costly and still not user friendly. Does not prevent completely from man-in-the-middle attacks or otherwise compromised end-user devices
• Single Sign-on services (OpenID, Google ID, Facebook logins, etc) – Mostly proprietary and typically one company or organization is in full control. If that company gets hacked then the hacker can access all sites using the single sign-on identity. OpenID is a step in the right direction but there’s a lot of criticism pointing to fundamental security flaws
• OAuth – merely a protocol for authorizing apps (like on your iPhone) to servers. Does solve a few problems but by far not all of them. Besides – if you change your password, does that mean OAuth-enabled apps are no longer granted access? If a hacker gets your OAuth “valet” key, do they need your password to get access to your data? Is a secure password protecting you from this issue?
• SAML – a protocol (not a complete toolset) that defines XML standards on exchanging security information. Solves a big part of the problem.
• Yubikey – a small USB device that generates strong passwords. Interesting technology and I think devices like this solve another important part of the problem.

And Google seems to be working on something new: Google’s alternative to the password which looks promising – but that was announced a year ago and recently they acquired Slicklogin – which makes you wonder if they are serious about the password replacement project in the first place. Besides, knowing Google it will probably end up being a closed, proprietary standard which has to generate revenue for them – making large scale adoption near impossible. Otherwise they would have already invited the rest of the world helping them defining standards and further developments.

If you google the web you will find many more initiatives. Kudos for the people trying to solve the password misery – and some have actually come up with very smart, creative and interesting solutions.

So it looks like much of the fundamental technology to solve the password misery forever, already exists. It’s just that the pieces don’t make the full puzzle yet and some pieces just don’t fit. And some key pieces are still missing.

The ultimate solution

So why am I bringing up this topic instead of sitting back, relaxing and waiting until a Google or Facebook, or other company comes up with the ultimate solution?

I don’t think this problem should be solved by a single company. I have been thinking about these problems since about two years ago and tried to come up with a solution – so I spent time designing something high-level and actually submitted it as an idea for EMC’s innovation conference (EMC colleagues: you can find my idea on my internal ONE EMC page). It got some traction but then I was notified that our security division, RSA, was already working on a similar project: RSA Cloud Trust Authority – which is an interesting technology – but does not solve the exact issues I am thinking about. It’s focus is Business-to-business.In the past years many announcements were made by various organizations and individuals, but still there seems to be no ultimate solution that solves all problems. So, if I get positive response to this blogpost, I might file the idea again for this year’s conference – so let me know what you think!

Now, I’m not a developer, or cryptographer, and I’m pretty busy with my “real” job (helping customers optimize databases and making them more cost-efficient) but still I tried to lay down a concept framework to solve the password problem – or more generally speaking – the authentication problem – once and for all. I’m not claiming to have a complete and working solution, I just attempted to set the stage with requirements and a high-level design. A real working solution would require lots of extra work with many people involved from different organizations (or just individuals) to verify security mechanisms, further develop protocols, etc.

Worth noting that I just combined existing technologies and principles together. So if you think “nothing new here” – that’s right, I’m just proposing a standard that is made up of the great work done already by many others plus a few additional thoughts.

CLASS

The proposal I filed for our innovation conference was called CLASS – Cloud Authentication and Single Signon. The idea was very similar to existing authentication methods currently in use for websites. There are Root and leaf Certificate Authorities, servers, clients, various authentication levels and the like. But now applied to user authentication and validation instead of web servers – and improving on some of the weaknesses in Web PKI infrastructure on which I have written before.

I will go in more detail in the follow-up to this blog post, but fundamentally this is how it works:

• A Peer-to-peer network exists that keeps track of public information of users, services, authorities etc. Nobody owns or controls this network. A good example of such a network is the Bitcoin network
• End users create a keyring (using a user-friendly app) that is protected by a public/private key mechanism. The private key is protected in such a way that the user cannot accidentally destroy or reveal the private key (in other words, it is never stored on an end-user computing device – so it is either stored “in the cloud” or on a local appliance such as the Yubikey or similar hardware tokens. I’m aware of the weaknesses of both approaches but stay tuned – there are solutions to these problems)
• End users fill the keyring with fields containing personal information
• One or more certificate authorities sign the keyring to validate the user is who he claims to be. This can be done at different guarantee levels – from email validated (basic) to micropayment validated (advanced) – to governmental approval based on physical passport or social security number (strong) – or even stronger guarantee levels such as enforced by notaries or banks – and the authority may sign only specific fields in the keyring if needed.
• Users log in to cloud application services where they specify what information is needed by the service to be granted access. The end user has full control over what fields to reveal.
• Each login is audited and can be verified (or even acknowledged – out of band) by the end user – so secret logins with stolen password or keys is not possible
• The application service can verify the authenticity of the user by checking for certificates (if the user allows!)
• Revoke or expiration of one certificate by one of the authorities does not compromise the entire keyring (so no single authority controls your digital existence)
• The keyring may hold information for each application service specifying things like user id, full name, profile picture, credit card numbers or whatever – so even with one keyring a user can have different virtual identities
• A user may also define multiple keyrings (regular users would not do that but people living in non-democratic countries might, also good for developers or system administrators)
• A user may (temporary) delegate authentication to another user (of course, audited and secured).
• Off-line authentication option that even extends to the physical world (think access via keycard to corporate buildings, your house, your car) – by storing offline copies of (parts of the) keyring and certificates

An end user does not have to bother with all of these details. He would (ideally, once in a lifetime) create a keyring. Then register some personal information once, and have it signed and maybe re-signed every so many years. When buying a new end-user device such as a tablet, smartphone or computer, he would register the keyring with the new device. These actions only need to be done once in a while.

In between those actions, he can log in to any application or service without providing passwords or user ids. If the device gets stolen it can be expired from the keyring, and a compromised device is not much good to someone with wrong intentions – because any attempt to log in will be audited and visible by the end user. And for additional security there’s the out-of-band validation mechanism with USB-like security tokens or something similar (which means the user has to press a button on something that looks like a USB stick or dongle, before getting access to his bank account). If a hacker gets full access to, say, a server running a web shop, that’s not a big issue anymore because the webshop no longer stores the user details (it will just access them – only when needed – from the cloud after being authenticated). So even simple web services run by inexperienced administrators can be secure (if there’s nothing to steal then why break in in the first place). The user can use his single keyring to log in to his employer’s private network if that private network provided a certificate for (parts of) the keyring – again with out-of-band validation for each login if needed.

In my follow-up post I will go in more details on the requirements, benefits, challenges and other details of such a solution. For now, here is a small teaser that underlines the benefits of a universal authentication mechanism:

Given the amount of SPAM currently handled by the world’s email system, and the burden it is for administrators and end users, consider a situation where email servers will only transfer emails that are signed by the keyring mechanism I described. The minimum would be micropayment (advanced) validation level. Any email not signed this way ends up in a “potential junk” email box. If such a system gets adopted at large scale, then all spammers either have to reveal their identity somehow, or accept that 99% of all users worldwide will not even receive spam at all.

Comments welcome (or reply privately)!