How we created a password manager with strong cryptography and a master password. Experience team Yandex. Browser
Strangely enough, but only 1% of browser users use specialized extensions to store passwords (LastPass, KeePass, 1Password, ...). Password security for all other users depends on the browser. Today we will tell Habrahabr readers why our team abandoned the password protection architecture from the Chromium project and how it developed its own password manager, which is already being tested in beta. You will also learn how we solved the problem of resetting the master password without decrypting the passwords themselves.
From a security point of view, it is recommended to use a unique password on each site. If attackers steal one password, they will get access to only one site. The problem is that remembering dozens of strong passwords is very difficult. Someone honestly comes up with new passwords and writes them in his hands in a notebook (and then loses with him), others use the same password on all sites. It is difficult to say which of these options is worse. The solution to the problem for millions of ordinary users may be the password manager built into the browser, but its effectiveness depends on how simple and reliable it is. And in these questions the previous decision had gaps, which we will discuss below.
')
Why are we creating a new password manager?
In the current implementation of the password manager for Windows, inherited from Chromium, the saved passwords are protected by the browser quite simply. They are encrypted by means of the operating system (for example, on Windows 7, the CryptProtectData function is used, based on the AES algorithm), but they are not stored in an isolated area, but simply in a profile folder. It would seem that there is no problem in this, because the data is encrypted, but the decryption key is also stored in the operating system. Any program on the computer can go to the browser profile folder, take the key, decrypt passwords locally, send them to a third-party server, and no one will notice.
And many users would like a random person who does not have special training, but who has received short-term access to the browser (for example, a relative or colleague), could not log in to important sites using saved passwords.
Both of these problems are solved with the help of a master password, which protects the data, but which is not stored anywhere. And it became our first requirement for a new password storage architecture in Yandex. Browser. But not the only one.
No matter how safe the new password manager may be, its popularity depends on how easy it is to use it. Recall that the same 1Password, KeePass and LastPass even in the total use no more than a percentage of users (although we offer LastPass in our built-in catalog of add-ons). Or another example. So in the old implementation, the Browser suggests saving the password:
Experienced users either agree, or refuse, or do at least something with this notice. But in 80% of cases they simply do not notice him. Many users do not even know that passwords can be saved in the browser.
Separately it is necessary to say about the functionality. Now even getting to the list of your passwords is not so easy. You need to open the menu, click on the settings, go to the advanced settings, find the password management button there. And only then will a person have access to a primitive list of accounts that cannot be sorted by login, you cannot add a text note, you cannot edit it either. In addition, the password manager should help to invent new passwords.
And something else. It was important for us that the new architecture corresponded to the Kirkgoff principle, that is, that its reliability did not depend on the knowledge of the attackers about the algorithms used. The cryptosystem must remain secure, even if they know everything except the keys used.
Why we did not take a ready-made solution?
There are open source products that support a master password and advanced functionality. They could be integrated into the browser, but they did not suit us for a number of reasons.
KeePass comes to mind first. But its storage is encrypted entirely, and in our browser the synchronization works line by line. So, it is necessary either to ask the master password for each synchronization, or to encrypt the records separately. The second option is kinder to users. Moreover, for a mass product, it is important that the user knows about the possibility to substitute the saved password before unlocking the database with a master password, so some of the information should remain unencrypted.
The specialized add-ons for working with passwords have the opportunity to reset the master password if the user forgot it. But for this you need to download, hide and not lose the backup code or file. This is normal when it comes to advanced users, but it is difficult for everyone else. Therefore, we needed to come up with an alternative solution. Spoiler: in the end, we managed to find a solution in which the master password can be reset, but even Yandex cannot access the database. But more on that later.
And any third-party solution in any case would have to be seriously refined to natively integrate into the browser (rewrite in C ++ and Java) and make it quite simple for users (completely replace the entire interface). No matter how surprising it may sound, but writing a new password storage and encryption architecture is easier than doing the rest. Therefore, it is more logical not to try to link two initially incompatible products into one, but to modify your own.
New architecture using a master password
There is nothing unusual about storing the records themselves. We use a robust and fast AES-256-GCM algorithm to encrypt passwords and notes, addresses and logins are not encrypted for ease of use, but signed for protection against spoofing. The storage scheme in the same 1Password is similarly arranged.
The most interesting thing is the protection of the 256-bit key encKey, which is necessary for decrypting passwords. This is the key to password security. If an attacker recognizes this key, it will easily hack into all storage, regardless of the complexity of the encryption algorithm. Therefore, key protection is based on the following basic principles:
- Access to the encryption key is blocked by a master password that is not stored anywhere.
- The encryption key should not be mathematically related to the master password.
In simple services and applications, an encryption key is obtained by hashing the master password in order to at least slow down the brute force attack. But the mathematical dependence of the key on the master password still simplifies hacking, the speed of which in this case depends only on the reliability of hashing. The use of trusses from sharpened ASIC processors is no longer a rarity. Therefore, in our case, the encKey key is not derived from the master password and is generated randomly.
Next, the encKey key is encrypted using the asymmetric RSA-OAEP algorithm. For this, the Browser creates a pair of keys: open pubKey and closed privKey. The encKey key is protected using the public key, and it can only be decrypted using the private key.
It is not necessary to protect the public key pubKey, because it is not suitable for decryption, but with the privKey closed, the story is different. To protect it from theft, access to it is blocked according to the PKCS # 8 standard using the unlockKey passphrase, which in turn is the result of hashing the master password using the PBKDF2-HMAC-SHA256 function (100 thousand repetitions; with salt added and id ). If the master password accidentally coincides with the already stolen password from any site, adding salt will hide this fact and complicate hacking. And due to the repeated hashing of a sufficiently long master password, the unlockKey hacking complexity is comparable to the encKey key hacking.
The encrypted passwords, the encrypted key to them encKey, the encrypted privKey private key and the public key pubKey are stored in the browser profile and synchronized with other devices of the user.
To make it easier to understand all this, we give a password decryption scheme:
This architecture using a master password has several advantages:
- 256-bit storage encryption key is generated randomly and has high cryptographic strength compared to passwords invented by man.
- If the master password is brute force, the attacker will not know the result if he does not pass through the entire chain (password-PBKDF2-RSA-AES). It is very long and very expensive.
“If the hash function is compromised, we can switch to an alternative hash at any time while maintaining backward compatibility.”
- If an attacker finds out the master password, you can change it without a complicated and risky procedure to decrypt the entire repository, because the data encryption key is not associated with the master password, which means it is not compromised.
- The encryption key is stored in encrypted form. Neither Yandex nor the attacker who stole the Yandex password will be able to gain access to synchronized passwords, since this requires a master password that is not stored anywhere.
But the master password option has one “flaw”: the user can forget the master password. This is normal when it comes to specialized solutions that are experienced users who are well aware of the risk. But in a product with a multimillion audience, this is unacceptable. If we do not foresee the backup option, many Yandex. Browser users either refuse to use the master password, or “lose” once all their passwords, and the Browser will be guilty in this (you will be surprised, but Yandex is often the last thing in a situation where man forgot the password from the account). And to come up with a solution is not so simple.
How to reset the master password without disclosing passwords?
In some products, this problem is solved by storing decrypted data (or even a master password) in the cloud. This option was not suitable for us, because an attacker could steal a password from Yandex, and with it, passwords from all sites. Therefore, we had to come up with a way to restore access to the password store, in which no one but the user could do it. Third-party password managers suggest creating a backup file for this, which the user must independently store in a safe place. A good solution, but ordinary users will inevitably lose such backup keys, so everything is much simpler.
Once again, recall the key dependency chain. The password store is encrypted using a random key encKey, which is not stored anywhere in the explicit form. This key is protected using the private key privKey, which is also not stored explicitly and is in turn protected by a complex hash from the master password. When a person forgets the master password, he actually loses the ability to decrypt the key privKey. This means that as a backup option, you can store a duplicate key privKey. But where? And how to protect it?
If you put the decoded privKey in the cloud, then the password security will depend on the Yandex account. And exactly this we did not want to admit. If you store it explicitly locally, then all protection with a master password loses any meaning. There is no such place where it would be safe to store this key explicitly. So it needs to be encrypted. To do this, the Browser creates a random 256-bit key that protects the duplicate privKey. Now the fun part. This random key is sent to the Yandex.Passport cloud for storage. And the encrypted duplicate is stored in the local browser profile. It turns out that neither the cloud nor the computer has a ready-made pair for decrypting passwords, and security does not suffer.
With this option, it would be possible to reset the master password only where the duplicate key privKey was created. We wanted to add this feature to synchronized devices. It is inconvenient to manually create a backup key on each device: you can accidentally stay with the device on your hands, on which you forgot to create a duplicate. You cannot send an encrypted duplicate to other devices using synchronization: the key to it is already stored in the cloud, and for security reasons they cannot be found in one place. Therefore, the encrypted duplicate privKey passes through another layer of encryption. This time - using a hash from the master password. The master password is not stored in the cloud, so the resulting "matryoshka" can already be synchronized safely. On other devices, when you first enter the master password, an additional encryption layer will be removed.
As a result, when the user forgets the master password, it will be enough for him to request a password reset via the browser and confirm his identity with a Yandex password.
The browser will request the key from Yandex.Passport, decrypt the duplicate key privKey, use it to decrypt the key for the storage encKey, and then create a new pair of pubKey and privKey, the last of which will be protected by a new master password. The password store is not decrypted, which reduces the risk of data loss. By the way, it is also possible to force the change of encKey and re-encrypt data: just disable and re-enable the master password in the settings.
It turns out that only the user can reset the master password and only on the device where he has entered it at least once. Of course, it is not necessary to create a backup key if the user is confident in himself. Even the master password can not be used, although we do not recommend to give it up.
New architecture and master password are not the only changes in the new manager. As we said above, usability and advanced features are just as important.
New Password Manager
First of all, we abandoned the inconspicuous gray panel with the proposal to save the password. Now the user will see a suggestion next to the password field. Not to notice this is already difficult.
And now the manager himself no longer needs to be searched in the settings: the button is available in the main menu. The list of saved accounts now supports sorting by login, address and notes. We also added editing entries.
Tip: notes are great as an alternative to tags because they support searching.
And the Browser now helps to create unique passwords.
In the first beta version, we were far from all. In the future, we will support the export and import of passwords for compatibility with popular third-party solutions. We also have an idea to add password generator settings.
Mobile Password Manager
Of course, the new logic and support for the master password will appear not only on the computer, but also in the Yandex Browser versions for Android and iOS. With a little adaptation. For example, you can use not only the master password, but also a fingerprint. We also forbade programmatically taking screenshots on the password list page - you can not be afraid of malicious applications.
Today, a new password manager can be tried in the beta version of Yandex. Browser for Windows and macOS (the version for Linux is traditionally built on the basis of stable code, so it will be released a little later). In the near future, he will also work in the alpha version of the Browser for Android (and after some time will appear in the beta for iOS).
We are constantly looking for a balance between a simple but reliable tool for millions of users and advanced features for those who need them. Please share with us a vision of the ideal password manager that you would like to see in the browser.
And something else. We invite security experts to help us find vulnerabilities in the new password manager under the Bug for Bugs program. With your help, the password manager will be even safer. Thank!
From a security point of view, it is recommended to use a unique password on each site. If attackers steal one password, they will get access to only one site. The problem is that remembering dozens of strong passwords is very difficult. Someone honestly comes up with new passwords and writes them in his hands in a notebook (and then loses with him), others use the same password on all sites. It is difficult to say which of these options is worse. The solution to the problem for millions of ordinary users may be the password manager built into the browser, but its effectiveness depends on how simple and reliable it is. And in these questions the previous decision had gaps, which we will discuss below.
')
Why are we creating a new password manager?
In the current implementation of the password manager for Windows, inherited from Chromium, the saved passwords are protected by the browser quite simply. They are encrypted by means of the operating system (for example, on Windows 7, the CryptProtectData function is used, based on the AES algorithm), but they are not stored in an isolated area, but simply in a profile folder. It would seem that there is no problem in this, because the data is encrypted, but the decryption key is also stored in the operating system. Any program on the computer can go to the browser profile folder, take the key, decrypt passwords locally, send them to a third-party server, and no one will notice.
And many users would like a random person who does not have special training, but who has received short-term access to the browser (for example, a relative or colleague), could not log in to important sites using saved passwords.
Both of these problems are solved with the help of a master password, which protects the data, but which is not stored anywhere. And it became our first requirement for a new password storage architecture in Yandex. Browser. But not the only one.
No matter how safe the new password manager may be, its popularity depends on how easy it is to use it. Recall that the same 1Password, KeePass and LastPass even in the total use no more than a percentage of users (although we offer LastPass in our built-in catalog of add-ons). Or another example. So in the old implementation, the Browser suggests saving the password:
Experienced users either agree, or refuse, or do at least something with this notice. But in 80% of cases they simply do not notice him. Many users do not even know that passwords can be saved in the browser.
Separately it is necessary to say about the functionality. Now even getting to the list of your passwords is not so easy. You need to open the menu, click on the settings, go to the advanced settings, find the password management button there. And only then will a person have access to a primitive list of accounts that cannot be sorted by login, you cannot add a text note, you cannot edit it either. In addition, the password manager should help to invent new passwords.
And something else. It was important for us that the new architecture corresponded to the Kirkgoff principle, that is, that its reliability did not depend on the knowledge of the attackers about the algorithms used. The cryptosystem must remain secure, even if they know everything except the keys used.
Why we did not take a ready-made solution?
There are open source products that support a master password and advanced functionality. They could be integrated into the browser, but they did not suit us for a number of reasons.
KeePass comes to mind first. But its storage is encrypted entirely, and in our browser the synchronization works line by line. So, it is necessary either to ask the master password for each synchronization, or to encrypt the records separately. The second option is kinder to users. Moreover, for a mass product, it is important that the user knows about the possibility to substitute the saved password before unlocking the database with a master password, so some of the information should remain unencrypted.
The specialized add-ons for working with passwords have the opportunity to reset the master password if the user forgot it. But for this you need to download, hide and not lose the backup code or file. This is normal when it comes to advanced users, but it is difficult for everyone else. Therefore, we needed to come up with an alternative solution. Spoiler: in the end, we managed to find a solution in which the master password can be reset, but even Yandex cannot access the database. But more on that later.
And any third-party solution in any case would have to be seriously refined to natively integrate into the browser (rewrite in C ++ and Java) and make it quite simple for users (completely replace the entire interface). No matter how surprising it may sound, but writing a new password storage and encryption architecture is easier than doing the rest. Therefore, it is more logical not to try to link two initially incompatible products into one, but to modify your own.
New architecture using a master password
There is nothing unusual about storing the records themselves. We use a robust and fast AES-256-GCM algorithm to encrypt passwords and notes, addresses and logins are not encrypted for ease of use, but signed for protection against spoofing. The storage scheme in the same 1Password is similarly arranged.
The most interesting thing is the protection of the 256-bit key encKey, which is necessary for decrypting passwords. This is the key to password security. If an attacker recognizes this key, it will easily hack into all storage, regardless of the complexity of the encryption algorithm. Therefore, key protection is based on the following basic principles:
- Access to the encryption key is blocked by a master password that is not stored anywhere.
- The encryption key should not be mathematically related to the master password.
In simple services and applications, an encryption key is obtained by hashing the master password in order to at least slow down the brute force attack. But the mathematical dependence of the key on the master password still simplifies hacking, the speed of which in this case depends only on the reliability of hashing. The use of trusses from sharpened ASIC processors is no longer a rarity. Therefore, in our case, the encKey key is not derived from the master password and is generated randomly.
Next, the encKey key is encrypted using the asymmetric RSA-OAEP algorithm. For this, the Browser creates a pair of keys: open pubKey and closed privKey. The encKey key is protected using the public key, and it can only be decrypted using the private key.
It is not necessary to protect the public key pubKey, because it is not suitable for decryption, but with the privKey closed, the story is different. To protect it from theft, access to it is blocked according to the PKCS # 8 standard using the unlockKey passphrase, which in turn is the result of hashing the master password using the PBKDF2-HMAC-SHA256 function (100 thousand repetitions; with salt added and id ). If the master password accidentally coincides with the already stolen password from any site, adding salt will hide this fact and complicate hacking. And due to the repeated hashing of a sufficiently long master password, the unlockKey hacking complexity is comparable to the encKey key hacking.
The encrypted passwords, the encrypted key to them encKey, the encrypted privKey private key and the public key pubKey are stored in the browser profile and synchronized with other devices of the user.
To make it easier to understand all this, we give a password decryption scheme:
This architecture using a master password has several advantages:
- 256-bit storage encryption key is generated randomly and has high cryptographic strength compared to passwords invented by man.
- If the master password is brute force, the attacker will not know the result if he does not pass through the entire chain (password-PBKDF2-RSA-AES). It is very long and very expensive.
“If the hash function is compromised, we can switch to an alternative hash at any time while maintaining backward compatibility.”
- If an attacker finds out the master password, you can change it without a complicated and risky procedure to decrypt the entire repository, because the data encryption key is not associated with the master password, which means it is not compromised.
- The encryption key is stored in encrypted form. Neither Yandex nor the attacker who stole the Yandex password will be able to gain access to synchronized passwords, since this requires a master password that is not stored anywhere.
But the master password option has one “flaw”: the user can forget the master password. This is normal when it comes to specialized solutions that are experienced users who are well aware of the risk. But in a product with a multimillion audience, this is unacceptable. If we do not foresee the backup option, many Yandex. Browser users either refuse to use the master password, or “lose” once all their passwords, and the Browser will be guilty in this (you will be surprised, but Yandex is often the last thing in a situation where man forgot the password from the account). And to come up with a solution is not so simple.
How to reset the master password without disclosing passwords?
In some products, this problem is solved by storing decrypted data (or even a master password) in the cloud. This option was not suitable for us, because an attacker could steal a password from Yandex, and with it, passwords from all sites. Therefore, we had to come up with a way to restore access to the password store, in which no one but the user could do it. Third-party password managers suggest creating a backup file for this, which the user must independently store in a safe place. A good solution, but ordinary users will inevitably lose such backup keys, so everything is much simpler.
Once again, recall the key dependency chain. The password store is encrypted using a random key encKey, which is not stored anywhere in the explicit form. This key is protected using the private key privKey, which is also not stored explicitly and is in turn protected by a complex hash from the master password. When a person forgets the master password, he actually loses the ability to decrypt the key privKey. This means that as a backup option, you can store a duplicate key privKey. But where? And how to protect it?
If you put the decoded privKey in the cloud, then the password security will depend on the Yandex account. And exactly this we did not want to admit. If you store it explicitly locally, then all protection with a master password loses any meaning. There is no such place where it would be safe to store this key explicitly. So it needs to be encrypted. To do this, the Browser creates a random 256-bit key that protects the duplicate privKey. Now the fun part. This random key is sent to the Yandex.Passport cloud for storage. And the encrypted duplicate is stored in the local browser profile. It turns out that neither the cloud nor the computer has a ready-made pair for decrypting passwords, and security does not suffer.
With this option, it would be possible to reset the master password only where the duplicate key privKey was created. We wanted to add this feature to synchronized devices. It is inconvenient to manually create a backup key on each device: you can accidentally stay with the device on your hands, on which you forgot to create a duplicate. You cannot send an encrypted duplicate to other devices using synchronization: the key to it is already stored in the cloud, and for security reasons they cannot be found in one place. Therefore, the encrypted duplicate privKey passes through another layer of encryption. This time - using a hash from the master password. The master password is not stored in the cloud, so the resulting "matryoshka" can already be synchronized safely. On other devices, when you first enter the master password, an additional encryption layer will be removed.
As a result, when the user forgets the master password, it will be enough for him to request a password reset via the browser and confirm his identity with a Yandex password.
The browser will request the key from Yandex.Passport, decrypt the duplicate key privKey, use it to decrypt the key for the storage encKey, and then create a new pair of pubKey and privKey, the last of which will be protected by a new master password. The password store is not decrypted, which reduces the risk of data loss. By the way, it is also possible to force the change of encKey and re-encrypt data: just disable and re-enable the master password in the settings.
It turns out that only the user can reset the master password and only on the device where he has entered it at least once. Of course, it is not necessary to create a backup key if the user is confident in himself. Even the master password can not be used, although we do not recommend to give it up.
New architecture and master password are not the only changes in the new manager. As we said above, usability and advanced features are just as important.
New Password Manager
First of all, we abandoned the inconspicuous gray panel with the proposal to save the password. Now the user will see a suggestion next to the password field. Not to notice this is already difficult.
And now the manager himself no longer needs to be searched in the settings: the button is available in the main menu. The list of saved accounts now supports sorting by login, address and notes. We also added editing entries.
Tip: notes are great as an alternative to tags because they support searching.
And the Browser now helps to create unique passwords.
In the first beta version, we were far from all. In the future, we will support the export and import of passwords for compatibility with popular third-party solutions. We also have an idea to add password generator settings.
Mobile Password Manager
Of course, the new logic and support for the master password will appear not only on the computer, but also in the Yandex Browser versions for Android and iOS. With a little adaptation. For example, you can use not only the master password, but also a fingerprint. We also forbade programmatically taking screenshots on the password list page - you can not be afraid of malicious applications.
Today, a new password manager can be tried in the beta version of Yandex. Browser for Windows and macOS (the version for Linux is traditionally built on the basis of stable code, so it will be released a little later). In the near future, he will also work in the alpha version of the Browser for Android (and after some time will appear in the beta for iOS).
We are constantly looking for a balance between a simple but reliable tool for millions of users and advanced features for those who need them. Please share with us a vision of the ideal password manager that you would like to see in the browser.
And something else. We invite security experts to help us find vulnerabilities in the new password manager under the Bug for Bugs program. With your help, the password manager will be even safer. Thank!
Source: https://habr.com/ru/post/344382/
All Articles