Question says it all, should passwords be stored using 2 way encryption or just 1 way?
Whatever - the important thing is that the decryption key is held securely and independently of the data - that implies asymmetric encryption which is computationally very expensive - and there's usually no significant benefit compared with a hash + secure reset mechanism.
Passwords should be stored via a salted hash. Encryption implies that you essentially want to/are able to decrypt it. A one way hash is best, then you can simply compare your existing hash to the one that the user uses to login or whatever the task.
Point is... one way hash.
Edit: As per Stevens comments. The following RFC 2898 covers some crucial hashing techniques. It also makes for a thumping good read.
One way hashing is the way to go. I would not be happy if somebody could decrypt my password if he somehow gets access to the database it is stored. It's a real security issue if it is possible to decrypt passwords.
Just always save a hashed password and afterward compare the hashed input with the hash in the database. That's by far the most common and most save basic authentication method.
They should be stored using a one-way encryption (or salted hash function) whenever possible.
Situations where it might not be possible are cases where your application needs to use a password to log in to an external system (such as a database) that only supports plain-text authentication. In that case, you need to be able to decrypt the password in order to log in.
But, if you're talking about how you should store the passwords that users use to access your application, one-way encryption/hash is definitely the way to do it.
Hashing is a random string, encryption is obfuscating a string that could then potentially be decrypted.
However, with hashing, it's also possible to produce collisions. It depends on your needs. If you think you need to re-gain the original string then encrypt the password. If it's just for user's passwords, then hash it. You can easily generate them a new password if they forget their current one.
Stretch and Hash your passwords. If you're lazy, just go with phpass which is used by Drupal and phpBB.
Now if you was storing some data that you was passing over a network that MAY be intercepted then you would use Encryption/Decryption
If your talking about credentials in the manor of password of a user then Hashing is the way to go.
The deference is that when you say Encryption you instantly have the retrievable side as well Decryption, With hashing you don't need to retrieve the value of the compiled text, just mealy check it against another hash
You can combine the the both together for transferring data across the web, but they still stay the same, just use each other to validate each other.
An example of how you should hash in PHP is like so:
The Hash
define('LOCAL_USER_SALT',£F$%^GH*&^%HG&*^%F&*(K(*');
Then this Hash should never change, this is what static hash and would be used to tripple hash a password, let me show you
class User
{
//..
function AddUserToDatabase($username,$password,$meta = array())
{
//Create a db salt
$salt = md5(uniqid() . microtime() . $username . microtime(true));
//Now we create a hashed version of the
$password = md5($password . $salt . LOCAL_USER_SALT);
//Then you would insert the $salt and $hash to the DB
}
//..
}
After reading the comments, you can check like so:
class User
{
//..
public function CheckCredentials($username,$pass)
{
//Get results from DB where $username is set in the column
//lets say $db_row is the data from the sql query
$check = md5($password . $db_row['salt'] . LOCAL_USER_SALT);
if($password == $check)
{
//The user exists.
}
}
//..
}
So this is called 1 way hashing, there's no need to have a reversible algorithm for your users credentials.