Sleep Better at Night While You Keep Your Members (and You) Safe

Remember the days when having an encrypted member database was enough? Those practices were rock solid for years and you slept soundly knowing your data was secure.

Unfortunately, times have changed. With today’s threats, you’ve likely added a number of security steps for your members.  This leads to endless support calls from members who have locked themselves out of their accounts, and even more secrets for you to protect due to two-factor authentication and other new security solutions you’ve implemented. And on top of that, you worry that an employee might get spear-phished, opening your database to an attack.

Striking a balance between security and convenience is the age-old, but ever more relevant, challenge.  As you evaluate ways to manage critical data, here are four essential steps you need to take to ensure security, yet provide an easy and convenient experience for your members at the same time.

1.  Eliminate shared secrets; don’t add more.

It’s near impossible to prevent attackers from penetrating your perimeter and reading your files. This means that the only way to avoid a mass breach of centralized information (like a password file or file of two-factor authentication (2FA) secrets stored in browser cookies) is to eliminate the need for these secrets. In the case of a password file or 2FA secrets, it’s best to replace these with files of public keys. In short, eliminate the shared secrets and replace them with asymmetric cryptography in all places.

This then solves the breach problem. If an attacker breaches the system, all he gets is a file of public keys: perfect for authenticating users, but completely useless for impersonating a user. The simple act of doing this has a secondary effect:  smart hackers will avoid your site because there is simply no “pay day” if you break in. Replacing username/password authentication with asymmetric cryptography has a two-fold effect. First, there is nothing to be gained if there is a break-in and second, there are far fewer attackers trying to break in and the sophistication level of the attackers is much lower than before the change.

2.  Store any secrets on the user’s devices.

If you eliminate shared secrets using Step #1 above, you are still left with the cryptographic secrets associated with each user. Storing those cryptographic secrets in a central repository wouldn’t work. It would just replace one set of shared secrets (passwords, 2FA cookies) with another (private signature keys). Instead, the proper approach is to store the cryptographic secrets of a user’s identity in the devices owned by the user. When a user gets a new device, use a secure method to move the secrets from Device A to Device B using server C where server C is not trustable. Algorithms exist to do just that (such as the Diffie-Hellman key exchange protocol). That way, there are no single points of mass compromise and identity cannot be asserted to a relying party without express involvement of at least one device owned by the user.

3.  Don’t deploy a proprietary solution.

In order to store the cryptographic secrets of a user’s identity on their device, it means the user has to be involved in authorizing that process. If each site has its own means of doing that, it creates a user/device management nightmare since each site will do it differently – a problem that is not all that different from today’s username and password problem. Instead, a better approach is to use a trustable federated identity provider that supports this type of operation so users just do it once per device, not once per site.

4.  To create a really secure identity system, get rid of the username/password while you’re at it.

The final recommendation is to eliminate usernames and passwords when making this change and instead use digital signatures as both the primary and second factor for login. This simplifies things for users because there is just a single password to remember which is verified locally on the user’s device. A financial institution that requires 2FA for login then can simply instruct the user to hit the login button, enter the password associated with their device(s) – it is the same across all devices the user has authorized. The site receives that specific digital signature indicating the device is valid and the user has entered the correct password. So this provides simple two-factor login, a single password that the user can use across all sites, and security against phishing, key logging, and other similar attacks.

While there are many solutions out there that offer a subset of these these recommendations, it’s important to look beyond today’s requirements and threats to implement a solution that offers exponential protection without additional friction to your members.  These steps help you do just that.