I am using following way to encrypt user's passwords which is AES Encryption. I just want to know is this a good practice or is there any other method should I follow. Because someone made me confused saying "Why don't you use "SALT". Can I use SALT AES Encryption? with Bellow is a sample query I am using.
INSERT INTO user(id,passowrd) VALUES (1,AES_ENCRYPT('mypassword','key'));
That aside..
Salt isn't an encryption method, it's a random bit you need to add to each password before hashing to protect against dictionary attacks.
You should not be storing user passwords using AES encryption, which is reversible. You don't care what the user's password is, only that they know it: so don't store the password in a reversible form.
Instead, you use a secure one-way hash, such as SHA256 or even bcrypt, of the password plus some random data. This random junk, the "salt", is generated for each user and appended to the password before hashing. It is then stored in the database along with the hashed data to enable you to compare the passwords later.
This way, an attacker with what's called a rainbow table (a big dictionary of hash-to-plaintext mappings) can't come along and see "oh look, Joe User decided to make his password 'password'!". This also protects against someone brute-forcing all the passwords in your database, since if each account has its own independent salt, each password must be independently attacked.
You wouldn't use "SALT" with AES, typically it's used with SHA.
Great details and explanation can be found at:
A salt is a sequence of characters added to a string about to being hashed, so it's harder for an attacker to obtain the original string.
However, for a cipher algorithm that is not based on hash, a salt isn't necessary, because the attackers will obtain anyway the original string with the salt, and it's just needed logic to remove it.
With AES_ENCRYPT the key you're using IS the salt. I prefer one-way hashes like MD5 or SHA, but many like decryptable passwords like you're storing.
