New answers tagged

0

The salt has to be stored someplace that's easily accessible given a user ID. That means a database table. The hacker who can get the hashed passwords can get the salts in the same way, often using SQL injection. As others have already written, the salt stops precomputation attacks. There is an approach called a keyed hash in which the hash is generated ...


0

Others have clarified the purpose of Salt, which is to require a separate brute-force process per-user to crack, which would take much longer than a single brute-force process finding matches for every user at once. Salt is not needed to be secret, just unique. A good way to improve on this is to include Pepper, which is secret. Pepper is just some random ...


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 ...


0

You answered your question, just did not saw it. why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe The answer is: if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I ...


0

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters. A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to ...


0

The only other solution than asking for a new password is to save the new hash on next login, setting a flag to know it's upgraded (if needed). This approach is as secure as your current login, and based on your question, will improve it. Changing the current hash is pointless as it will not add entropy.


-2

Everything is very simple. The name was coined for the song, already after the computed hash. They probably could not think of a name for a song and someone accidentally measured hash and noticed there is an unusual sequence, due to this, the name was invented! =)


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. ...


0

The local hashing will not help against passive MitM if the authentication process is simply sending the hash to the server. The attacker can capture the hash during registration/password change and just send a request with the hash instead of using your web application which computes the hash based on password and pin code. Server side hashing keeps ...


2

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 ...


0

SHA256crypt and SHA512crypt was described by Ulrich Drepper here. He provides an algorithm and implementation, but unfortunately not a security analysis, any proof that this algorithm is secure, or any insight in his design decisions. This makes it hard to analyze the security of the algorithm. The algorithm is pretty much like PBKDF2, in that it performs ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


-4

The easiest way would be checking the file size. If it is just a function call is changed like for a dialog like "Enter valid DVD", then it's file size should be almost the same. Fuzzy hashing should work though I don't know much about it.


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 ...


0

Found this to the point answer from another forum. These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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.


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.


0

There are many password "managers" that works in that way. For example Masterpassword app is really close to your idea. The algorithm is open source so I disagree with @RonWayn. As long as you cannot reverse the algorithm and find the master password with a given used password this should be secure enough.


0

It's only as secure as the master password. Everything else relies on the the assumption, that the algorithm is not disclosed to an attacker aka security through obscurity. Oh, and you just disclosed your algorithm to the internet.


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 ...


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 ...


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 ...


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 ...


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, ...


-1

Besides the normal Philip Dick kind of paranoia which tells you nothing is as it seems -- ever -- there is nothing that can be inferred from simply seeing that Chrome has alerted you to a site's using SHA-1 for their certificate's signature. Google said they were going to do this back in 2014. You could be on Amazon.com, using Chrome. The fact is, if ...


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 ...


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 ...


1

Others have noted the problems getting the card info to the site, but you must also think about how they handle that information internally. I once worked at a dotcom that stored credit card info in our database in plain text. Anyone with access to client info could see them. Lazy certification is only the tip of the iceberg, IMO.


25

As others have said, technically the risk is small for a MiM attack. However this has a larger problem and implication. Should I go ahead and enter my card details and pay for something on this site? NO, YOU SHOULD NOT USE THIS SITE FOR A CARD TRANSACTION The SSL issue is, as stated by others, relatively minor, however, using a SHA-1 hash means two ...


16

It means that the certificate used by the site is using an outdated signature algorithm to confirm the certificate identity. Google has been aggressively targeting SHA-1 signatures for site certificates for a couple of years, since there are some theoretical attacks which could result in a fraudulent certificate having a valid signature, although there has ...


72

It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on. The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm. What does that mean? It means the connection is encrypted and a passive eavesdropper can still not listen in. But a ...



Top 50 recent answers are included