How we protect your data

Information security is a huge topic, covering everything from processess and policies through to technical measures.There are several dimensions to security and data protection. I’ll try to explain how we address them, without sending you to sleep.

The CIA triad

No I’m not talking about the US intelligence agency, I’m talking about Confidentiality, Integrity and Availability. The three dimensions we need to address when considering information security.

Confidentiality

This is what lay people immediately think of when considering security and “hacking” (which should really be called cracking, but anyway…). Confidentiality refers to preventing unauthorized access to data, in this case your data and your user’s data.

Protecting private keys

Passkeys use public/private key pairs. Private keys never leave the authentication device (physical e.g. YubiKey, or platform e.g. an iPhone) except when being synced to a cloud account. Crucially this is enforced by the authentication device itself, there is no way for a malicious XSS exploit to obtain access to your users private keys.

Our JWTs are signed using RS256 private keys. Guarding access to those keys is obviously crucial. We take a number of steps to protect the keys. Most importantly we delegate signing to Amazons Key Management Service. Just as we don’t have access to your user’s private keys, we don’t actually have access to our own private keys! they’re locked away in the KMS vault.

We routinely rotate the keypairs used for JWT signing and verification. It’s one of the reasons why we use JWK endpoints - most JWT libraries will transparently fetch and cache the relevant public key when the signing key changes.

Protecting personal information

We hold personal information, most obviously in the form of names and email addresses, but also IP addresses and browser “fingerprints”. We encrypt personally identifiable data in DynamoDB, which uses AWS KMS behind the scenes.

Let’s move onto the next aspect of the CIA triad, Integrity…

Integrity

Public keys

Integrity of data is often overlooked in the context of PKI. “I only share my public key so I’m good” is something I’ve heard too often. The risk lies in an attacker substituting a public key with his own. In the context of passkeys, if an attacker can substitute a users’s public keys with his own, he can login as that person.

Of course we take all the normal precautions to restrict access to data but we can go a step further…

Fortunately, unlike passwords, once a passkey is generated, and the public key component is stored it shouldn’t really change. There are legitimate (but very limited) reasons why a user may replace a passkey. Any change should be flagged.

Due to the exceptional nature of a passkey update, we monitor and alert on any unexpected changes. We set a tripwire so if the data changes we’re notified and can perform additional checks. If we detect unusual activity, we want to alert the user and developers.

For those who are interested in the details, we actually use DynamoDB streams to do this.

Client side code

We ask you to execute our Javascript in your users’ browsers. This opens up the potential for XSS attacks. We deliberately minimise our use of external dependencies and limit use to those projects with high traction and “eyes on”. Additionally we use Snyk to check the dependency graphs for vulnerabilities.

Availability

If your users are unable to authenticate against Passlock, they’re unable to access your systems. Availability is really important.

That’s why we delegate infrastructure to AWS. They’re not perfect, but they’re much better at this stuff than we could ever be. We use serverless products, with built in high availability. For example, we store most data in DynamoDB instead of RDS.

Read more about our AWS stack.