In defense of deterministic password managers
tldr; Although they have some shortcomings, deterministic password management is a great idea with a lot of benefits!
Today I read this post which was trying to convince people to switch to stateful password managers which store all passwords in some central data storage locally or on the cloud. I have to admit that the article had some valid points, but generally, it did poorly to convince me that deterministic password managers are bad.
First let me explain what a non-deterministic password manager is.
Normally, when you register in a website, you use a password manager to keep track of all of your passwords. So after signing up for a new email account (e.g.
firstname.lastname@example.org), you will store email id and it’s password (which is chosen by you), in the password manager’s database.
What is the solution? There has recently been a new way to manage password which I call deterministic password management (or DPM for short). This means that there is no central password database. Everything is inside your head! There is no need to have a cloud-based server to store your passwords. Generally, you have a basic passphrase which I call the “master password”. All other passwords are generated uniquely using a formula based on “master password” and some other public information. As a result, you don’t need to memorize 100 passwords or save them anywhere! Just memorize the master password and the reset can be automated.
For example for website “gmail.com” and username “mahdix” the password will be calculated using some formula like this:
password = Hash(master_password, 'gmail.com', 'mahdix')
The most important advantage of this scheme is that there is no need to store sensitive data anywhere! I would like to stress the term “sensitive” because later I will refer to this feature. The other advantage is that your password will all be strong passwords because they are generated using a hash function which causes the result to be semi-random. There will no longer be passwords like “letmein” or “admin” in this scheme.
What are flaws of Deterministic Password Managers?
Now, back to the initial point! The blog post discusses some reasons why this type of password management is not secure and as the author claims: “has fatal flaws”.
There are four points discussed in the article:
- DPMs cannot accommodate varying password policies without keeping state: I disagree with this one. As long as the hash function is complex enough (which normally is), the generated password can be accoreding to every sane password policy. The examples that author provides: “password must be at least 8 characters long” or “password must be lowercase only” either are by default satisfied or don’t make sense! I have never seen a website which insists password must be lowercase.
- DPMs cannot handle recovation of exposed passwords without keeping state: I agree with this one but see point below.
- DPMs cannot store existing secrets: Agreed but it can be fixed without loosing security. See the point below.
- Exposed master password alone exposes all of your site passwords: I disagree with this point because it is not an issue of DPMs per-se. If your email account’s password is exposed, it will probably have similar effect! That is how email works. This is the natural side-effect of using email.
State vs Sensitive data
I would like to differentiate between state of a password manager with sensitive data (e.g. passwords). Of course for a traditional password manager like 1Password, these are the same: State of the password manager is the collection of stored password. So it is sensitive data by definition.
But for DPMs this is not the case. You can have some basic and minimal state which is not sensitive. What does that mean? It means that this state can be publicly exposed and available without loosing security of any of your accounts. The only important security feature of state in this sense is “Integrity”. They should not be altered without your consent. If this feature is satisfied then there is no problem for a DPM to have publicly available state.
For example you can store this state in your Google Drive or Dropbox or even on GitHub! Even if you want to maintain higher level of security you can encrypt those information using the “master password”, but that won’t be required.
Now, how can using state address the two problems stated above: Password revocation and storing existing secrets?
How to store existing secrets in a DPM?
Suppose that you already have an account with password: EP. Now you want to switch to DPM. Can you keep this password? It is possible using State.
Suppose that DLM expects the password of this account to be CP where CP is result of the Hash function formula of the system. It is enough to store “
XP=CP^EP” in the State storage of the system (^ represents XOR operation). Now, it is impossible to retain any information about “EP” with having only “XP“. But user can easily calculate “EP” by calculating “CP” and then: “
EP=CP^XP” (You can use any other function with similar property).
Using this method, a user can store his existing password without revealing any sensitive information. Same approach can be used to renew a password. Just keep a public parameter (like counter), in the State data. It won’t expose anything sensitive and can be used to renew the password. Just increment the counter and the password will be:
Password = Hash(master_password, website, user_id, counter)
This can easily be incorporated to any DLM and provide features to re-new password or add pre-existing passwords.
Of course there will always be a trade-off . So for above mentioned advantages, there are some drawbacks too. Most notably, if your master password is exposed or stolen, all of your accounts will be at risk. This is the natural consequence of using “Master Password”.