Jacques1

Hi, there is no direct equivalent to mysql_result(). You have to fetch the whole row and then extract the first value as shown by Ch0cu3r. A shorter solution would be list($num_items) = $items_query->fetch_row(); I strongly recommend that you actually learn how to use MySQLi and make use of its new features. Don't just run some tool to translate the old code. The new extension is very different in many aspects, and it's important to understand them.

I know. What I mean is that we should leave cryptography to the people who actually understand it. Designing a hash algorithm is definitely an expert topic. And the result needs to be reviewed and tested by many people over a long period of time. If the algorithm has survived that, then it's ready for use. Right. That's why it's a good idea to expect the worst and make as few assumptions as possible. Password hashes should be secure even if the entire server has been compromised. They shouldn't depend on some secret data which might be stolen (be it a key, the salt, the algorithm itself or whatever). So am I. By the way, kudos for being open to critique.

You mean the class you've just published on the Internet? Anyway, this is security through obscurity, a very common fallacy. People try it again and again, and it fails again and again. An algorithm that is only secure as long as it's kept secret isn't secure at all. A cost factor alone doesn't mean much. This is where it gets into the ugly details of cryptography, and I think none of us is qualified to talk about that. Again, security through obscurity. Very funny. AES is no magic spell to make systems secure. The server that manages the passwords needs access to the plaintext salts. That means you either have to store the AES keys right next to the encrypted salts, which would make the whole thing pretty silly. Or the authentication server needs to be able to fetch the plaintext salts from some external server, in which case the AES encryption is irrelevant for the attacker. Either way, the encryption doesn't really do anything. I mean, if you know how to build perfectly secure systems, why don't you simply protect the hashes? Nonsense. Sorry, but I have no idea why people keep perpetuating this myth. SHA-2, SHA-3 or whatever are in no way better for hashing passwords than MD5. They're all equally bad. The problem is that they were designed for digital signatures, not for password hashes. They're supposed to be very fast and efficient, which is the last thing you want when hashing a password. bcrypt, on the other hand, was specifically designed to be slow and expensive. Reality has proven that it's able to withstand brute-force attacks as long as the password is relatively strong. This is the de-facto standard for hashing passwords. And since PHP 5.5 got the new bcrypt API (see trq's post), there's really no excuse for not using it.

You're missing the whole point of password hashing, phpzer. You do a lot of hashing and encrypting and encoding and whatnot, but you don't seem to understand why you're doing it. This is just an arbitrary collection of pseudo-cryptographic voodoo. The biggest threat for password hashes is a brute-force attack. To withstand those attacks, a hash algorithm has to be computationally expensive. That's the only counter-measure: To slow down the attacker so that it's impractical for them to break anything but the weakest passwords. Your algorithm isn't expensive at all. An average gamer PC can calculate billions(!) of SHA-2 hashes per second. Sure, you repeat the hashing a few times. But that only means an attacker might need, say, 2 minutes instead of 1 to break an average password. Great. Actually, how can you be so sure that your nested hashes and string magic don't introduce cryptographic weaknesses? Don't tell me you've written a mathematical proof for each function call. Encrypting the salt is also nonsensical. First of all, that's not what it's meant for. The purpose of the salt is to act as additional input so that the same password doesn't lead to the same hash. Secondly, if an attacker has already managed to obtain the password hashes, it's pretty naïve to assume that the salt is still perfectly secure. I mean, it's readable by the very server that has just been compromised. Long story short, this is in no way better than plain old MD5. It's actually much worse, because MD5 was intensively researched, and we know its strengths and weaknesses. Your stuff hasn't been researched by anybody. The only person who thinks it's good is: you.