3

Suppose you use a password manager having all possible features of modern password managers: encryption with a key derived from your master password, auto-filling, cloud or local storage, browser extension, web and local applications, random password generator, password auto-change, etc.

Now, suppose that you have the choice between these two options:

  • storing a randomly generated strong password directly in the encrypted vault (KeePass-like, with the ability to choose how long the vault can stay unencrypted, or when to ask again the master password: before each use, etc.)
  • storing only the pattern used to derive a strong password from your master password (LessPass-like, with the ability to choose when the password is derived: just after the decryption, before each use, etc.)

Finally, suppose that the round numbers used by the derivation functions (for the encryption key and the strong password) are high enough for the derivation to take roughly one second on most devices.

How to choose between those two?
What are their pros and cons?
Which one is the most secure in which case (concerning both cryptography and usability)?
Are there other parameters to take into account to make this choice (features, closed or open source, etc)?

migrated from crypto.stackexchange.com Nov 13 '18 at 13:14

This question came from our site for software developers, mathematicians and others interested in cryptography.

  • Using your master password for much more than your password vault is a very bad idea. Your password fault is generally not available to others, having a master password is an additional security measure, for me at least. Devices have a wildly different amount of hardware; it may not be possible to have a 1s delay on a 4 GHz x64 CPU and have it run in anything considered useful on a low end smartphone or, say, an old Raspberry (which are "sluggish" to say the least). – Maarten Bodewes Nov 13 '18 at 11:46
  • 1
    Both methods have their advantages and disadvantages (and you hint at this when asking for "other parameters"). You can ask about those, but asking which is more secure is opinionated and the question may be closed because of that. – Maarten Bodewes Nov 13 '18 at 11:49
  • Hmm, well let's say that the random passwords are chosen from [a-zA-Z0-9]{21}, that gives ~131 bits of entropy. If the master password has more entropy than that and you use an HMAC(site_name, master_pw) construction to derive the passwords, then your derived passwords should be just as secure as if they were chosen uniformly at random. But this derivation scheme is less secure overall: if an attacker ever gained access to your master password (even for a moment) your future derived passwords are at risk if you continue using that password... – kiwidrew Nov 13 '18 at 12:05
  • I fail to see the difference with encryption: if he has my master password, he should also be able to decrypt my vault and retrieve all my stored passwords. However, if my master password is compromised, I may want to change it, but if I do, I will have to change all my derived passwords but won't have to for the encrypted ones... I will add the password auto change feature. – CidTori Nov 13 '18 at 13:06
7

I have used deterministic password managers (pwdhash, what you call password derivation) for a long time and I wouldn't advice anyone to use a deterministic password manager. I also wrote a blog post about this, but I'll summarize my main issues here:

  • It is hard to determine the account to derive the password for. Maybe you want to use the same password for wikipedia.org and for wiktionary.org, or live.com and microsoft.com. Determining the account to use based on the domain name is pretty hard.
  • It is hard to conform to password requirements. Some sites don't allow passwords of 20 characters, and some sites require your password to be 20 characters. How is your derivation function going to handle that?
  • It is hard to change the derivation function. Once you use the derivation function, you depend on it for all your passwords. You can't increase the complexity or increase the length of the derived passwords or anything, because then you can't login anymore on all sites.
  • If you use some site to derive the password, such as lesspass.com or pwdhash.com, you supply that site your master password every time and that site generates your account password. This creates an enormous single point of failure. If that site is compromised all your accounts are compromised.

The main "advantage" is that a deterministic password manager doesn't keep state. However, it becomes increasingly easy to store state somewhere on the internet, either in a file in Dropbox or through some cloud service.

  • The password manager I described is closer to lesspass' "connected" version than pwdhash as far as I know. Instead of using the domain name as the salt, you can define rules based on the domain name to determine the account, use any salt to derive the password, and like LessPass define a pattern used to derive the password (length, authorized characters, etc.), all (but the derived password) being stored in the vault, so it should not have your first 2 issues and maybe part of your third – CidTori Nov 13 '18 at 14:06
  • Since you can configure unique parameters for the derivation function for each password, I think it would not be affected by your third issue. The only thing that should change from time to time is the round numbers: contrary to the master password that can be extremely strong from the beginning, the round number should be high enough to make the master password hard to recover, but low enough to be computed within a reasonable time frame, so it should roughly double every other year according to Moore's law. If the user thinks it's too cumbersome, he could use the auto-change feature. – CidTori Nov 13 '18 at 14:15
  • Which bring us to your fourth issue. I agree with you, but isn't it the same problem with password managers using encrypted passwords ? For most of them, you have to trust their website, browser extension or application. The only exception is for open-source and exclusively local vaults like KeePass, but then, wouldn't an open-source and exclusively local deterministic password manager provide the same security? – CidTori Nov 13 '18 at 14:21
  • 1
    @CidTori, you are missing an important security point from the answer. With the generation scheme, your passwords are not independent of each other. An attacker who gains access to any one of your passwords, including from sites that don't hash passwords at all, is in a position to crack all of them. To crack a master password for a proper password manager, the attacker would need to acquire your data. Learning any of your individual passwords would not help them. – Jeffrey Goldberg Nov 14 '18 at 23:01
  • As for "you need to trust the website of the password manager", take a closer look at the design of KeePass. You only have to trust that its developers deliver non-malicious software. No decent password manager software or service (disclosure: I work for 1Password) would ever want to have the ability to decrypt your password. If you are only going to trust things that you review and compile yourself, that's fine. But if you are going to "roll your own" you should seriously study why password managers are designed the way that they are. – Jeffrey Goldberg Nov 14 '18 at 23:08
1

There are no practical advantages to using the derived password function based key manager.

If you can't trust the vault to correctly use AES and PBKDF2 to secure a password database, you can't trust it to secure a derivation algorithm's parameters, either. There is no security difference in storing a master password or a derivation algorithm (assuming a correctly designed key manager, of course.)

Various sites and applications have mutually differing requirements, such as password length, special character requirements, etc., so each site still needs some extra info stored. It may not be secret data, but it still needs to be managed in both systems.

Password rotation policies vary, and can be a problem (or at least require even more information stored on a per-site basis.) If you use multiple clients (laptop and cell phone, for example) you still have to synchronize the extra data just as you would a stored password.

A derivation-only system can't store assigned passwords. If you deal with external systems such as an enterprise password manager, the external manager may be responsible for rotating and generating new passwords.

The per-key delay you mentioned for the derivation function doesn't make much sense. A password manager employs an algorithm like PBKDF2 to prevent guessing the master password at the initial decryption of the master key; each password decrypted after that takes microseconds. Note that the same delay could be added to a traditional password manager. However, there's no benefit in slowing your own system down when it doesn't impact the attackers.

Derivation functions have been popular with humans because they can be memorized: it's easy to work out in your head that your password for google is Cid123!@#googlE, etc. But a modern computer can just as easily generate and store a high quality random string for each site. In this age of 64GB+ flash chips in mobile phones and terabytes of storage in computers, the dozen megabytes of storage required for thousands of web site passwords simply isn't a practical issue. And with cloud based storage and ubiquitous cellular data coverage, sharing passwords across multiple devices also isn't an issue.

  • I'm not sure that "There is no security difference in storing a password or a derivation algorithm": for example, if an attacker manage to get your unencrypted vault or your encryption key, he gains access to all your passwords (but the master password, protected by PBKDF2 in the encryption key) ; with a derivation function, he only gains access to the passwords parameters, which should be considered public anyway by Kerckhoffs's principle when deriving the password. – CidTori Nov 14 '18 at 9:30
  • However, if an attacker manage to get your password for a specific account, he gains 0 knowledge from a random password, but could try to crack a derived password to gain access to your master password. So there are (theoretical) differences. – CidTori Nov 14 '18 at 9:30
  • I don't see your point in your two paragraphs "Various sites [...]" and "Password rotation policies [...]": in the manager I described, those data are managed and synchronized by both systems, so what is the difference? And what is the problem with password rotation? With a derived password, you can simply add a counter or a random salt, depending on your needs (a counter is guessable, so it may be less secure but can be recovered if needed), and it becomes just another parameter: that's what LessPass uses. – CidTori Nov 14 '18 at 9:41
  • However, I totally agree with the fact that: "A derivation-only system can't store assigned passwords", of course. That's why in the manager I described, you can chose between both systems: you can't do without stored passwords for all cases, but you can do without derived passwords. This is an interesting practical difference between these systems. – CidTori Nov 14 '18 at 9:48
  • I'm not sure I understood your paragraph "The per-key delay [...]": as I mentioned in my second comment, that delay is mandatory if you use a derived password, because if an attacker gains access to one of your passwords, he could try to crack it to find your master password, so you do not have a choice. However, that means it's another difference between these systems: with a derived password, you will have a delay each time you want to derive it ; it won't be a problem for a stored password. – CidTori Nov 14 '18 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.