6

Flow diagram to show password generation

Counter

The counter is appended to the site name and incremented if you need to get a new password for a site or if the generated password is insecure because it randomly matches something like "password1" (see Quality Assurance)

Base 89

Where Base 89 is like Hex just with an alphabet of 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"$%&/{}()[]=\+*~'#-_.:,;| rather than 0123456789abcdef.

Quality Assurance

Quality Assurance would use something like zxcvbn to rate the security of the password. If it doesn't pass the test, the counter is incremented and the whole process is repeated.

Ask for clarification anytime.

Edit

New design This is my new design but @Gilles stated good arguments against a vaultless password manager.

  • Not a bad design, this is similar to many password generators, although the counter is an interesting addition. Where would you store the counter? – paj28 Dec 30 '18 at 2:04
  • You'd have to memorise/write down everytime you change your password on a site. If you don't remember it you'll have to try a few. And I thought about having an encrypted, non security critical Vault which would contain your site names and their counter. But if you loose that Vault it doesn't contain any important data – Ma_124 Dec 30 '18 at 8:37
  • 1
    Having a vault sounds greatly preferable to memorising those counters. By the way, I think you are over-estimating the security benefit of not having a vault. As long as the vault is encrypted, you only have a breach if you lose the vault and master password. In your design there is no vault, but if you lose the master password, you have a breach. – paj28 Dec 30 '18 at 12:36
  • I chose the vault-less design so you can't "loose" your passwords. – Ma_124 Dec 30 '18 at 13:30
  • @paj28 the counter doesn't need to be stored (as long as the "quality algorithm" isn't changed) since the choice of what counter to use would always be the same (the first number which matches quality criteria) – BlueWizard Dec 30 '18 at 21:00
7

The master key must be a sufficiently long, randomly-generated key. It must be at least 16 bytes generated uniformly at random (not 16 random printable ASCII characters and definitely not a human-chosen password or passphrase). Otherwise it would be possible to find the master key from any of the derived passwords.

This means that the master key is not realistically memorable by a human, so this scheme is not really vaultless.

If you use HMAC as the hash, then it's ok if the master key is not generated uniformly at random, but it still needs to have sufficient entropy to make a brute force search infeasible. For example, with Diceware, you need 10 words to reach 128 bits of entropy. Given that you'd have to change all your passwords if the key is ever compromised, don't settle for less.

Generating different keys from a master key is called key derivation. You're using a MAC as a key derivation function. This is probably ok with MAC that are used in practice, but it's dodgy. Any MAC guarantees that there's no way to find the master key from any number of (input, output) pairs, except for a brute force search over the set of permitted master keys. A MAC also guarantees that there's no way to find the output for a particular input without knowing the master key, even knowing the output for some other inputs. What a MAC does not guarantee is that there's no way to find the truncated output, and password length limits may require you to truncate the output. Rather than using a MAC, use a recognized KDF, such as HKDF (which is very easy to implement on top of HMAC, if your crypto library doesn't have it).

You could replace the MAC-should-be-KDF step by a password-based key derivation function such as scrypt or Argon2. This would let you use a master key with less entropy. Password-based key derivation functions are designed to take a password as the secret input and compensate for a smaller input space (less entropy than a normal-sized key) by being intrinsically slower to compute. For example, if the stretching factor makes it 1 billion times slower than HKDF (so it takes about 1 second on a PC) then it's enough to have 7 Diceware words (giving you 120 bits of entropy). Keep in mind that in this scheme, you won't be able to upgrade the stretching factor without changing all your passwords, so choose it conservatively.

The “quality assurance” step is badly named since it (slightly) decreases the security. It doesn't separate “weak” from “strong” outputs: all outputs have exactly the same strength. The strength if the output comes from how the output was generated, not from what it is. Call it an “output constraints” step, with outcomes “acceptable” and “not acceptable”. Note that you'll need different acceptability rules for every site (for example some sites insist on the presence of a punctuation character while others reject all punctuation characters).

Remember that you'll sometimes need to change your password on a site. So you need an additional public input “version” in addition to the site name. Make sure that the site name, the version and the counter are combined unambiguously. For example, plain string concatenation would not be ok since example.com123 could be version 1 with counter 23 or version 12 with counter 3. If you use printable strings for the site name, version and counter then you can concatenate them with a null byte as separator. You may also want to include a user name in there to support multiple accounts on the same site.

A practical limitation of this scheme is that you must only ever input the master key/passphrase on a system that you trust. This means only your own PC, only in circumstances where nobody might be spying on you (for example, not in view of security cameras). In particular, there's no way to create a password in a low-security environment and later upload it to your keyring. Every password must be generated in a high-security environment.

Since you need to carry your own PC to use this scheme, it is of limited benefit compared to a password vault. The only benefit is that if your PC is stolen while it doesn't have the master key in memory, you haven't leaked any secret. Balance that with the risk that if the master key is ever compromised, you've instantly compromised all of your passwords.

This scheme, if implemented correctly, is theoretically safe, but doesn't work well in the real world. It's well-protected against cryptographic attacks, but poorly protected against “out-of-band” attacks such as a physical keylogger, a keylogger malware or a security camera, or against revealing the master key through coercion or by accidentally typing it in the wrong field.

Your scheme is basically a single-factor authentication (only the master key) where a password vault is two-factor authentication (the vault content and the vault unlocking key). Two factors are more robust than one. A vault protected by a strong password is just as resistant to all the same attacks as your scheme, and additionally resists attacks such as shoulder surfing.

In terms of usability, both schemes require you to use your own trusted PC. Your scheme has the advantage that you can buy a new PC, retrieve your software from a trusted source, obtain an offline copy of the master key, and get access to your passwords. A vault requires the extra step of downloading the encrypted vault, but this is hardly ever a problem in practice: when would you need passwords but no have Internet access? As mentioned above, a vault has the advantage that it works in a common scenario where you want to create a password in circumstances where you don't have access to your PC, for example to create a password for shared work/personal use (e.g. a password for a travel-related site if you travel for work) on a work machine and then copy it to your personal vault.

I would strongly recommend a password vault over this scheme. It's more robust in real-world use cases.

  • Thank you for that great answer! I added the "Quality Assurance" step in case someone just runs a dictionary attack instead of targeting this method. Because the output of this algorithm could be 123456789. – Ma_124 Dec 30 '18 at 8:41

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.