Hot answers tagged

48

Should you make the algorithm public? Trying to hide implementation details (such as which hashing algorithm you use) to preserve security is the very definition of security through obscurity. There is broad consensus that obscurity should not be your only line of defense. If you need to keep your hash algorithm a secret, you are doing it wrong and need ...


8

@Anders is correct that security through obscurity is no security at all. Having said that, publishing implementation details gives information to attackers that they could use if vulnerabilities are discovered in your implementation in the future or it the attacker has zero-day vulnerabilities. Think of it this way - many penetration tests begin with a ...


7

Because if a user can get their password out of the database, then so can: The system/database administrator. The school/employer/government who's proxying the user's Internet access. The hacker who pwned the WiFi at the coffee shop. The hacker who pwned the user's e-mail account. The hacker who pwned the server. In some of these cases, ease of access is ...


6

When your user logs in, you will have to know if the password is correct. Hashing a password means you don't need to know the password, just the hash. As hashing is one-way, if someone leaks your database, they will only have the hashes and will have to bruteforce every one to get the passwords. Using salts, bcrypt and a lot of rounds makes very, very ...


5

Is wrapping MD5 in PBKDF2 (or, for what it's worth, other secure hashing algorithms) something that safely can be done, or are there better approaches for dealing with old, insecure MD5 hashes? Yes, it is secure. You do not loose any security on this process. All this passwords would experience the same protection that the non MD5 passwords have, given ...


5

Upgrading to the latest supported stable PHP branch is the recommended route plain and simple. That being said, you've noted that you're with GoDaddy. Which of their services are you using for the project? If it's their shared hosting line, or any line that offers cPanel, upgrading PHP versions shouldn't add anything to current costs. Any web hosting ...


5

Hashing client side Secondly assuming that the connection is compromised because of an MiTM attack. The process of how the leaked hash of the password is created is still unknown because the salt and iterations (based on the pincode) are unknown. In case of a MitM attack (made possible by say incorrect use of TLS) hashing client side will not help you. ...


4

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately. Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried ...


4

Let's say we can try 10,000,000,000 SHA-256 hashes per second. For us to find the 256 byte hash, we have to search approximately half the search space, so we need to compute 2^255 hashes. This will take 2^255 / 10,000,000,000 seconds, or about 183587153154040137340770841274555916814545257270485419900205 years. Edit: I screwed up the calculation, because I ...


4

This would make the password LESS secure. Consider a 16-character password made up of a sequence of randomly chosen letters, numbers, and symbols. By itself, this password is basically "uncrackable" for all intents and purposes, even if your password database is leaked, assuming you hash the password. You could probably even use something stupid like MD5 ...


3

Passwords are not stored by web servers, only hashes. What happens when someone logs in is they type their password into the field. This password is sent to the server and hashed. The hash is then compared to the hash the server has stored to determine whether the password was correct or not. Since even the server doesn't know what the password actually is ...


3

Main advantages of hashing versus encryption: the administrator of the website doesn't know your password (see Iszi 's answer); if the database is breached, it is easier for the attacker to break a single encryption key than to obtain the passwords from N (10^4, 10^6,...) properly salted hashes (see ThoriumBR's answer); you don't actually need to get that ...


3

In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay. In most systems, I strive for a 10 to 20 ms delay. Assume your ...


2

Most hash functions take measures to make them hard to implement on GPU's, but it is indeed also possible to take advantage of parallel execution and use that on the defender's side when verifying passwords. One algorithm that was designed to be easily parallelizable is parallel by Steve Thomas. Parallel was a finalist in the PHC and thus has gotten some ...


2

Please take a look at the article - it's about naive implementation of Rainbow Tables for cracking MD5 hash function. It also has sources attached to the article. The main drawback - it's in Russian, but Yandex.Translate or Google Translate can easily cope with it.


2

Field Password and "X" contain a part of the hashed function most likely a split of the first Y characters in the password field, and the rest in the "X" Field. Combine and check if correct. Is there anything wrong with this approach? I surely feel that this would be a problem for any attacker. Yes, this severely weakens the hash security. Instead of ...


2

Not only can you, you absolutely should. Kerckhoff's principle dictates that the only valid thing for the security of your system to rest upon is the secret key, and that any secure system should be designed with the notion that "the enemy knows the system" assumed to be true up-front. Therefore, by Kerckhoff's principle, sharing the details of the system ...


2

Assuming a very good hash, use one of Sjoerd's answers. If the hash were very, very bad, however a collision could be calcuated in microseconds. i.e. 256 bit/byte hash alone means nothing unless it was designed properly. A naive hash could be something as simple as a CRC, which was never intended to be secure. Even hashes designed for security purposes ...


2

What are the risks of storing (in hashes I guess) all the old passwords? The risks are very low, since the old passwords will not allow access to the account. Why would a company chose to not delete old passwords? Companies store old password hashes so they can check to make sure that you do not reuse x number of old passwords. Why not let ...


2

As written, it is quite easy, because PHP will not expand variables inside single quotes. So '$time' is the five constant characters '$', 't', 'i', 'm', 'e', instead of a very long, increasing number. So this might have been a trick question, to lead someone to say "it's very difficult" when actually it is not. Supposing it was written md5("{$time}".rand(...


1

The purpose of salting is, that one cannot build a rainbow table to get several passwords at once. Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort. With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with ...


1

What are the risks of storing (in hashes I guess) all the old passwords? see here But just because you cannot use your old password doesn't mean that they necessarily store all the old passwords. They could just hash the password you provided and compare it to the stored hash. Why would a company chose to not delete old passwords? To prevent you ...


1

What you are describing is essentially an extra salt encrypted with a key derived from an extra password consisting of dictionary words that are not chosen by the user. I know this will appear as a rather vague and general criticism, but I see three downsides with this: You are rolling your own. Inventing your own systems to solve problems with ...


1

Yes, this is called the Pass the Hash attack. Microsoft has not issued any solution to mitigate (except for some vague general security advice), until Windows 10 where the hash is stored in a special vault. An example of exploit (via Metasploit) can be found at Offensive Security.


1

No, it is not secure. First of all, you're suggesting a MAC-then-encrypt, which is known to be vulnerable to "chosen ciphertext" attacks (i.e. an attacker can take a valid message, modify it, and observe the result to gain information about the plaintext). Secondly, you're suggesting the use of a hash rather than a MAC or even better a digital signature. A ...


1

Your update helps, but the pieces still don't quite fit. You know that the key the software gave you to keep safe is an RSA public/private pair, and you know a session key is involved. The usual practice is to choose a fast symmetric algorithm to do the actual encryption of the data, randomly generate a key suitable for that algorithm called the session key, ...



Only top voted, non community-wiki answers of a minimum length are eligible