phpass the best solution for secure password-storing?

I'm creating a service which handles a lot of personal data, and therefor it's not appropriate to let the passwords simply fly out. I've been diggin' around to find any possible solutions, and one that caught my attention is phpass. I did read about it on StackOverflow over here.开发者_运维百科

I'm aware that there are a lot of questions about this subject, but I'd just like to clarify, that phpass is a secure way of storing passwords. The reason to my suspiciousness is that it doesn't use any salts (at least doesn't seem to use), which are, I've been told, the key to secure storing.

My current method is simply a sha512-hash with one user-specific salt, and another site-specific hash. Here's a clip of my PHP-code:

hash_hmac('sha512', $password.$account_specific, $site_specific);

It would be great to hear some expert-ish opinions on this matter. I apologize for creating another thread for the subject that's been and will always be asked about. Thanks in advance.

EDIT:

I've also heard that hashing a password, let's say, 1000 times is also a good way to store passwords. This way hashing only takes a few seconds (at max), but breaking the hashed password takes literally ages?

When dealing with topics of security on the web there is no "true" secure way to do things. Web security is inherently a cat and mouse game; the everyday users are the mice and the hackers are the cats. Web security is primarily reactive, meaning that a new security implementation is only thought of when a breach of security occurs. Because of this hackers are generally one step ahead of security implementation.

That being said, there are a number of things that you can do to make your site more secure:

1) Use salt values.

I know that you are already doing this, and it is good practice. It is wrong to say that using salts makes your application secure, as it doesn't. It makes it much more difficult to hack, yes, but if you're storing salt values in the DB and you end up getting your whole DB injected / dumped then the hacker has all the information they need to use a rainbow table. Using an application-specific salt is an additional measure of security but, again, if your application is hacked and the source code is obtained / decompiled then the hacker has all that they need.

2) Use SSL certificates

Making sure that data is encrypted when going to / coming from the server where your application resides is a good way to protect from packet-sniffing and session side-jacking.

3) Use SHA2 hashes

SHA2 hash values are widely implemented and are many times more secure than their predecessor, SHA1.

4) Have your DB and your application reside on separate servers.

If you have your DB on a separate server (or at least somewhere with a separate IP) then you can restrict access to the DB to a given calling IP address / port. In doing so you can make sure that the ONLY calls that can be made to your database are coming from your application.

5) Use stored procedures instead of dynamically creating queries.

If your application has code in it that structures SQL queries line by line then this information can be used by an attacker to map out the structure of your DB and subsequently effectively inject it. If you use stored procedures then this logic will be abstracted from the source code's perspective and attackers gain no insight into your DB structure by viewing them.

6) Check against all possible injecting points

Try to hack your own application. You know it best, so you should know its weakest points. While developers may make some of the worst QAers out there, figuring out whether or not you left an injectable hole open should be possible. Are there any places in which you're using user input to format queries? If so, mess around with the input and see what you can do.

From my experience if you do all of the above then you are very well protected. Nothing is 100% secure, but unless you are holding secret codes to the billion-dollar-free-cash-give-a-way then these obstacles will deter the vast majority of hackers (if not all of them). Having worked on a handful of large corporations' sites, it is ridiculous the lack of security some of these sites utilize (cough *cough* SONY cough *cough*).

Keep in mind, too, that a lot of users like to use the same password across separate platforms. If user A uses the same password for everything and registers for your site (a secure one) and then another site (one that isn't secure and doesn't hash passwords) then all it takes is the attacker to find the weakest link in a user's browsing habits and get the plain-text password from there.

Best regards,

It's important to note that salts are useless for preventing dictionary attacks or brute force attacks.

How to safely store a password

I use this:

function super_hash($string,$key,$times=2) {
    $hashed_string = SITE_KEY . $string . $key;
    for($i=1;$i<=$times;$i++) {
        $hashed_string = hash_hmac('sha512',$hashed_string,SITE_KEY . $key . 'hardcoded_key');
    }
    return $hashed_string;
}

For more security (slower processing), just add more iterations ($times parameter). Please note that extra iterations are only needed if both your database and your code are compromised.