Improving Registration Lock with Secure Value Recovery

jimio on 27 Jan 2020

Registration Lock allows you to set a PIN that is required for account registration in addition to standard SMS-based verification. Today’s Signal beta release enhances the security of these PINs by transitioning them to use Secure Value Recovery.

A Registration Lock PIN functions the same way as any password: it’s a shared secret that you and the service agree on in order to verify that you are really you when you show up in the future.

In order to remember everyone’s passwords, servers have to store all of them somewhere like a database. That’s a sensitive piece of infrastructure, and while the security of a password database can be improved by hashing the values that are stored there, short passwords (or even non-randomly generated long ones) can be brute forced by attackers with offline access by iteratively guessing combinations and seeing if the hash matches the stored value.

Ideally, a Registration Lock PIN would be a public key or a 256-bit random value, such that brute forcing would not be possible even with offline access to the data. However, most people are unlikely to remember a 256-bit random value for day-to-day use, resulting in a registration lock that is so secure it locks everyone out – including the account owner.

This is the familiar trade-off that Secure Value Recovery is designed to help with. By transitioning Registration Lock PINs to Secure Value Recovery, we can restrict offline brute force access for those PINs. For the Registration Lock itself, we can derive a random 256-bit registration_lock_secret from master_key, and use that for access control.

Before: HASH(12345 || salt) After: HASH(7aa86631a01853e9f2a38ffba36667e396bc7bc3cbaf96389240de118c9fbb66 || salt)

Registration Lock PINs move from being hashed short non-random values in a database to hashed 256-bit random values in a database.

We feel like this is a good place to start experimenting with Secure Value Recovery, since transitioning Registration Lock should be strictly additive security. We’re improving the way that we store an existing value while building a foundation for other future enhancements. As with everything we do here at Signal, all of the code is open source and available for review.

We would also like to thank everyone who helped us test the hashing performance of Signal’s Argon2 wrapper on a wide variety of Android and iOS devices. This work would not have been possible without your support.

Want to get involved with Signal? We're hiring!