A few months ago, Scott Stein shared an article on CNet, Password managers are great -- until you lose your password manager password. Many people shared and retweeted the article. You know that feeling if you ever lost the password to your password manager.
The earliest first generation password managers can manage passwords, by keeping them somewhere, but not protect them well.
About 20 years ago, PBKDF2 was recommended as a standard. It transforms a simple password into a complex key which can be used in cryptographic algorithms.
Since then, lots of second and third generation password managers have been emerging. They derive encryption key from master password, then encrypt user data with the key. This is how it works:
graph TD subgraph 1. key derivation password --> PBKDF2(PBKDF2) salt --> PBKDF2 PBKDF2 -->|derive| key[[key]] end subgraph 2. encryption key --> AES(AES) plaintext --> AES AES --> |encrypt| ciphertext[(ciphertext)] end style password fill:#fff, stroke: #aaa style ciphertext fill: #ddd, stroke: #aaa style salt fill:#fff style plaintext fill:#fff, stroke: #aaa
plaintextis unencrypted data intended to be encrypted;
ciphertextis the output of encryption of
To get the
plaintext back, password managers derive the key just as above, but perform decrypt operation instead of encrypt operation in the second step.
graph TD subgraph 1. key derivation password --> PBKDF2(PBKDF2) salt --> PBKDF2 PBKDF2 -->|derive| key[[key]] end subgraph 2. decryption key --> AES(AES) ciphertext[(ciphertext)] --> AES AES --> |decrypt| plaintext end style password fill:#fff, stroke: #aaa style salt fill:#fff style plaintext fill:#fff, stroke: #aaa style ciphertext fill:#ddd, stroke: #aaa
I will not go deep for it in this article. If you are interested in the details, please checkout this series The evolution of password manager.
Essentially, to encrypt user data, password managers must rely on some secret controlled by the user, so that hackers cannot get data from the ciphertext.
Nowadays, most smartphones, except some low-end ones, are equipped with a dedicated security chip(Trusted Execution Environment, Secure Element, or Secure Enclave in iOS). Emulated payment cards in iPhone and Android wallet apps are secured by this chip.
Our fourth generation password manager, ID Guard Offline, can be safely used without a master password. The secret for encryption can be secured by the chip which is much more reliable than human brain. Again, if you are interested in how it works, please checkout The Evolution of Password Manager (4/4).
Scott Stein, the CNet staff, lost all his passwords because of forgetting master password. It is the nature of the algorithm above. In addition to using security chip protection, ID Guard Offline also offers master password protection (users can choose whether to use it). So our users may also encounter the same problem. We believe that availability is just as important as confidentiality to password managers and we need to resolve that problem.
Some password manager providers allow user to reset master password, Google for example. If a user can reset master password and continue to view passwords stored previously, then those passwords are not secured by the master password.
Our team of course do not compromise on security. The master password can never be reset. Then, is it possible to get the master password back when our user cannot recall it?
Some social services offer user account recovery with the help of trusted contacts when the user forgets the password. Here is how it works.
Inspired by this, we have a simple idea: ask friends to help find password back. And finally, we perfected this design after several iterations.
Ask friends to save my password
The first idea coming into our minds was just asking friends to save the password. When forgetting the password, ask a friend to tell me the password. It's like asking a friend to keep my house keys temporarily.
Obviously, this is not safe. Passwords are always meant to be kept secretly. Lots of users reuse their passwords, one leaked password can endanger a large number of accounts.
Encrypt the password then send to friends
Encryption is a good idea. The problem is how to choose/derive the encryption key. We cannot ask user to set another password to encrypt the password, right?
If the encryption does not depend on user's secret, the encryption key must be hardcoded. We will not make the same mistake like other password managers did years ago.
Encrypt the password with a key inside the security chip on smartphone, and send only the
ciphertext to friends
graph TD key[[key]] --> AES(AES) password --> AES AES -->|encrypt| ciphertext[(password file)] key --> phone[Secure Element] ciphertext --> friend[saved by friend] style password fill:#fff, stroke: #aaa style ciphertext fill: #ddd, stroke: #aaa style phone fill: #b3d26a style friend fill: #acf
In this proposal, a password file(
ciphertext) is kept by each friend, but the
keys are secured by the security chip on the phone.
The password can be decrypted if a friend sends back the password file, when finding back the password.
graph TD subgraph 1. find back password masterPasswordKey[[key]] --> masterPasswordAes(AES) masterPasswordCiphertext[(password file)] --> masterPasswordAes masterPasswordAes -->|decrypt| password end subgraph 2. key derivation password --> PBKDF2(PBKDF2) salt --> PBKDF2 PBKDF2 -->|derive| key[[key]] end subgraph 3. decryption key --> AES(AES) ciphertext[(ciphertext)] --> AES AES --> |decrypt| plaintext end style masterPasswordCiphertext fill: #ddd, stroke: #aaa style password fill:#fff, stroke: #aaa style ciphertext fill: #ddd, stroke: #aaa style salt fill:#fff style plaintext fill:#fff, stroke: #aaa
Friends are required to save the password file into ID Guard Offline, which is secured by the security chip on the phone. So hackers cannot steal the password file. This finding back master password mechanism does not weaken the security of the data stored in ID Guard Offline.
So how to use it?
If you are using master password to unlock the app, go to the
Find back master password setup view, enter your friend's name, and touch
Send the password file to your friend and ask him/her to save it in ID Guard Offline.
If you forget your master password, you can check out the list of friends who can help you.
Ask a friend to send back the password file, open it with ID Guard Offline to unlock it. You need to change unlock method immediately.
Trusted contacts must be very trustworthy when using the account recovery feature offered by social services. Otherwise, those "bad friends" can hack into my account by initializing the account recovery process and completing the tasks required by the service.
We borrow the idea from social services, but in our design, friends can be somewhat dependable because they cannot decrypt my passwords without the key. Also, I can get my password back as long as one of my friends can give me the password file.
Both those password managers and ID Guard Offline can recover user data when a user forgets the password.
Those password managers can reset master password and grant access to user data after confirming the identity of the user. So the encryption, if any, of the stored data does not depend on the master password but totally controlled by the service provider.
In our design, master password cannot be reset. The data is protected by the password. We employ a new method to get the password back with the help of friends, and the password is kept secure at the same time.
As for security, those password managers do not make a concession. The master password cannot be reset.
In our design, we stick to this practice. But we provide a method to find the password back in case a user forgets it.
The availability of user data has been improved a lot without losing confidentiality.
We offer a new option to get password back, and it adds a new attack surface, however.
Previously, a hacker has to steal user's phone, unlock it and enter the master password to crack user data. Now, if the hacker does not know the master password, it is possible that he/she can hack into the a friend's phone to grab the password file.
To make it less vulnerable, friends are required to store the password file in ID Guard Offline. All data saved in ID Guard Offline are secured by security chip on the phone. To steal the password file, the hacker needs to completely crack ID Guard Offline on a friend's phone, which is much harder than stealing an ordinary file.
Of course, both of the user and the friend should not store the password file on the phone, except inside the app. If password files persist on some storage media during sending to friends, they must be deleted after that. Otherwise, bad guys can use the password file to unlock the app.
With several iterations, we get these achievements:
Availability is improved a lot.
Both availability and confidentiality are the most important KPIs for password managers. Human memory is not perfect. With this new way to recover user data, remembering the password manager password is not a single point of failure anymore.
Confidentiality is not weakened.
The password is still protecting user data, and cannot be reset. Decryption still requires the password which now can be recovered with the help of friends.
Master password is kept secret.
Friends can help recover the password, but cannot decipher it.
On the other hand, to use it safely, users shouldn't store the password file on phone's file system or any other transmission media such as email, messenger, cloud storage. Never put the password file on your phone, or you just left the key on a strongbox.