0

I designed a WiFi host whose password contains a truncated SHA256 hash of a password + the time it was set.

For example, “password2019-12-25-12:59” hashed to “acd2775f” which is truncated to 8 digits (by the way, not the real hash).

The password changes every X minutes based on the time it was modified. So the hash changes (a lot, obviously).

The fact that it actually changes every 3 minutes, makes me feel pretty safe, because even if an attacker knew the algorithm (pass+date) they wouldn’t know the password which has no length limit.

So the attacker would have 2 options:

  1. He can try cracking directly the N digit passphrase in that small period of time.
  2. (assuming he knows the algorithm) He can make a list of all possible hashes for a certain time when he captured a random handshake and bruteforce it. In the end, he would get the secret password of my formula and authenticate.

The second method concerns me the most because the secret password usually doesn’t change. The attacker should guess N (the number of digits) to get to the WPA2 passphrase by hashing strings and trying.

Assuming that the impact of a breach to this system may cause very severe damages:

How critical is this vulnerability? Is it enough to make this system directly obsolete?

Apart from changing the ‘secret password’ frequently to increase the security, are there any other ideas I should know?

COMMENT: I understand that this system is a little confusing, so feel free to ask my any questions or whatever you want to contribute.

10
  • 2
    So a valid user needs to re-associate itself to the WiFi every 3 minutes? And since it is based on a common secret and schema between all devices - how do you keep this secret? And why invent your own method in the first place instead of using established methods like certificate based authentication (WPA2-Enterprise, EAP-TLS with client certificate) which has not the problems of a shared password in the first place? – Steffen Ullrich Dec 26 '19 at 6:27
  • 2
    Why reduce the hash to only 8 chars and not the max? – schroeder Dec 26 '19 at 8:43
  • What are you trying to protect? The wifi network or the wifi password? – schroeder Dec 26 '19 at 8:44
  • @SteffenUllrich 1. Yes, it is an extremely strange business model where people don’t need to use the wifi, but just authenticate correctly. 2. About sharing, here you are allowed to send it to any invitee you want because it will not last so much. 3. The system is completely offline, so if someone had a user/pass he could never be deleted. – J. Francis Dec 26 '19 at 15:34
  • 1
    I have a feeling that if you described the system, we might find a much better approach to accomplish the system goals. – schroeder Dec 26 '19 at 15:59
3

I think you need to realise that you have 3 secrets here, from your perspective:

  • the password
  • the algorithm, and
  • the hash length

You assume that the password can remain intact, the algorithm can be exposed as an acceptable risk, but you are afraid that the exposure of the last one might defeat your security and the other two secrets. This is a rookie security design error.

Your system needs to be designed so that it is still secure even if the attacker knows how the system runs. This is known as Kerckhoff's Principle. In your case, even if the attacker knows the algorithm and the hash length (which, by the way, is basically part of your algorithm, but you speak of them separately).

From a security design perspective, your security comes down to just the password. You just made it supremely difficult for the legitimate users to use the system without adding any additional security.

If your intent is simply to protect the password because it does not change often, then you need to shift your perspective and your risk analysis. Your proposed system obfuscates the password by using a salt+hash design pattern. The intent of the salt+hash approach is to increase the time it takes an attacker to crack the hash (even if they know the hash method and the salt, see Kerckhoff's). So, the primary goal here is time. Using this design pattern, the only secret is the password, and the result is a longer time to crack the password. You defeat this approach by shortening the resulting hash, because that dramatically reduces the time it takes to crack (like, from centuries to seconds).

So, to answer your question: it's the length itself that is your vulnerability, and attackers would not have to figure out your algorithm, they can just bruteforce 8 characters blind. They will be able to figure out how often it changes, and simply design a method to crack the hash in that time.

There are so many other approaches to this problem that you should investigate.

2
  • So first of all I should try to increase the length of the passphrase which is something possible on this system. I know I should also try to make something stronger than an alphanumeric string. You made a beautiful answer, thank you very much – J. Francis Dec 26 '19 at 15:39
  • 1
    But still , wouldn't they need a much longer time to crack the string if you don't reduce it to 8 but take like 40 or more characters? If so , there wouldn't be a need for a 3 minutes change. So if it takes longer to crack the string than the time you set to replace the string you would be save, right? – Dr3xler Dec 28 '19 at 10:29

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.