Why not use AES for password encryption in PHP?

Everywhere I have seen people talking about storing passwords in a database, they have almost always used MD5.

What is wrong with AES, or SHA1?

AES-256 encryption, PHP to MySQL

I’m attempting to use this encryption system with PHP. It comes with this code from the download. $salt = ‘nala321’; $password = ‘Alan’; include(‘./crypt/Crypt/AES.php’); $aes = new Crypt_AES(); $aes-

PHP AES encryption padding NULL

I am try to setup an AES encryption. And i am using the following lib, it works great. http://www.coderelic.com/examples/AES_Encryption_Example.php However the external business told me to use padding

PHP iOS AES Encryption

I’ve been having trouble trying to communicate between PHP and my iOS application using AES encryption. So far, I’ve considered two methods of implementation. The first was to use OpenSSL. On the iOS

AES Password Encryption

Can anyone explain how this string has likely been encrypted at all? AES256:29://(Hex://5B18C3AD8CFR4D38) I’ve never seen an encryption has like this before in my life. Would it be possible to repli

AES -192 encryption/decryption using php?

I have done AES128 encryption/decryption in php using the AES128 script available at http://www.phpclasses.org/package/3650-PHP-A-pure-PHP-AES-128-encryption-implementation.html or http://www.phpclass

Password Encryption / Database Layer AES or App Layer AES

I need to encrypt / decrypt passwords for a new application. The spec requires me to use AES; can anyone suggest a good reason to either Do all my encryption in the database layer using CLR functions

Why does PHP crypt function use DES encryption algorithm?

Given that the rule of thumb is to store salted hashes of the password string, not the encrypted form of it, why does the PHP crypt() function use the DES-based algorithms? Isn’t DES an encryption alg

PHP AES encryption PKCS5Padding

So basically I’m not a PHP coder and that’s why I need a little help here with PHP AES encryption.I’m using a code where I am encrypting image files and than decrypt them with Java (Android).Everythin

AES encryption in mysql and php

There is a function in Mysql AES_encrypt. SELECT AES_encrypt( Hello World, password ) AS encrypted_value This gives the result: 9438eb79863e7009722fc3f0ad4b7198 But when I use the code in php to

AES 128 encryption in Java, PHP – difference in outputs

Followed AES 128 encryption in Java Decryption in PHP in writing the code for aes 128 encryption between Java and PHP (decryption – java, encryption – PHP) Java Code import java.security.MessageDigest


If you store a password encrypted, it can be decrypted. Since many people reuse passwords across many different systems, this is a bad thing. So you use a one-way function, a cryptographic hash function – this way a password can be verified without actually being revealed.

As Greg commented, AES is an encryption/decryption algorithm. MD5 and the SHA family are hash functions, which are the more appropriate ones to use. But steer clear of MD5 nowadays – it’s not really seen as secure enough any more. Xiaoyun Wang published an effective collision attack against it in 2005, and its strength is now seen as considerably below its design strength – thus in cryptographic terms it is “broken”.

For best results, the standard is to salt and hash a password to store it – google these terms in tandem and you’ll find numerous references.

MD5 (Message-Digest algorithm 5) is a cryptographic hash function, while Advanced Encryption Standard (AES) is a symmetric-key encryption algorithm, so they are used for different purposes. A hash, like MD5 or SHA is used to verify passwords because it’s hard to invert, that is, to obtain the password from the hash-string. An AES encryption, on the other hand, is invertible, the original message can be obtained if you know the key. So, if multiple messages are encrypted with the same key, knowing it exposes all of them, whereas if you manage to find a hash’s original string(rainbow tables, etc), you’ve only discovered the plain text for that particular instance, and you’ll have to redo the work to find a sollution for another hash-string.

Because AES encryption is symmetric. Given a password encrypted with AES and the key, you can decrypt the password. This is undesirable, because you almost always want only the owner of the password to know it and don’t want to have an easy way to derive the password. The SHA and MD5 algorithms, on the other hand, perform a (mostly) one-way transformation of the password. There is no piece of information (key) that allows you to return the transformed password back to its plaintext form.

The use of AES as a symmetric cipher for passwords would be a volation of CWE-257 and there for a vulnerability. It is possible to use a symmetric cipher as a hash function. Old unix passwords use DES as a hash function and newer unix systems use blowfish as a hash function. But even though its a block cipher, its being used as a one-way function, which is a requirement for any password storage system.

For php you should use sha256.

In short: AES is reversable. A hash function is not.

In response to the accepted answer… (sorry, I’m a new user, can’t post comments yet…) Salting only prevents Rainbow Table based attacks. It does not protect “weak passwords”. To protect the weaker passwords, you will need to use a hash function that has been proven to be slow. A properly configured bcrypt is the easiest way to do this. MD5 and SHA1 are too fast to be secure. (The collisions found with MD5 are unrelated to this problem I’m describing)

All 8-character passwords encrypted with MD5 or SHA1 (even when properly salted) can be cracked by this dude in a single day. Salting does NOT prevent this kind of attack. “Optimizing” the attack to consist of only the ~500k words in the english language… and the 10,000 most common variations of them will crack a huge number of passwords.

BCrypt is stronger against this kind of attack because it (can be configured to be) millions of times slower than MD5. Iteratively using MD5 a million times will theoretically achieve the same thing, but I suggest you stick with well tested libraries instead of rolling your own implementation. BCrypt uses Salting as well of course, and is available in most programming languages. So no reason to NOT use it.

In theory, SCrypt is better, but its too new (and therefore, implementations are probably still a little buggy)

Long story short: http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt

The main reason why using symmetric (or asymmetric) encryption is not advisable for protecting passwords is: key management. When using encryption, you must protect the encryption key (or the entropies from which the key is derived). And protecting the key is a very difficult task to solve. Hashing (with SHA, MD5, or any other algorithm) solves the problem of key protection, because you don’t need to keep any secret value (other than salt, but salt is significantly less sensitive than encryption key; you can store salt in plain text). So if you only keep passwords for authentication purposes (performed by your app), there is absolutely no reason to use encryption; hashing would do just fine. However, there may be cases when you need to be able to decrypt passwords (e.g. you may need to pass users credentials to third party apps). This is the only case, in which the use of encryption would be justified for password storage.