I don't want to store passwords, can I use them as an encryption key for another field?

Question

I'm not a 'cryptographic' anything, so if this is a super-dumb question please let me know (politely).

---

So here's the deal, say I don't want to store passwords because that opens me up to all sorts of failures (see: Facebook). Instead, I want to use the passwords as a key for something else.

Let's assume our process is:

1. User enters a password, we use 2FA, so we use that password to DECRYPT (via some KDF + et. al.) the Phone Number or Email (whatever the 2FA calls for here), and start the 2FA process;
2. User passes 2FA, we log them in;

Now, my thought is that this should be an acceptable process, but I'm not a cryptographic expert on anything, so I'm curious on whether this is an adequate method of storing the password + 2FA component. It seems reasonable, after all, we're no longer actually storing the password, and with a sufficiently-strong KDF we add another layer of security by not using the raw password in the encryption process, meaning if someone manages to break it (let's say we use something like AES-256, or whatever the de-facto standard is) and extract the key, they have the KDF-transformed key, not the raw key.

Additionally, my thought here is that this solves the following problems:

1. Storing the password in plain-text (obviously);
2. Abusing the MFA components (as a certain, nameless, company has starting using that Phone Number for marketing purposes);

Does this make sense? Am I talking about something the world / experts have decided is a terrible idea?

Answer 1

It kind of makes sense, but there are some hairy details.

---

To use a password as a key you need a password based key derivation function or PBKDF, not just any KDF. Otherwise the adversary can try and guess the password and try to decrypt anything you encrypted with it. Generally that would take just one additional block decrypt, so that's generally a fast operation. So you need a work factor (or, for specific PBKDF's, iteration count) to make it harder to guess the password. Just like when storing a password hash, for the same reason you will probably also want to a salt. The salt / random may also be required to stop replay attacks.

This does however mean that the user suddenly has to perform the work factor; generally password hashes are calculated server side. This might be an issue if the client has limited computing facilities - or battery life / heat dissipation issues, etc.. More importantly, if the attacker learns the key from your DB, then the attacker can simply skip the calculation altogether.

---

Generally we don't encrypt known / public data. It may be easy to slightly alter the data by adversaries, which in turn may result in surprising attacks. Generally we use a MAC such as HMAC over the data instead. That way you can verify if the key is correct by simply validating the MAC.

---

There are many other ways to verify passwords. For instance, you could have a look at PAKE protocols or SRP.

You haven't really indicated why simply storing a password hash is not sufficient either. Currently you are making your life more difficult without making your protocol more secure.