The history of the password is one of increasing complexity until one day they weren’t needed at all.
For a long time passwords were the de facto standard for information security. Any time you’d sign up with a web service provider you would set up a username and a password so that the service could authenticate you. As services were hacked and passwords exploited it became apparent that increased security standards were needed. Developers responded by introducing simple password hashing (using MD5 or SHA1) so that databases would never hold the original password. The theory was that since you can’t easily reverse a hash then the passwords were secure. Unfortunately, users continued to enter passwords that were simple to guess (“abc123”, “qwerty” etc) and it wasn’t long before cracking sites published “rainbow tables” where the hashes for common passwords, and multiple combinations thereof, were revealed. Having stolen the contents of a database, the thief simply had to do a series of reverse lookups of the hashes within to immediately reveal the original passwords.
It should be remembered that people often reuse their passwords across multiple sites. Therefore a compromise in one meant a compromise in all the others. Cracking sites soon published scripts that would trigger a chain of hacks against a user’s online identity in seconds. By the time the original site was aware of the intrusion many of its customers were fatally compromised.
Security best practices were updated to abandon simple hashes in favour of time-consuming algorithms such as Bcrypt rendering the rainbow tables impractical. Users were informed that simple passwords were useless and the new normal was 16 characters long with upper and lower case letters, digits and symbols randomly mixed together and never to be reused.
And that was the breaking point. Many people just could not handle this arbitrary complexity in passwords and simply ignored the security advice. There had to be a better way, even if it meant a compromise.
One approach was to use protocols like OpenID and OAuth so that a trusted web service, such as Google or Twitter, would act as the credential holder for their customers. Signing up for a new service was a simple matter of clicking the “sign in with Google” button. While good for security it still centralised the credentials to a trusted third party. If your Google account was compromised then a sophisticated hacker could work their way through your online identity just as before.
To reduce the chance of compromising the central account, additional complexity was introduced. Now it became necessary for the user to use 2 factor authentication (2FA). This approach combined “something you know” (your password) with “something you have” (a device to generate codes based on a shared secret) to create a much higher barrier for attackers.
While this greatly improved the security of the centralised account, users still had to use complex passwords and now they had to enter a special number as well.
It was at this point that the Fast Identity Online (FIDO) Alliance began to push to introduce standard public key cryptography techniques instead of shared secrets (passwords and 2FA) to provide the strong authentication that users required without the complexity that had gone before. Working with tech giants such as Google and Apple these protocols have been integrated smoothly into smartphones, tablets, browsers and secure devices in preparation for a migration away from usernames and passwords.
From the FIDO Alliance White Paper:
FIDO2 uses public-key cryptography in order to create strong and unique credentials for every site with which a user needs to authenticate. Instead of a password, a user’s authenticator creates a public and private key and shares the public key with a given web application, while the private key is securely stored inside a piece of hardware, such as a security token or a secure storage space on the user’s phone. This private key is unextractable and not stored in a central location like with passwords. Biometric authentication may also be used with FIDO-enabled authenticators to ensure that the keys being accessed are being directly accessed by a certain user.
Here at Attestant we work hard to ensure that our security conforms to industry best practices and is constantly updated as new attack vectors come to light. By using FIDO2 we are able to remove entire classes of attacks against our servers and our customers’ information.
We will never have to ask you for a username and password. For your part, you only need to remember a PIN or use biometrics (such as facial recognition or a fingerprint) to access your device. The most important point is that your private details are never moved off your device - they remain completely under your control.
Over the course of time more websites will adopt this new security model, so don’t be surprised when someone asks you, “What happened to passwords?”
As always, if you are interested in using Attestant to meet your Ethereum 2 staking requirements, please get in touch using email@example.com. You may want to download our short data sheet (PDF) which covers our managed staking service.