A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2008 yearSecure hash and salt for PHP passwords - page 1
User InfoPosts
Secure hash and salt for PHP passwords#1
It is currently said that MD5 is partially unsafe. Taking this into consideration, I(d like to know which mechanism to use for password protection.

This question, Is “double hashing” a password less secure than just hashing it once?
suggests that hashing multiple times may be a good idea, whereas How to implement password protection for individual files? suggests using salt.

I(m using PHP. I want a safe and fast password encryption system. Hashing a password a million times may be safer, but also slower. How to achieve a good balance between speed and safety? Also, I(d prefer the result to have a constant number of characters.


The hashing mechanism must be available in PHP
It must be safe
It can use salt (in this case, are all salts equally good? Is there any way to generate good salts?)


Also, should I store two fields in the database (one using MD5 and another one using SHA, for example)? Would it make it safer or unsafer?

In case I wasn(t clear enough, I want to know which hashing function(s) to use and how to pick a good salt in order to have a safe and fast password protection mechanism.

Related questions that don(t quite cover my question:

What(s the difference between SHA and MD5 in PHP
Simple Password Encryption
Secure methods of storing keys, passwords for asp.net
How would you implement salted passwords in Tomcat 5.5

posted date: 2008-12-30 14:02:00


Re: Secure hash and salt for PHP passwords#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2008-12-30 14:02:01


Re: Secure hash and salt for PHP passwords#3
TL;DRDon(tsDon(t limit what characters users can enter for passwords. Only idiots do this.Don(t limit the length of a password. If your users want a sentence with supercalifragilisticexpialidocious in it, don(t prevent them from using it.Never store your user(s password in plain-text.Never email a password to your user except when they have lost theirs, and you sent a temporary one.Never, ever log passwords in any manner.Never hash passwords with SHA1 or MD5 or even SHA256! Modern crackers can exceed 60 and 180 billion hashes/second (respectively).Don(t mix bcrypt and with the raw output of hash(), either use hex output or base64_encode it. (This applies to any input that may have a rogue \0 in it, which can seriously weaken security.)DosUse scrypt when you can; bcrypt if you cannot.Use PBKDF2 if you cannot use either bcrypt or scrypt, with SHA2 hashes.Reset everyone(s passwords when the database is compromised.Implement a reasonable 8-10 character minimum length, plus require at least 1 upper case letter, 1 lower case letter, a number, and a symbol. This will improve the entropy of the password, in turn making it harder to crack. (See the "What makes a good password?" section for some debate.)Why hash passwords anyway?The objective behind hashing passwords is simple: preventing malicious access to user accounts by compromising the database. So the goal of password hashing is to deter a hacker or cracker by costing them too much time or money to calculate the plain-text passwords. And time/cost are the best deterrents in your arsenal.Another reason that you want a good, robust hash on a user accounts is to give you enough time to change all the passwords in the system. If your database is compromised you will need enough time to at least lock the system down, if not change every password in the database.Jeremiah Grossman, CTO of Whitehat Security, stated on his blog after a recent password recovery that required brute-force breaking of his password protection:Interestingly, in living out this nightmare, I learned A LOT I didn’t know about password cracking, storage, and complexity. I’ve come to appreciate why password storage is ever so much more important than password complexity. If you don’t know how your password is stored, then all you really can depend upon is complexity. This might be common knowledge to password and crypto pros, but for the average InfoSec or Web Security expert, I highly doubt it.(Emphasis mine.)What makes a good password anyway?Entropy. (Not that I fully subscribe to Randall(s viewpoint.)In short, entropy is how much variation is within the password. When a password is only lowercase roman letters, that(s only 26 characters. That isn(t much variation. Alpha-numeric passwords are better, with 36 characters. But allowing upper and lower case, with symbols, is roughly 96 characters. That(s a lot better than just letters. One problem is, to make our passwords memorable we insert patterns—which reduces entropy. Oops!Password entropy is approximated easily. Using the full range of ascii characters (roughly 96 typeable characters) yields an entropy of 6.6 per character, which at 8 characters for a password is still too low (52.679 bits of entropy) for future security. But the good news is: longer passwords, and passwords with unicode characters, really increase the entropy of a password and make it harder to crack.There(s a longer discussion of password entropy on the Crypto StackExchange site. A good Google search will also turn up a lot of results.In the comments I talked with @popnoodles, who pointed out that enforcing a password policy of X length with X many letters, numbers, symbols, etc, can actually reduce entropy by making the password scheme more predictable. I do agree. Randomess, as truly random as possible, is always the safest but least memorable solution.So far as I(ve been able to tell, making the world(s best password is a Catch-22. Either its not memorable, too predictable, too short, too many unicode characters (hard to type on a Windows/Mobile device), too long, etc. No password is truly good enough for our purposes, so we must protect them as though they were in Fort Knox.Best practicesBcrypt and scrypt are the current best practices. Scrypt will be better than bcrypt in time, but it hasn(t seen adoption as a standard by Linux/Unix or by webservers, and hasn(t had in-depth reviews of its algorithm posted yet. But still, the future of the algorithm does look promising. If you are working with Ruby there is an scrypt gem that will help you out, and Node.js now has its own scrypt package. You can use Scrypt in PHP either via the Scrypt extension or the Libsodium extension (both are available in PECL).I highly suggest reading the documentation for the crypt function if you want to understand how to use bcrypt, or finding yourself a goodwrapper or use something like PHPASS for a more legacy implementation. I recommend a minimum of 12 rounds of bcrypt, if not 15 to 18.I changed my mind about using bcrypt when I learned that bcrypt only uses blowfish(s key schedule, with a variable cost mechanism. The latter lets you increase the cost to brute-force a password by increasing blowfish(s already expensive key schedule.Average practicesI almost can(t imagine this situation anymore. PHPASS supports PHP 3.0.18 through 5.3, so it is usable on almost every installation imaginable—and should be used if you don(t know for certain that your environment supports bcrypt.But suppose that you cannot use bcrypt or PHPASS at all. What then?Try an implementation of PDKBF2 with the maximum number of rounds that your environment/application/user-perception can tolerate. The lowest number I(d recommend is 2500 rounds. Also, make sure to use hash_hmac() if it is available to make the operation harder to reproduce.Future PracticesComing in PHP 5.5 is a full password protection library that abstracts away any pains of working with bcrypt. While most of us are stuck with PHP 5.2 and 5.3 in most common environments, especially shared hosts, @ircmaxell has built a compatibility layer for the coming API that is backward compatible to PHP 5.3.7.Cryptography Recap & DisclaimerThe computational power required to actually crack a hashed password doesn(t exist. The only way for computers to "crack" a password is to recreate it and simulate the hashing algorithm used to secure it. The speed of the hash is linearly related to its ability to be brute-forced. Worse still, most hash algorithms can be easily parallelized to perform even faster. This is why costly schemes like bcrypt and scrypt are so important.You cannot possibly foresee all threats or avenues of attack, and so you must make your best effort to protect your users up front. If you do not, then you might even miss the fact that you were attacked until it(s too late... and you(re liable. To avoid that situation, act paranoid to begin with. Attack your own software (internally) and attempt to steal user credentials, or modify other user(s accounts or access their data. If you don(t test the security of your system, then you cannot blame anyone but yourself.Lastly: I am not a cryptographer. Whatever I(ve said is my opinion, but I happen to think it(s based on good ol( common sense ... and lots of reading. Remember, be as paranoid as possible, make things as hard to intrude as possible, and then, if you are still worried, contact a white-hat hacker or cryptographer to see what they say about your code/system.

posted date: 2008-12-30 14:15:00


Re: Secure hash and salt for PHP passwords#4
I usually use SHA1 and salt with the user ID (or some other user-specific piece of information), and sometimes I additionally use a constant salt (so I have 2 parts to the salt).SHA1 is now also considered somewhat compromised, but to a far lesser degree than MD5. By using a salt (any salt), you(re preventing the use of a generic rainbow table to attack your hashes (some people have even had success using Google as a sort of rainbow table by searching for the hash). An attacker could conceivably generate a rainbow table using your salt, so that(s why you should include a user-specific salt. That way, they will have to generate a rainbow table for each and every record in your system, not just one for your entire system! With that type of salting, even MD5 is decently secure.

posted date: 2008-12-30 14:18:00


Re: Secure hash and salt for PHP passwords#5
Google says SHA256 is available to PHP.You should definitely use a salt. I(d recommend using random bytes (and not restrict yourself to characters and numbers). As usually, the longer you choose, the safer, slower it gets. 64 bytes ought to be fine, i guess.

posted date: 2008-12-30 14:20:00


Re: Secure hash and salt for PHP passwords#6
SHA1 and a salt should suffice (depending, naturally, on whether you are coding something for Fort Knox or a login system for your shopping list) for the foreseeable future. If SHA1 isn(t good enough for you, use SHA256.The idea of a salt is to throw the hashing results off balance, so to say. It is known, for example, that the MD5-hash of an empty string is d41d8cd98f00b204e9800998ecf8427e. So, if someone with good enough a memory would see that hash and know that it(s the hash of an empty string. But if the string is salted (say, with the string "MY_PERSONAL_SALT"), the hash for the (empty string( (i.e. "MY_PERSONAL_SALT") becomes aeac2612626724592271634fb14d3ea6, hence non-obvious to backtrace. What I(m trying to say, that it(s better to use any salt, than not to. Therefore, it(s not too much of an importance to know which salt to use.There are actually websites that do just this - you can feed it a (md5) hash, and it spits out a known plaintext that generates that particular hash. If you would get access to a database that stores plain md5-hashes, it would be trivial for you to enter the hash for the admin to such a service, and log in. But, if the passwords were salted, such a service would become ineffective.Also, double-hashing is generally regarded as bad method, because it diminishes the result space. All popular hashes are fixed-length. Thus, you can have only a finite values of this fixed length, and the results become less varied. This could be regarded as another form of salting, but I wouldn(t recommend it.

posted date: 2008-12-30 14:21:00


Re: Secure hash and salt for PHP passwords#7
The target site shouldn't contain anything too sensitive(it's not a bank), but still I'd rather have it secured.

posted date: 2008-12-30 14:24:00


Re: Secure hash and salt for PHP passwords#8
In the end, double-hashing, mathematically, provides no benefit. In practice, however, it is useful for preventing rainbow table-based attacks. In other words, it is of no more benefit than hashing with a salt, which takes far less processor time in your application or on your server.

posted date: 2008-12-30 14:29:00


Re: Secure hash and salt for PHP passwords#9
multiple hashing also protects against dictionary and brute force attacks - i.e. it simply makes them take longer to compute.

posted date: 2008-12-30 15:00:00


Re: Secure hash and salt for PHP passwords#10
not for password hashing. the attacker only needs to break one hash to retrieve the password. the point is moot anyway as neither MD5 nor SHA1 have any practical breaks available in the password scenario.

posted date: 2008-12-30 15:05:00


Re: Secure hash and salt for PHP passwords#11
a secret doesn't help as your password DB is supposed to be secret anyway - if they can get hold of that DB, they can also find whatever secret you're using. it is however important that the salt is random.

posted date: 2008-12-30 15:07:00


Re: Secure hash and salt for PHP passwords#12
constant salt is not a great idea...probably not a fatal flaw but it unnecessarily weakens the scheme.

posted date: 2008-12-30 15:08:00


select page: « 1 2...»
Copyright ©2008-2017 www.momige.com, all rights reserved.