Stop Storing Passwords! Often i see code from people who don't know how dangerous it is or how to properly store user credentials. The many Anonymous hacks in the past year that resulted in the leaking of users' passwords also show that many sites still store passwords in either clear-text or encrypted form.

Here is how its done Right so you store never a Password! After that or i need to Crack you down :D.

The biggest issues with storing passwords are:

It's always possible that someone can get access to your database even if it's not directly exposed to the outside world, which it never should be. Whatever security stuff you've put in there to protect your database, it's a good idea to assume that sooner or later, someone will be able to break your security efforts and be able to read the data. You really don't want to store clear-text passwords. You also don't want to store encrypted passwords because encrypted data can always be decrypted. And if people get access to those encrypted passwords even if they weren't supposed to, it'd be wise to assume that they also know how to decrypt them, or that it won't take them long to figure it out.

The Solution:

Store a hashed version of the password using a strong one-way cryptographic algorithm and a unique salt value per password. If the cryptographic algorithm is one-way, it means you can't apply another algorithm to get the original source value again. The only way to compare passwords is to apply the cryptographic algorithm on a given password using the originally used salt value, and then compare the resulting hash with the one you've stored. If they are identical, the given password is the same as the one that was used originally. If they differ, the password is invalid.

Attackers can still employ rainbow tables to try to find password values that generate the same hashes as the ones in your database. Generating rainbow tables takes much time and plenty of machines botnets as well so it makes it much harder for attackers to find the passwords. This is why it's so important to use a unique salt value per password. It effectively means that a rainbow table would have to be generated for every single salt value that you've used, making it practically infeasible to find the original password values.

Prove of Concept example. In Node.js but this can be applied with whatever language you're using PHP Example is also in my link.

NODEJS

a example mongo database user model would look like the following but i have setuped a git repo with commented source so you can learn it better! link

var mongoose = require('mongoose'),
crypto = require('crypto'),
uuid = require('node-uuid'),
Schema = mongoose.Schema,
ObjectId = Schema.ObjectId;
var userSchema = new Schema({
name: { type: String, required: true, unique: true },
email: { type: String, required: true },
salt: { type: String, required: true, default: uuid.v1 },
passwdHash: { type: String, required: true }
});
var hash = function(passwd, salt) {
return crypto.createHmac('sha256', salt).update(passwd).digest('hex');
};
userSchema.methods.setPassword = function(passwordString) {
this.passwdHash = hash(passwordString, this.salt);
};
userSchema.methods.isValidPassword = function(passwordString) {
return this.passwdHash === hash(passwordString, this.salt);
};
mongoose.model('User', userSchema);
module.exports = mongoose.model('User');

If your Interested go to the git you will probally understand it then there are 4 files the complet flow! create user -> with db model -> resulting exampledbentry -> and finaly auth method

PHP & NODE JS EXAMPLES in My Git Repository

link