Last Updated: February 25, 2016
· frank-dspeed

HOWTO: !!!NOT!!! Store Passwords in Applications!

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.


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


7 Responses
Add your response

@jimmykane ill write just for you a little php example :D

over 1 year ago ·

@jimmykane added the php part to the end simply read and follow it its best patrice

over 1 year ago ·

very nice :) love it.

over 1 year ago ·

@martinseener the best would be to use a own algo for those that are able to do so :D

over 1 year ago ·

@martinseener dont talk dude this examples using bcrypt and its save and a own one way ENCRYPTION is Always best no need to prove that ! who are you that your talking here? prove your self hack one of my algos and then come back and comment.

I am one of the best hackers on this whole planet i realy don't get the point of your comment its nice that you think you got a cloue about the facts your telling but i bet you got none so post for all of us what makes you qualifiyed to tell me whats wrong or right ???

Du bist ein Administrator aus berlin perfekt mach hier noch ein Kommentar das du ihrgend was weisst und wir machen als pro tip ein video von dir und mir wie du beweist das du nichts weist den pro tip nennen wir dan leg dich nicht mit Frank an wenn du nicht besser bist als er :D

over 1 year ago ·

@frank-dspeed WOW. the rest of the "security community" ... you know the ones who came up with the hash{password + salt}...will tell you to NEVER use a home grown, black box, custom crypto function. Security by Obscurity is a failure.

Also SHA-256 is a hashing function too FAST and therefore will give the attacker an advantage when brute forcing. There are other slower algorithms (PKBDF2, bcrypt) designed for this is exact purpose.

If you are a god please release your amazing algorithm on github. Cryptography Experts can verify your greatness.

Originally I would give this article 5/10. Your comments drop it to a 2/10.

over 1 year ago ·

@j3g i don't know where your point is normaly i shouldn't even respond but at all for the rest of the world what i say is right sure it is for advanced people to do own algos but its 100% saver then using a Public one. Sure it Brings nothing if your own algo is reversing the string + salt :D but no one is such silly that he would do that. And i don't need to use Own Algos if i whanted to make em public then they get useless.

I Think your a wanna be thats it but its ok every one has its place on earth you know your.

over 1 year ago ·