Please correct me if any of my statement is incorrect.

It is probably more good practice to not show any hint of the password.

However, AES encrypted passwords by itself cannot be used to decrypt the password or find the key; known-plaintext attack does not work with AES. This means that revealing the encrypted password doesn't really hurt anything.

So, is it safe to reveal AES encrypted passwords in web applications?

  • 8
    Side question: why are passwords encrypted and not hashed?
    – schroeder
    Apr 14, 2016 at 23:45
  • 1
    Another question: what do you mean by "safe"? It is possible to brute-force the decryption of an encrypted string.
    – schroeder
    Apr 14, 2016 at 23:50
  • 1
    Generally isn't it what LastPass and some other password managers do?
    – techraf
    Apr 15, 2016 at 0:23
  • @schroeder: To answer your first question. This password is for the database connection and by the design we did not want user to enter password every time and match with the hashed password. By using encryption, we can ask password once, saved the encrypted one and decrypt every time when the connection is needed. For your second question, let's put it "in general". Sorry I don't have much good answer on this. I was hoping experts can add details on this.
    – Harry Cho
    Apr 15, 2016 at 17:39
  • @HarryCho: rather than AES, you may be better served by using a key derivation function, like PBKDF2, bcrypt, or scrypt for that kind of scenario.
    – Lie Ryan
    Apr 16, 2016 at 1:28

2 Answers 2


Main answer

In summary, you are completely right with your first assumption:

It is probably more good practice to not show any hint of the password.

There are a few issues with the rest of your question though:

  • You do not want to encrypt passwords.

    Usually, that is, at least.

    schroeder rightfully asks in the comments

    Side question: why are passwords encrypted and not hashed?

    Thing is: If you encrypt the passwords instead of hashing them, you can always decrypt them and use them. Usually, the key for decryption has to be somewhere in the application for the data to be of any use.

    Hence, if someone stole your application's data - which isn't that uncommon (and the usual reason for credentials to show up on haveibeenpwned) - that someone has all passwords in clear text.

    Thus, you usually want to hash passwords - there are well received Q&As here on how that works.

  • You do not want to use plain AES

    If you use plain AES, the same password encrypts to the same ciphertext.

    If someone has access to all ciphertexts, statistical analysis is likely to give away the plain text of at least one ciphertext - and all accounts with that password are automatically breached.

    An example: If you know the most often used password is cucumber, you go ahead and look for the most often appearing ciphertext - the plain text is likely to be cucumber.

    Also, this restricts your users' passwords to the block size. This might be not what you (or your users) want.

  • You do want to give away as little information as you possibly can.

    Even publicly listing proper hashes of user passwords would be a pretty bad idea, as - again - schroeder already put in the comments:

    Another question: what do you mean by "safe"? It is possible to brute-force the decryption of an encrypted string.

  • Encrypting passwords is basically a plain text offense, according to Plain text offenders' FAQ

    1. But the site says they store my password securely using [something]!

      Your password is yours. It is the means by which you identify yourself to a site. If a site can tell what your password is after you gave it to them, anyone can know what your password is (hackers, disgruntled employees, people stumbling onto it by accident, etc.).

Side Note

While AES with a reasonable mode of operation is not vulnerable to known plaintext attacks (I think what you had in mind was "I know my password, I can extrapolate the key and know all passwords"), using plain AES will, as said before, increase the chances of an attacker to win in a CPA model.

Which is basically what you have, given that a user can change his/her password.


No, it is not.

While it is the very purpose of encryption, to protect the data inside the encryption (provided the key is secure!), there is a very clear vulnerability, which passwords, specifically, are quite vulnerable to:

A given input string, encrypted with AES, will always give the same output.

This means that, if two users have the same passwords, and one is compromised, then the other is automatically also compromised.

As an example, lets say I set my password to the most common password: "password". I get the AES encrypted string. I then change it to "123456", and get this encrypted string. I gradually work my way through the top 10,000 passwords, generating 10,000 encrypted strings (and their unencrypted passwords). I have no idea what key was used.

Now, I go to a random other user. There is a 90% chance that I can look up their AES-encrypted password in my rainbow table, at which point I can see exactly what their password is.

Password hashes are also vulnerable to this. This is why salt & pepper are normally used.

Additionally, for longer passwords, if the first block (16-32 characters) of the input matches, then the first block of the output will also match. So, if the password is "My login name is AMADANON Inc.", and someone else's password is "My login name is Harry Cho", and my password is compromised, then the first 16 characters of your password are also known.

While these issues might be worked around, there is also a bigger issue: if someone gets the AES key, then all the passwords are plaintext. AES keys are, pretty inevitably, stored pretty close to the encrypted passwords (on the same machine). you should accept that, if malware gets on to a server with both the AES key, and the AES encrypted passwords, then they are compromised.

The only reason to store an AES encrypted password, is on the client side, if you do not have control of the server side. Do NOT EVER do this on the server - use a good, standard hash, from a standard library, with salt and pepper.

If you are writing both the client and the server, DO NOT use passwords at all. At this point, you are not authenticating a user, but a machine. For authenticating a machine, passwords are the wrong tool. Instead, use public key crypto - TLS for example, with client authentication - again, there are libraries already written for you. If you want to authenticate the user too, put a password on the private key. Public key crypto has the advantages the secret never travels across the network, and the server doesn't know what it is; you prove that you have it without giving it to the server.

  • 1
    It looks like you are making a large number of assumptions as to what is going on in the OP's operational setup. If one of your assumptions is incorrect, large portions of this answer become invalidated.
    – schroeder
    Apr 15, 2016 at 14:41
  • @schroeder - there was limited information in the post. What assumptions have I made? (a) the database stores multiple users' passwords, (b) a user can change their password, (c) that the user can look at their password encrypted (d) people use crappy passwords - (a) is ambigious, but I am pretty confident of b, c and d. These premises, on their own, will leak enough information to be concerned about. If the (encrypted) password database gets out, it will allow building of a rainbow table. This is the same issue that required adding salt to hashed passwords. Apr 17, 2016 at 21:26

You must log in to answer this question.

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