Tag Info

Hot answers tagged

25

You don't mention what you're using the hashes for, but it appears likely that your intent is to use if for password verification. So, the first issue to clear up is the concern that a given algorithm might be found to be susceptible to collisions. Collisions are not a threat to password hashes, and even if an algorithm were susceptible to collisions, that ...


18

No, you cannot conclude that. The password can be hashed on the server-side only, which implies that the password is sent in plain text to the server and stored in a variable. Then, nothing stops the Web application from displaying the sent password to the user, in the case where the very same script that has received the password is giving you the feedback ...


11

From the standpoint of collision-resistance (finding two colliding messages) and second-preimage-resistance (finding a different message colliding with a given one), the concatenation of multiple hashes is at least as secure as the strongest of the hashes (Proof: for any of the two properties, any attack that breaks the concatenation can be turned into an ...


11

Referring to the first few paragraphs in this article: https://crackstation.net/hashing-security.htm If you are thinking of writing your own password hashing code, please don't! I understand that you don't consider writing your own hashing code, but rather use multiple of standardised ones to seamingly increase security. This will, however, give you no or ...


6

You can't conclude the password was stored in plain text if it is redisplayed soon after you changed it. On the other hand if it is displayed after a while (days for instance) it may be a good hint that the password is indeed not hashed (it is stored in plain text or encrypted). Anyhow, redisplaying a password is clearly not a best practice because it may ...


5

Yes, you should. Nobody hashes (passwords are hashed, not encrypted) passwords because they KNOW that they have an SQL injection vulnerability. It's a second layer of defense. And it's needed because you just can't be sure that you don't have an SQL injection. Or that a library you use doesn't have any. Or that there are no other vulnerabilities, such as ...


4

YES!! You absolutely MUST both hash and salt the passwords. How do you know that "no hacker will reach the database"? There are probably hundreds of ways a database could be compromised; SQL injection is just one of them. And even if both your server and web application have zero security vulnerabilities (unlikely), you still have to deal with possibilities ...


3

According to Wikipedia (summary bar on the RHS), "No actual collisions have yet been produced" for SHA-1. The best we've done is find algorithms that "should" find collisions eventually. Since the point of a hash function is that any change (even a single bit) should change the whole result in a basically pseudorandom way, you're essentially looking at the ...


3

Answer depends on your security model. Classically, a cryptographic hash function has three properties: It resists preimages: given y, it is infeasible to find x such that h(x) = y. It resists second preimages: given x, it is infeasible to find x' such that x ≠ x' and h(x) = h(x'). It resists collisions: it is infeasible to find x and x' such that x ≠ x' ...


2

Carl can ask Alice and Bob (independently) to calculate hashes of specific fileparts and compare the results. For example C asks A to calc h(f[0-100]) and receives h' then C asks B to do the same and B returns h''. If h' == h'' they both have the same knowledge about this part of f. You can repeat this for different sections of the file. Notice: If A and B ...


2

This is something I've spent some time trying to figure out too. The answer is a lot harder then it appears, but quite consistently seems to be "We have no clue". This might seem strange but it's actually quite reasonable when you consider what you are looking for. Essentially you're asking someone to find a collision in a hash function. That is supposed to ...


2

TL;DR Yes, if done properly, the system you've designed should provide a small security gain, but it probably isn't the best option. The expanded version: When we design security into a system, we first develop a threat model, and then we figure out how our system is going to mitigate those specific threats. So, the question for you is: "What is the ...


1

As others have mentioned this doesn't necessarily mean the password is stored in plain text but is a bad sign and bad practice. Some ways to determine if your password is stored in plain text are: Using the password recovery to see if it's emailed to you (this indicates plain text or 2 way encryption at the most). Check the password requirements, if ...


1

I'll suggest an answer to my own question. Perhaps I'm essentially helping to define a term that has been introduced elsewhere. If we take the definition of 'hardening' in security as: hardening is any one of a variety of measures taken to make it more difficult for an intruder to circumvent the authentication process Then 'key hardening' is any ...


1

We have to distinguish between following two scenarios: 1) A determined hacker tries to get the passwords In this situation SSL usually provides enough protection, well implemented SSL is very hard to break. As soon as the attacker could successfully start a ManInTheMiddle attack, the client side hash would not get more protection anyway, because the ...



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