While we are working on a whitepaper that will have a more in-depth description of the architecture and a more extensive security analysis, I thought it'd be worth writing a primer on why Chiff is more secure than using passwords.

Password authentication

Passwords are one of the biggest practical problems facing security engineers today. In fact, as the usability researcher Angela Sasse puts it:

It's hard to think of a worse authentication mechanism than passwords, given what we know about human memory: people can't remember infrequently-used, frequently-changed, or many similar items; we can't forget on demand; recall is harder than recognition; and non-meaningful words are more difficult.[1]

This quote encompasses both the usability and security issues that come along with passwords, which are at variance with each other: to achieve reasonable security with password authentication, the passwords should be unique per website, sufficiently long and difficult to guess, all of which contribute to a lot of different passwords that are impossible to remember. This isn't breaking news: security researchers have known for decades that passwords aren't the best way of authenticating ourselves. There are sufficient cryptographic protocols available that allow for more secure authentication, so why are we still using them for almost every website?

I'm not really sure, but I think it has to do with the fact that the internet wasn't invented in a day, but has grown to be an ecosystem in the past 50 years where not every design choice is the most optimal one, especially for security, which wasn't really an issue in the early days of the internet. The fact that the whole world uses email as a primary means of online communication while it doesn't use any encryption is a similar pattern.

So what's the real risk with using passwords? What usually happens is:

1. A website gets hacked. This happens all the time and there's not much you can do about it (unless you're the owner of a big website).
2. Its database with password hashes is dumped on Pastebin or sold on the darkweb.
3. Dictionary and bruteforcing attacks are run on the password database, which implies that:
   • Predictable passwords are cracked, independent of whether they are long or short. Unfortunately people are more predictable than they think (you are not the first to think that 12345qwerty12345 is hard to guess..). (~35% for Linkedin)
   • Passwords that are too short or use a small character set are cracked (anything less than 10 character is definitely at risk). (~65% for Linkedin)
   • In some cases it doesn't even matter how good your password is, because the website messes up. This result may be that passwords can be read in plaintext (Twitter) or cracked easily (Adobe).

4) If your password gets cracked and you use this password for other websites as well, the attacker has access to your account on those websites.

Anyway, it usually doesn't take a lot of effort for us to convince people that password authentication is unusable or insecure. Most people kind of know that using mycat'sname123 as a password for almost every website isn't very secure, but just do it anyway because it's too much trouble to set up a more secure password system for themselves. And that's exactly why we think that Chiff may be a solution for a lot of people :).

Time for a change

We believe that the time for change is now, mainly due to the fact that smartphones have become commonplace and are more and more equipped with advanced biometric authentication systems and trusted execution environments. Chiff leverages this by allowing users to log into websites with the biometric authentication system of their phone. At least that's what the user experience should be.

With this user experience in mind, there are multiple ways to design the authentication process:

Strong authentication

Strong authentication means that no secret (such as a password) is sent over a communication channel. Password authentication is obviously not strong, since the password needs to be sent to the server, where it is being checked. There are various protocols that can accomplish strong authentication, for example challenge-response protocols. This means a challenge is sent by the server to the client, who applies a cryptographic operation on the challenge with a secret only the client knows, and sends back the response. If the response is correct, access is granted. In the new W3C WebAuthN candidate recommendation, strong authentication is used for the 'logging in with smartphone' use case described above.

Password authentication

In this approach, a unique (pseudo-)random password is generated for each website on the mobile device. When a user wants to log in, a request is sent to the mobile device. If the request is authorised by the user with his/her biometric traits, the password is sent back and automatically filled in the website using Javascript. Since this is sensitive information, it should be encrypted in transit.

Of these two approaches, strong authentication is preferred because it's more secure. However, the mayor drawback is that it needs be implemented at the backend of the server as well, so cooperation of the owner of the website is needed. The consequence is that it will take time before this method can really replace password authentication. The advantage of the password-based approach is that it works out of the box for every website, while still offering considerable security improvements over 'manual' password authentication, because it uses sufficiently strong passwords that are unique per website.

Chiff will use a combination of both approaches. That is, WebAuthN is used if the website conforms to the standard, where Chiff takes the Authenticator role of the standard. If WebAuthN is not available, the password-based approach is used. The good news is that the user doesn't have to worry about which of the methods is used under the hood, he always gets the most secure method available with exactly the same user experience.

Architecture

Since de WebAuthN is extensively explained in the proposed standard, I will focus on the security aspects of what makes Chiff unique: the password-based approach. To do so, it is worth discussing the key derivation scheme, password generation process, communication between browser and mobile device, security of stored data, 2-factor-authentication and backups.

Key derivation scheme

All cryptographic keys used in the architecture are derived from single 128-bit, randomly generated seed. From this seed, three keys are derived: the password key, the backup encryption key and the backup authentication keypair. The password key is used a seed to generate passwords, the backup encryption key and authentication keypair are used for backup purposes (what's in a name).

Password generation

Since a username is unique on a website, the combination URL + username is used as salt to generate a unique cryptographic key, which is used as a seed for in a CSPRNG. The bitstream that is produced by the CSPRNG is converted to a password. For the password generation, we use the process recommended by a researcher from Technical University Darmstadt, Moritz Horsch[2]. Furthermore, we also use the concept of Password Policy Documents (PPDs) to make sure the password will be accepted by the service. This is XML-standard where the password requirements are specified for every website.

Communication protocol

Besides sending the password from the client to the server, the password needs to be sent from the mobile device to the browser. All communication between browser and mobile device is end-to-end encrypted. Key establishment for a session is initiated by scanning a QR-code that is generated by the browser extension with your phone. We use Amazon SNS and SQS for simplicity and availability. Once the channels are set up for the session, all messages will be end-to-end encrypted. The protocol is formally verified using the applied pi calculus, to provide some assurance about its correctness.

Security of stored data

All sensitive data is only stored locally on the mobile device. While iOS is arguably the most secure OS that is currently on the market, it too has vulnerabilities that can be exploited. However, the process to obtain someone's passwords becomes fundamentally different from the process I described in the beginning of this article. Instead of hacking a website and getting results for about a lot of users at once, the attack needs to hack one individual phone to get someone's passwords. That's a lot more work per password, making the criminal business model much less interesting.

2-factor authentication

A method that greatly increases security is 2FA. A well-known method is TOTP, which is for example used by Google Authenticator. 2FA usually implies you need at least two of the following:

• Something you know
• Something you are
• Something you have

In the case of Google Authenticator in combination with a password, this is something you know (the password) and something you have (the phone, which is the only place where the secret is stored).

Since you don't have to remember any password with Chiff, something you know is out of the equation. You do need something you are (your biometric trait, such as fingerprint or face), but how about something you have? Since the passwords and cryptographic keys are only stored locally on your phone, you need to have that phone to authenticate. This would imply that Chiff is a 2FA method. However, you could argue that cracking the phone gives an attacker access to the secrets, defeating the 2FA part. For the whitepaper, We'll have to do some more research to come up with a definitive answer, but I'd argue that it would be a 1.5FA at least. A considerable improvement, especially taking into account that you don't have to remember anything for it :).

Backup

Since the data is only stored locally, losing your phone would mean losing access to all your accounts. Fortunately, we have come up with a backup scheme that fulfils the following requirements:

• You don't need to remember something to retrieve your data.
• The sensitive data isn't stored anywhere but your phone.
• It's uncomplicated to use

It works as follows:

1. When you install the app for the first time, twelve random words are shown. These twelve words represent the 128-bit seed where all cryptographic keys (including the passwords) are derived from.
2. You write these down on a piece of paper and store it securely (in a vault or something).
3. If you lose your phone, you can enter these twelve words into a freshly installed version of Chiff on your new phone and all passwords will be regenerated!

While the secret is the seed (=the twelve words), you also need to know for which sites you had an account and for which username to regenerate the passwords (since these are used to generate the cryptographic key where the passwords is derived from). This meta-information is stored remotely, and automatically fetched when you enter the paper backup. The beauty of the scheme is that the data is encrypted with a key that is derived from the seed (so we nor anyone else can read it) and that getting or writing the data is only allowed when the request is signed with the authentication key (so it can't be overwritten by an evil hacker or bored teenager).

Conclusion

I realise that there's a lot more to cover, we are working on this. Furthermore, the theory is only one side of the story. We will have a thorough security analysis of the app as well to make sure the code is robust. Nevertheless, I hope this primer gives you some confidence about Chiff's security. If not, we're happy to address you concerns!

References

[1] Ross J Anderson. Security engineering: a guide to building dependable distributed systems. John Wiley & Sons, 2010.

[2] Moritz Horsch. Generating and Managing Secure Passwords for Online Accounts. PhD thesis. Darmstadt: Technische Universität, 2018. URL: http://tuprints.ulb.tu-darmstadt.de/7003/.