-2

I know that if hash values are same , then the security of the system is reduced. For example: If two timestamps create same hash values, they lessen security. Why is that? What are reasons?

The scenario is: There is a secure web authentication system. There is a login page. In the login page, there are some fields (username, password) for login, and two buttons "Upload your key file" and "Register". At first, a user has to register using a username, password and his email address. If the registration is successful, he will be sent a confirmation email with a key-file (.key) attached. He has to download the .key file.

Now he will go to the login page, then he will type his username, password and he will upload his key-file (.key) which he was sent via email. If everything matches properly, then he will be logged in.

In the backend, during login process, the system will compare the password typed by the user to the one in the database. If it matches, then the typed-in username will be encrypted by an internal php algorithm using the timehash (the time when the user's password was created) from the database. The result will be compared to the key-file uploaded by the user. It they match, then the user will be granted entry.

In the implementation, there are some SAME timehash values. I want to know- how and why do SAME timehash values lessen security?

  • The security weakness here has nothing to do with hashes being the same. The whole keyfile process is poorly designed and serves no ultimate purpose. It is trivial to recreate the keyfile for any user, the way you described the process. – schroeder Feb 1 '18 at 20:31
  • There is no difference between using a hash of the timestamp, or just using the timestamp raw. – schroeder Feb 1 '18 at 20:32
4

Say you are storing hashes from users passwords in a database to authenticate them on your site, and you do not salt them. An attacker somehow gains access to the database. Since you do not salt the hash, users with same passwords have same hashe, thus the attacker has to crack only one hash to learn the passwords of these users, instead of cracking one hash per user.

Another important thing to point out. If two timestamps have the same hash, it might lessen security depending what exactly the hash is used for, but also it indicates that the hashing algorithm is weak, since there is a collision on a very small set of inputs.

  • Nice answer, might want to stress the "collision" aspect that you mention. I believe that is really what the OP is asking...I think. Two different inputs resulting in the same output – pm1391 Jan 31 '18 at 14:36
  • I updated the question body... Please read. – Martin Feb 1 '18 at 20:28
2

(see below edit to address the edited answer)

Although it's still a bit unclear what you're asking, I think it can be said with reasonable certitude that as-asked your assumption is wrong.

Two timestamps -- or any pair of inputs -- producing the same hash does per se not lessen security in any way. Indeed, mapping identical inputs and possibly even different inputs to identical outputs is the very nature of a hash function (cryptographic or not), and perfectly normal. Hashing produces M bits of output from N bits of input where usually (but not necessarily) N is larger than M. If N is larger than M, then of course some different inputs must produce the same output, there is no other way it could be (pidgeonhole principle). If N is equal to or smaller than N, chances are good that if the outputs are the same, then inputs were the same as well (a hash could in principle still have collisions, but with a reasonably good one that's unlikely). It is usually not easy, or even feasible, to tell the input from the output (cryptographic hashes are explicitly designed to make this hard), but verifying if some provided input matches or not can be done. That's what storing hashes of passwords is about, in its most naive form.

All alone by itself, the fact that sometimes you have the same hash value is not a problem in any way. But in some situations, it may become one.

You made mention of "username", "password", and "file". So let's assume you meant to say you have usernames and hashes of passwords stored in a file. Is it a problem if two hashes are the same?

Well yes, in this case it certainly is, unless it happens by pure coincidence. An attacker breaking into the server and stealing the file can now immediately tell users that have the same (unknown) password apart from others which have different, individual passwords.
If nothing else, this means that the attacker has immediately, at the first glance, identified those users where the cost/benefit ratio of attacking is best. Why? Well because by breaking one password you do not only get access to one acount, but to many. Also, it is highly likely (almost guaranteed) that those particular users are using a very common well-known password which they probably use on many sites, too.

Further, if you are doing this regularly for a living, you can make your life a lot easier, since the hash is deterministic, i.e. it always produces the same output for the same input. That's nice, isn't it?

This means that not only can you run a dictionary attack very cheaply (precompute variations of the 1,000 most common passwords once, reuse forever), but you can also cache results instead of spending work on crunching numbers for every user anew. Instead of one user careless enought to use a password from the top-1000-most-stupid-passwords list or a variation thereof, you can attack many at once, at the same cost. Also, you can remember and reuse every single match that you ever find anywhere (even on a different system), which is less work, and has a much better chance of success than brute-forcing randomly. What's worst, you do not even have to do the work yourself since others have already done it...

That is why identical inputs should produce different outputs for different users on the same system, and for the same user on different systems. Because otherwise, compromising one will compromise many. Rainbow table and salt are two keywords you may want to familiarize yourself with (Wikipedia or such) in that context.

There's other (not immediately related) considerations such as the ability to test hundreds of millions of hashes per second on rather modest hardware which make salting as the only precaution somewhat obsolete nowadays, too.
While salting still effectively protects the entire population of users as such, it does not sufficiently protect the targetted individuum. In this context, PBKDF2 and bcrypt are some keywords you may be interested in.

Edit
Your method does not just have somewhat lessened security, but it is outright catastropic. That's not because of the hash, however, but first and foreall because you store plaintext passwords, and compare plaintext passwords. Little does the validation with the key (which is not a key at all) help to remedy this.

A hash from a timestamp and the username is mostly public knowledge, it can easily be calculated by anyone if the time of registration is known, and unless it's a at least microsecond precision time, even without knowing the time of registration (could just brute force it). Add to this the fact that you just emailed it around the world. This really adds zero to security.

The purpose of such a "keyfile" or registration code (usually in the form of an URL, not an attachment) is to make sure the provided e-mail address is valid and accessible. Nothing more, really.
As such, it does not need to be super secret or super special. In principle, any kinda random, not immediately guessable 6-8 digit number will do just fine for that purpose. Make it a 16-digit random number if it makes you feel better.
That does, however, not account in any way for the terrible idea of comparing passwords, which of course implies storing plaintext passwords. Note that PHP has an explicit function for that purpose which does the right thing without you even needing to know how to do it. Or, if bcrypt isn't good enough, and you carefully read up on the matter so know what you're doing this one which is much more complicated but can arguably offer better (and worse!) security.

  • I updated the question body. Please read.... – Martin Feb 1 '18 at 20:27
0

I think the timehash(username) and keyfile are distracting you from the actual security. Let me explain what I mean by that. Encryption Security is the idea that even if an attacker can see everything (including your app's source code), they still can't easily get at the data.

Do you see why timehash(username) doesn't really help that out? Time of creation and Username are both stored on the SQL DB. You have to plan on the attacker having that information and knowing how you're using it (aka, security by obfuscation's a bad idea.) Trying to use it as a secondary form of validation doesn't really help out, because the attacker can just use timehash(Table.Username, Table.AccountCreateTime) to generate a keyfile for a particular user.

There's one thing that will allow you to get real security: the user password. And reading between the lines, it looks like you're storing it in plain text.

No. No, no, no, no, no.

If you want to actually make this secure? Then do the following:

  1. On user creation, salt and hash the user's password
  2. Store the hash'd password in the SQL table
  3. When the user tries to login, they submit Username, Password
  4. Salt/Hash their password attempt, and compare the result to the SQL entry
  5. If the hashed values match, the login is valid

... you can add the keyfile with timehash(username) if you want. It's basically a bit of SecurityTheater+SecurityByObscurity, but as long as you get the important part down pat, you should be good to go.

Anyway, as to your specific question: having a few identical hashes isn't the end of the world. All it means is that if someone cracks a password, they'll simultaneously crack any identical passwords with the same hash. So if two passwords share the same hash, it doesn't matter unless they have the same password as well. Personally, I'd rather generate a CSPRNG salt and store it in the table so I don't have to worry about the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.