Login system using authenticated encryption without storing user password

Question

I'm not a security expert, so I might be asking a silly question, but let me describe what I am thinking about.

First, I know that a lot of web sites store hashed/encrypted passwords which could be decrypted by brute force attack once the table on db is hacked. Hackers might even be able to use the passwords in other websites and access other confidential info.

Given that AES cannot be broken why can't we just use a logic similar to the authenticated encryption? here is another relevant link. For example,

1. Prepare 1kb random binary file as expected file.
2. Encrypt the expected file using a hashed password
3. When a user logs in the system, validate the password by decrypting the encrypted file and check against the expected file. If fails reject the log-in. I suppose we can use the same logic for secret questions and answers for resetting password without actually storing answers.

If the confidential files are also encrypted using the password, then I guess the user will not be able to reset password. Is there any way to do it?

While writing this, I found a very similar question, but they are talking about client side decryption and I'm talking about server side (or only within the local system).

I'd really appreciate any comments and suggestions.

Answer 1

Actually your proposal is just a variation of a hashed password. Only in this case it is not the hash which is verified, rather an encrypted/decrypted blob. Hence it has mostly the same advantages and drawbacks of (reasonably implemented) hashed passwords. See PBKDF. When properly designed - like e.g. bcrypt (c.f. Do any security experts recommend bcrypt for password storage?) - it offers rather good security for most scenarios.

The question you are referring to (user authentication by decrypting a random blob) actually covers it rather well, I'd say.

As for user's data encrypted by the password - change in the password would of course require re-encrypting anything encrypted with the old one (i.e. decrypt with old one, encrypt with new one), which is generally performance expensive thing to do. This is usually circumvented in a layered manner: the data itself is encrypted with a randomly generated key, which in turn is encrypted with a password-derived one. If one decides to change the password, all that is needed is re-encrypting the real encryption key. It also allows one to use several passwords to access the same data (one example of this very way of encrypting data is LUKS).

That said, should you intend to create your own cryptography solutution, read Is my developer's home-brew password security right or wrong, and why? first.

Answer 2

In your proposed scenario, we take a password P, hash it to produce a key K that is H(P), and then encrypt a file using K.

The server validates the login by decrypting the file with K.

Your big issue here is that to decrypt the file, the server needs to know K. Which means the server needs to store either P or K in cleartext, and you've lost all the computational complexity of storing password hashes.

You're confusing yourself by being imprecise with your terminology. What you are describing as a password is actually just a seed for producing the login password, which is the hash of your seed.