Generating Complex Passwords from (Non-)Memorable Phrases - Need Advice

Question

I've been thinking about creating strong and unique passwords for my online accounts, but I also want them to be memorable. I've come across the idea of using a memorable passphrase as the basis for a complex password generation. Specifically, I'm considering hashing the passphrase to generate the complex password, such as hash function like SHA-256 or bcrypt to convert the passphrase into a fixed-length hash. This hash will serve as my complex password, usually for PGP keys or encrypted database for other passwords.

Example: input > MD2 > Base85 (=password)

• Input passphrase: password
• MD2: f03881a88c6e39135f0ecc60efd609b9
• Base85: AhZ##3&[email protected]@q.DNAS,I20KET&

That gives entropy of 210 bit. Yet, the input is extremely poor.

I'd love to hear your thoughts and any advice you might have on this approach. Is it a good idea for creating strong passwords that are also easy to remember in such a way having a scheme? Are there any security concerns or best practices I should keep in mind, ora any other tools for that purpose?

================================================= EDIT:

After reading several comments I try to understand the concept. First, I didn't say that only hashing will make my password "safe". My initial question would mean: Why would having a strong passphrase be equally "strong" as "passphrase + flushing through various hashes, rotations and encryption methods"? In the former case the attacker needs to go through brute force of the plain-password phrases, in the latter case he needs to do the first phase of attack first to proceed to the second, and having in mind how many combinations and rotations one can imagine, it is adding an extreme layer of difficulty.

Let me explain a bit more sophisticated, instead:

• Input: мой password is חזק
• DES Encrypt: Key ("MySecret" Latin1), IV (密码01 UTF8), CBC, In/Out:Raw
• Base85 (output password): Lkp.F?sa:8g^-4..,^E5:iF+SFV<s<

So, I have made by purpose all input in different languages. In reality it can be something equally complex yet very easy to remember. By having 密码01 - as an obvious example, I can create several passwords by increasing it to 密码02. The next password would result in: GHpS9fl'b8C*QImok46gDm4K"bO=qq

Answer 1

That gives entropy of 210 bit.

No.

Suppose the enemy knows or can usefully assume that Alice sends only 0 or 1 after flipping a fair coin, and such a flip is channel-encoded in ASCII as either

• 0: cb530c5177b16f897d9e1f1ee1ff5a0d5e1b7aae8b313746d61d21b7 or
• 1: a5d8adf6032b5f333d9cd6696dd0c520b4dca7f0c3238aa8de33e87c

Did Alice send 56 × 8 == 448 bits of entropy? Or 56 × 4 == 224 bits of entropy? Certainly not. Alice sent a single bit's worth of entropy, from which the remaining channel bits can be trivially derived.

If the attacker can usefully assume that Alice only chooses 8-char lowercase passwords that appear in Webster's dictionary, then we certainly infer that there is less than 210 bits of entropy. Webster's contains far fewer than 2 ^ 210 8-char words.

---

Prefer the SHA-3 family of hashes over MD2.

https://datatracker.ietf.org/doc/html/rfc6149#section-7 published 2011

MD2 is clearly showing signs of weakness, and implementations should strongly consider removing support and migrating to another hash algorithm.

Answer 2

That gives entropy of 210 bit. Yet, the input is extremely poor.

Not quite. Hashing won't confer any additional entropy than what is present in the inputs.

---

Is it a good idea for creating strong passwords that are also easy to remember in such a way having a scheme?

Usually, to a memorable root passphrase. Maybe, to preprocessing the root passphrase.

A memorable root passphrase⁽⁰⁾ can be a good idea if you want to be able to access it without trusting⁽¹⁾, or having access to, a particular device or service. Most humans have memories that are limited in how well they can remember really good passwords / passphrases. The better the passphrase, then the more challenging it will be to remember (generally). So, having a single really good passphrase which opens an encrypted password manager is usually the way to go.

^{Illustration: xkcd comic on the security of passphrases.}

Preprocessing the passphrase with a memory-hard⁽²⁾ password-based key derivation function (KDF) like Argon2⁽³⁾ can be a good idea. For instance, to slow down the process of an adversary guessing it. This slow KDF turns the passphrase into a uniform initial key that requires effort to bruteforce. It can then be used as the input to a more efficient KDF, which can finally produce different domain-separated⁽⁴⁾ cryptographic keys⁽⁵⁾ for different purposes. But key derivation can be tricky⁽⁶⁾. It is possible to reduce the security provided by the passphrase if key derivation is done poorly. This also means that every key derived from the root passphrase will be compromised if or when the passphrase is compromised. Password (or more generally, Secrets) managers are neat because all the secrets inside can be completely independent from each other, as well as, from the root passphrase.

---

Are there any security concerns or best practices I should keep in mind, ora any other tools for that purpose?

Yes, there are many security concerns. Yes, there are many tools.

I cannot list all the security concerns, some of them are discussed here. I'll mention three best practices: 1. Understand your hash functions⁽⁷⁾⁽⁸⁾; 2. Separate your domains^(9)(10); 3. Canonicalize all your inputs^(11)(12).

There are many common secrets management tools & recommendations^(13)(14)(15) which you can look into.

Answer 3

You mentioned that the password could be used for PGP keys or an encrypted database.

This means that the attack can happen offline, and can be massively parallelized. A determined attacker could temporarily rent thousands of GPUs to attempt to crack your password. They might even figure out how to inject malware into copies of pirated video games that are shared widely, and get those GPU resources for free.

To be crack-proof, the gold standard is 128 bits of entropy in the password.

You can reduce the entropy of the password a little, as long as "password stretching" is used to get you up to 128 bits of strength. If you use something like Argon2, then depending on the number of rounds and the time you're willing to wait, you might be able to stretch 90 bits of password entropy into 128 bits of strength. You would salt Argon2 with an identifier unique to you and the particular domain in which the password will be used (such as your email address, and the name of the application/database you're protecting), to prevent an adversary from using a rainbow table.

90 vs 128 bits is the difference between a 7-word password and a 10-word password, assuming words are chosen randomly from a 10,000 word English dictionary.

Therefore, password stretching is of limited use. You can't get from "big red elephant" to 128 bits of strength with password stretching.

Note that if you are picking random English words, they should be truly random. Entropy will be much lower if you choose words which are easier to remember (whether individually or as a combination).

The approach in your question relies on security by obscurity. The only reason that AhZ##3&[email protected]@q.DNAS,I20KET& would be a harder password to guess than password is that an attacker might not think to try your particular technique (password -> MD2 -> base85).

You should be abiding by Kerckhoffs's principle, which asserts that you should assume that an attacker knows everything about the process you are using, other than the initial entropy. Otherwise, it's too difficult to reason about exactly how unlikely it is that an attacker will think to try your technique.