The key in your pocket

Passwords are an outdated concept. They are stolen easily without the user being any the wiser. Not to mention the sheer number of passwords is overwhelming. Password manager applications are a common best practice workaround. As a result, the password to your password manager now becomes your Achilles’ heel with nearly as devastating consequences as for the Greek hero that coined the term. Which is why most security-oriented services have begun encouraging its users to utilize additional ways of securing logins, typically involving mobile phones.

Mobile phones are a logical choice for a hardware security device. They may not be ultimately secure, but their physical security tends to be fairly good. Most people guard their mobile phones carefully and have it near or in their hands at virtually all times. Losing a mobile phone is far more upsetting than losing a wallet these days. And because most people are always connected, mobile phones also tend to hold all the passwords and access tokens – even though entering them can be a pain. So why not do away with the song and dance of user names and passwords? Your device is already your key.

It’s not a big leap to recognize, it is much the same for all devices you own. Why keep entering passwords that are usually far from secure into every one of them? What if each device or application carried its own, unique set of keys? Skipping the pomp and circumstance of user names can dramatically simplify life for users while making them more secure.

Your devices hold the keys to your identity and can authorize further applications or devices. You can think of this process as cloning the keys to your house: of course, you must have a key to clone. If you lose all keys, you need to call the key service – which is what access recovery for your account is all about and it’s also covered below. But to avoid this it makes sense to always have at least two devices authorized, and one of them should be a mobile phone.

A practical example

Sarah signs up for Vereign using her Firefox browser on her desktop and sets up her Vereign identity. The browser has opened the account with a set of keys generated locally and stored in the encrypted storage of Firefox, secured with the Personal Identification Number (PIN) Sarah chose during sign-up. Her Firefox browser is now a fully authenticated access device. Next time Sarah visits app.vereign.com with this browser she simply enters her PIN and is logged in securely.

Sarah would also like to see her dashboard on the mobile phone. So in her Firefox browser she selects “Add mobile device” in the Vereign dashboard, showing her a QR code that she can use to add another device. Sarah takes her mobile phone and opens app.vereign.com on her preferred browser and selects “Authenticate new mobile device” which brings up a QR code scanner on her mobile. She scans the QR code in her Firefox browser – and finds that she now has access to the dashboard on the mobile phone.

Like the Firefox browser on her desktop, the browser on her mobile phone has generated its own set of unique keys which are now authorized to access her identity. They are now stored in the encrypted browser storage on her mobile device, again encrypted with PIN.

Because she uses Gmail, Sarah installs the Vereign Beta for Gmail extension for Google Chrome on her desktop. In order to authorize Google Chrome for access, she once more visits app.vereign.com on Google Chrome, selects “Access” and gets a QR code to authenticate the browser. On her mobile phone she visits the dashboard, selects to authenticate another device, scans the code and thus authenticates her Chrome browser.

Sarah now has three devices fully authenticated against her Vereign identity. Each has its own, unique set of keys in encrypted storage on the local device only. Each device has its own PIN number, although Sarah might of course for convenience re-use the PIN for both browsers on her desktop, at least. The server never had access to the private keys and could thus not compromise them. Neither can loss of keys on one device compromise another.

Stuff happens

But what if Sarah were to lose a device, or an attacker managed to compromise one of her access devices? Stuff happens. Mobile phones break, get stolen, hard disks get corrupted, houses burn down. Without wanting to go into too much detail, the Vereign answer to this has two components.

One is full transparency and accountability to the user. Each modification of access devices, as well as each interaction with the Vereign identity leaves an audit trail on a blockchain that is visible to Sarah only. If anyone added devices she did not want to have access, she’d know it immediately. Same for any kind of transaction with her identity that she did not mean to conduct.

The other is an escrow system where Sarah can choose aunt Emma as her trustee. Emma cannot access Sarah’s identity. But she can add or remove devices for Sarah’s identity. Although of course this would again leave an audit trail for Sarah on her audit trail blockchain. So Emma could not abuse this feature without Sarah learning about it immediately.

There are of course many details to both, but this ultimately creates a robust set of controls for our identity in which we can add layers of protection that are based on our actual social environment and situation.

Passwords not required.

More Reading

Want to know how this looks like? Check out

And of course please head on over to our Welcome to our journey introduction in case you hadn’t done so already.

1 Like