One of Tozny’s primary goals is to reduce the use of passwords for authentication. As a result, requiring a password to register with Tozny Platform and log in to our new Dashboard has struck a few people as odd. We wanted to take a moment and explain why passwords are being used in this case and pave the way forward towards a password-free future.
Interesting in learning more about Tonzy’s encryption solutions? Check out TozStore or TozID, Tozny’s secure identity management solution with end-to-end encryption built in. Our SDKs and toolkits are designed to simplify and expedite the deployment of solutions that address your encryption needs. |
Traditional Password Authentication
Traditionally, systems require users to maintain knowledge of both a username and a password. The username is stored in plaintext in a database while the password is hashed using a simple, one-way algorithm and the hash is stored in the database. This system allows for efficient lookups of user identities and provides a relatively simple way to verify a user is who they say they are.
When logging in, users provide their username and password to the system. The system then hashes the provided password and compares the hashed output with a known hash from the database. If they match, the user proceeds. If they don’t, the login is rejected.
As simple as this sounds, people get it wrong all the time. Some platforms fail to hash passwords at all, storing the plaintext instead. Others forget to add random salts to the passwords while hashing, leading to a lookup table that exposes when two users have the same passwords. Still others implement weak hashing algorithms that can easily be broken with even consumer-grade hardware.
In all of these failure conditions, the breach of an authentication database can be tragic. If the platform is ever broken and the database leaked online, outside attackers can use the information it contains to potentially break into other systems as well! Users frequently reuse passwords for many sites, so sometimes knowing only the hash of a password is enough for an attacker to identify an easy-to-abuse target.
Tozny has no desire to maintain a password database, hashed or otherwise, so we never transmit your password over the wire. Instead, our Dashboard
implements a more transparent password verification scheme.
Transparent Password Verification
When you first register with Tozny, the site prompts for both your email address and a strong password. We encourage you to use a long, random password, preferably generated at random through and stored in a password manager to prevent your ever losing it.
Registration
The Dashboard application that authenticates directly to our platform. When you register, it creates your account for you, but it never gives us the password you’ve chosen. Instead, the application generates a random salt (a random, 16-byte string) and uses it with a password-based key derivation function (PBKDF2) to produce a static key for your account.
The PBKDF2 function is run 1000 times to produce the 32-byte key. The high number of iterations is negligible when you log in, but if someone were to attempt to guess your password by brute force, it will drastically slow them down (and give our system the time it needs to detect and block the attack).
Once a key is generated, the application uses that key to seed the creation of an Ed25519 public/private keypair using Libsodium.js. This keypair is used to cryptographically sign (and verify signatures of) arbitrary content using elliptic curves.
When you register with Tozny, the application sends the following information to Tozny:
- Your name
- Your email address
- The random 16-byte salt used to derive your signing key
- The public component of your derived Ed25519 keypair
If you sign up for a paid account, your billing information is managed securely through Stripe. Your chosen password is never stored in the browser or sent over the Internet to a third party. All we need is your public key to verify signatures in the future.
Authentication
The next time you log into the Dashboard, you are asked to provide your email address and password. Instead of submitting these to the server for verification, the application instead submits your email address and requests an authentication challenge. The server looks up your account (based on your email address) and responds with your original 16-byte salt and an additional 32-byte random challenge nonce.
This nonce is stored on the server side, so the authentication challenge can only be used once. If authentication fails, a new challenge must be issued.
The application will use your salt and your provided password to regenerate your account’s static key (again using 1000 rounds of PBKDF2). This key will be the exact same as the one generated during initial registration – when supplied to Libsodium.js to seed an Ed25519 keypair, it will generate the same keypair generated during registration.
The application will then use the private component of your derived keypair to sign the random nonce. It will then complete the authentication challenge by sending the server:
- Your email address
- The nonce that was signed
- Your signature on the nonce
The server uses your stored public key to verify the signature on the nonce and, if it’s valid, establishes a secure session for you.
Password-Authenticated Key Exchange
Some developers might recognize this flow and suggest it’s similar to a password-authenticated key exchange (PAKE) routine. In practice, it is very similar. In a PAKE routine, two parties that share a known password use their independent knowledge of that password (and specific mathematic operations) to establish a separate key without exchanging that key itself over the Internet.
A PAKE routine can be used to negotiate a shared, symmetric encryption key used for communication. It’s also used primarily to mutually verify the identities of the client and the server to one another when the identity of either is suspect.
In Tozny’s case, we are relying heavily on the fact that communication always happens with a known party – the Tozny Dashboard – and that party’s identity is already established by nature of the SSL certificate it uses for communication. Given that all operations between the client and server occur over HTTPS, there is also no need for an independently negotiated encryption key. All our model hopes to verify is that the client authenticating does, in fact, have knowledge of the password used during registration.
A Password-free Future
The above illustration covers registration and authentication, but there is a similar model underlying the cryptographic operations that take place within the Dashboard. At no time does Tozny ever have knowledge of your password or the signing/cryptographic keys derived from it – you can authenticate and decrypt your data, but we could never do so even if we wanted to.
This being said, we are currently working to add extra layers of security on your account with various two-factor implementations. Knowledge of a password plus possession of a physical, independently-identifiable device will make your account even more secure.
Regardless, we are living in a world where you can securely use Tozny’s products without us ever being able to know the information you use to authenticate – be that a complex password or a key embedded in a mobile device. Today, Tozny Platform is completely secure and takes proactive steps to prevent any form of account breach or abuse.
And we continue to work to make it even more so.
In the present, take some time to proactively protect your customers’ data by signing up for TozStore or TozID account today.