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.

  • Please explain how this question is different from the one you linked about "user authentication by decrypting a random blob". At first glance it looks like an exact duplicate to me.
    – Luc
    Commented Jun 10, 2013 at 12:43

2 Answers 2


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.

  • I'd like to point out that Microsoft's Encrypting File System uses the same concept as LUKS at a file level (not disk level!). Each file is encrypted using a randomly generated symmetric key and the symmetric key is then encrypted using the user's EFS certificate (and any other recovery agents, allowing administrators to access the contents) and stored along side the file in an alternate data stream.
    – Joshua
    Commented Jun 10, 2013 at 14:16
  • Thanks peterph for pointing out that I was thinking about the exactly the same thing as the hashed password and your suggestion of bcrypt. Also, I'm not developing anything right now but I was just thinking too hard...
    – niea
    Commented Jun 10, 2013 at 20:03

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.

  • 3
    The server actually knows K: when the user tries to log in, he/she sends the password and the server hashes it to obtain the required key. The point is, that neither the key nor the hash are kept for longer than absolutely necessary to decrypt the file.
    – peterph
    Commented Jun 10, 2013 at 12:29
  • I see how it could be read that way. I suppose I had a much less charitable reading of how the asker was implementing this. Commented Jun 10, 2013 at 12:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .