Tag Info

New answers tagged

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


0

No it doesn't. The password is probably sent to the page where it's displayed to you and at the same time it's stored. We cant say if it's stored hashed or not but displaying the password to you does not mean it's not hashed. Like the other answers, I do agree that it's a terrible idea to show the password on the next page in plain text. It's bad anyhow to ...


2

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


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


22

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


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


0

I'd like to to rephrase your question as this: "Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?" I would see two approaches to that problem. The first one starts with the data, the second one, with the final view. Data-centric In order to implement this, you need to ...


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


0

It would need to be researched as to whether or not such an action would produce a collision in practice, but you can consider that a recursive MD5 hash is still only 1 MD5 hash at the end. You are only running the hash on 32 bits of data (the output of your n - 1) instead of on n bits of data. So, considering that the hash algorithm is pseudo-random, you ...


0

A straightforward approach would be to log the IP address and a timestamp in a logfile, and delete entries after a period of time. Straightforward but phenomenally innefficient. Really you should only be maintaining data for violators in indexed storage independent of your log data (you should probably also be keeping log files but that is seperate ...


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


0

An offline/local encryption/hashing server. Imagine this an user register himself >on the website but instead of the current site hashing and storing the password. This exposes the password to a unknown server, with unknown security for the password itself. Its better to NEVER send an password over the wire at all. you could use a java script hashing ...


0

Stop adding useless complexity This would just add one step to build password... In case of brute force, attacker could use same tool you've chosen for doing this step automatically. In fact, this won't add a lot of work for attacker, but by adding step for users, they could even contribute to reveal password by user's mistake. Use passphrases instead of ...


0

Yes, you must hash user passwords, because you have access to the database. You should never have access to user passwords. Because you have access, anyone who obtains your level of privilege also has access. So does someone who manages to get direct database access by compromising the server. So does anyone who can view your backups. A user's password ...


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


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


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


-1

Why not just use a CRC-token? or alike. without knowing what it is you are securing against with the hash no-one can tell you what to do (and the least amount of data added for verification the better for speed). truncating a hash does not help in general. because all you do is expose more of it to collision attacks.


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


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


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


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


0

It's implied in the same article that Kaspersky has access to the code which uses the hashes. They know the algorithm because they have the code which generates it. What they want to know is what the code is targeting which is hidden by the hash.


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


-1

By doing number of times the hashing gives you more randomness and entropy. The primary reason is protection against brute force attacks. You're adding a work factor to slow down trials of possible keys. Take a 4 digit passcode - there are 10,000 possible passwords, and you can get all of them by incrementing 0 through 9999 by 1. If you use a key derivation ...



Top 50 recent answers are included