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?
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
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.).
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.
