security - Secure hash and salt for PHP passwords -

it said md5 partially unsafe. taking consideration, i'd know mechanism use password protection.

this question, is “double hashing” password less secure hashing once? suggests hashing multiple times may idea, whereas how implement password protection individual files? suggests using salt.

i'm using php. want safe , fast password encryption system. hashing password million times may safer, slower. how achieve balance between speed , safety? also, i'd prefer result have constant number of characters.

1. the hashing mechanism must available in php
2. it must safe
3. it can use salt (in case, salts equally good? there way generate salts?)

also, should store 2 fields in database (one using md5 , 1 using sha, example)? make safer or unsafer?

in case wasn't clear enough, want know hashing function(s) use , how pick salt in order have safe , fast password protection mechanism.

related questions don't quite cover question:

what's difference between sha , md5 in php
simple password encryption
secure methods of storing keys, passwords asp.net
how implement salted passwords in tomcat 5.5

disclaimer: answer written in 2008.

since then, php has given password_hash , password_verify and, since introduction, recommended password hashing & checking method.

the theory of answer still read though.

tl;dr

don'ts

• don't limit characters users can enter passwords. idiots this.
• don't limit length of password. if users want sentence supercalifragilisticexpialidocious in it, don't prevent them using it.
• never store user's password in plain-text.
• never email password user except when have lost theirs, , sent temporary one.
• never, ever log passwords in manner.
• never hash passwords sha1 or md5 or sha256! modern crackers can exceed 60 , 180 billion hashes/second (respectively).
• don't mix bcrypt , raw output of hash(), either use hex output or base64_encode it. (this applies input may have rogue \0 in it, can weaken security.)

dos

• use scrypt when can; bcrypt if cannot.
• use pbkdf2 if cannot use either bcrypt or scrypt, sha2 hashes.
• reset everyone's passwords when database compromised.
• implement reasonable 8-10 character minimum length, plus require @ least 1 upper case letter, 1 lower case letter, number, , symbol. improve entropy of password, in turn making harder crack. (see "what makes password?" section debate.)

why hash passwords anyway?

the objective behind hashing passwords simple: preventing malicious access user accounts compromising database. goal of password hashing deter hacker or cracker costing them time or money calculate plain-text passwords. , time/cost best deterrents in arsenal.

another reason want good, robust hash on user accounts give enough time change passwords in system. if database compromised need enough time @ least lock system down, if not change every password in database.

jeremiah grossman, cto of whitehat security, stated on blog after recent password recovery required brute-force breaking of password protection:

interestingly, in living out nightmare, learned lot didn’t know password cracking, storage, , complexity. i’ve come appreciate why password storage ever more important password complexity. if don’t know how password stored, can depend upon complexity. might common knowledge password , crypto pros, average infosec or web security expert, highly doubt it.

(emphasis mine.)

what makes good password anyway?

entropy. (not subscribe randall's viewpoint.)

in short, entropy how variation within password. when password lowercase roman letters, that's 26 characters. isn't variation. alpha-numeric passwords better, 36 characters. allowing upper , lower case, symbols, 96 characters. that's lot better letters. 1 problem is, make our passwords memorable insert patterns—which reduces entropy. oops!

password entropy approximated easily. using full range of ascii characters (roughly 96 typeable characters) yields entropy of 6.6 per character, @ 8 characters password still low (52.679 bits of entropy) future security. news is: longer passwords, , passwords unicode characters, increase entropy of password , make harder crack.

there's longer discussion of password entropy on crypto stackexchange site. google search turn lot of results.

in comments talked @popnoodles, pointed out enforcing password policy of x length x many letters, numbers, symbols, etc, can reduce entropy making password scheme more predictable. agree. randomess, random possible, safest least memorable solution.

so far i've been able tell, making world's best password catch-22. either not memorable, predictable, short, many unicode characters (hard type on windows/mobile device), long, etc. no password enough our purposes, must protect them though in fort knox.

best practices

bcrypt , scrypt current best practices. scrypt better bcrypt in time, hasn't seen adoption standard linux/unix or webservers, , hasn't had in-depth reviews of algorithm posted yet. still, future of algorithm promising. if working ruby there scrypt gem out, , node.js has own scrypt package. can use scrypt in php either via scrypt extension or libsodium extension (both available in pecl).

i highly suggest reading documentation crypt function if want understand how use bcrypt, or finding good wrapper or use phpass more legacy implementation. recommend minimum of 12 rounds of bcrypt, if not 15 18.

i changed mind using bcrypt when learned bcrypt uses blowfish's key schedule, variable cost mechanism. latter lets increase cost brute-force password increasing blowfish's expensive key schedule.

average practices

i can't imagine situation anymore. phpass supports php 3.0.18 through 5.3, usable on every installation imaginable—and should used if don't know certain environment supports bcrypt.

but suppose cannot use bcrypt or phpass @ all. then?

try implementation of pdkbf2 maximum number of rounds environment/application/user-perception can tolerate. lowest number i'd recommend 2500 rounds. also, make sure use hash_hmac() if available make operation harder reproduce.

future practices

coming in php 5.5 full password protection library abstracts away pains of working bcrypt. while of stuck php 5.2 , 5.3 in common environments, shared hosts, @ircmaxell has built compatibility layer coming api backward compatible php 5.3.7.

cryptography recap & disclaimer

the computational power required crack hashed password doesn't exist. way computers "crack" password recreate , simulate hashing algorithm used secure it. speed of hash linearly related ability brute-forced. worse still, hash algorithms can parallelized perform faster. why costly schemes bcrypt , scrypt important.

you cannot possibly foresee threats or avenues of attack, , must make best effort protect users up front. if not, might miss fact attacked until it's late... and you're liable. avoid situation, act paranoid begin with. attack own software (internally) , attempt steal user credentials, or modify other user's accounts or access data. if don't test security of system, cannot blame yourself.

lastly: not cryptographer. whatever i've said opinion, happen think it's based on ol' common sense ... , lots of reading. remember, paranoid possible, make things hard intrude possible, , then, if still worried, contact white-hat hacker or cryptographer see code/system.