-3

I would like to build a simple system, are there any obvious security flaws in it? Will this hashing mechanism be fairly secure without any other layers of encryption?

I have a simple module where people can enter in codes, and a server that keeps a list of allowable codes (which are used only once, and new ones are added, but not reused). Assume the wifi connection between the module and server is insecure.

Here are the steps the code gets verified:

  • the module sends a sha1 hash of the code to the server
  • (if valid) the server responds with a sha1 hash of the code + a hard-coded salt (known to the module, but unknown to hackers)
  • the module can verify that and accept or deny the user

(The reason only hashes are used is so it would be impossible for a hacker to transmit an Allow/Deny message straight to the module. A salt is used, is so that middle-men cannot enter a random code then then transmit their own sha1 hash of it)

I am avoiding the complexity of SSL because the module will be run on an extremely simple embedded system with no OS.

Updated example that makes more sense: Allow UPS couriers to scan the tracking number of packages to unlock a door so they can drop off the package. Only known tracking numbers are allowed so that robbers cannot simply scan an irrelevant package to break in.

Notes:

  • I guess "password" isn't the right word, it's just one-time use codes. Yes, the salt is hard-coded and I'm hoping to avoid encryption. The reason sending back the code is involved is so that regardless of what a hacker might transmit to the module, it will be impossible to authenticate unless he knows the salt.
  • As for where the authentication happens: the server will know if the code is valid or not, but the module will only accept the hash of salt + code so that the module knows the answer came from the server not hackers, and also so hackers cannot figure out the salt.
Pierre.Vriens
  • 165
  • 1
  • 1
  • 11
Artur
  • 105
  • 3
  • 3
    So, you hardcode the "salt" in both the server and the module? All this is being transmitted unencrypted? Why is the server sending the password back? How is the server maintaining the password list? There appear to be multiple security flaws here. Have you looked up authentication mechanisms you can emulate instead of creating your own? – schroeder Jan 07 '16 at 00:29
  • Is the userID or tagID sent along with the password? What happens when the password is wrong? Who is doing the authentication, the server or the module? How are passwords updated or revoked? – schroeder Jan 07 '16 at 00:31

3 Answers3

1

If an attacker is able to perform a man in the middle attack (and he can perform it, if the wifi connection is insecure), then it's not secure:
If I take your example: When the UPS courier scans the package, the attacker can drop the message with hash but keep the hash for later. The module will deny the UPS courier the access and he will probably simply go away. Now attacker can go to the house and send the message with the hash to unlock the door.

But this is only one obvious vulnerability of your system, that should show you why should not roll your own crypto.
(I recommend you to read this answer: https://security.stackexchange.com/a/18198/91783 )

If TLS/SSL is not possible for your system, I think you should use a well-tested implementation of an existing authentication protocol. The code is like a password the token that authenticates the user on the server.

Take a look at Wikpedia for a list of protocols: https://en.wikipedia.org/wiki/Authentication_protocol

Community
  • 1
sven.to
  • 596
  • 3
  • 5
0

I do not notice anywhere in your description that you are encrypting your traffic. Are you sending your hash in the clear? If so, I am thinking, what would prevent an eavesdropper from intercepting the hash and reuse it?

Another question is, how do you attempt to keep your list of allowable passwords which "keep changing"?

xyz
  • 387
  • 2
  • 8
  • OP states no encryption. – Neil Smithline Jan 07 '16 at 03:10
  • Good point about reuse, they will be sent in the clear, but the codes will be used only once. Adding new codes is something that the admin can take care of, on the server side. – Artur Jan 07 '16 at 03:30
  • How do you plan to only use the code once? Do you intend to change the password once the module logs in to the server? Furthermore, have you consider Man In The Middle intercepting your hash even on the first attempt? I feel you should just find a tiny/embedded SSL/TLS implementation instead. It is usually a bad idea to invent yourself. – xyz Jan 07 '16 at 03:48
  • @wei Yea, after feedback here, I'm leaning towards doing SSL. But still curious if using this particular system on its own is theoretically secure. Instead of "password" better way of describing it is a "tracking number" I updated the example in question to one that makes more sense. First time man in the middle should be an issue if its single use codes, as far as I can see. – Artur Jan 07 '16 at 05:10
  • 1
    @Artur. I believe your system is insecure even just logically. Whether it is a tracking number or password, it still represents the client's identity right? If it is not encrypted, it can be eavesdropped, hence impersonated. the server wouldn't know how to different your module from the impersonator. Any the server make the token single use only, how does the module/client knows what to send the next time? Is the next token predictable from the initial token? – xyz Jan 07 '16 at 05:35
-1

First vulnerability is around using SHA1 hashes. SHA1 hash based collisions are relatively highly probable with modern compute power. See SHA1-collisions

What this means is the rogue party can capture those hashes on the wire and brute force them. Even worse, if the attacker gets into your server and obtains the limited set allowed, it narrows down the problem significantly.

sandyp
  • 1,126
  • 1
  • 9
  • 17
  • 1
    "Highly probable"? Your reference states: A collision attack is therefore well within the range of what an organized crime syndicate can practically budget by 2018, and a university research project by 2021. An organized crime syndicate doesn't seem to be part of the threat model. – Neil Smithline Jan 07 '16 at 03:13
  • @NeilSmithline It is an article older than the three year old ringworm on my neck. Apply Moore's law and the ballpark should be something tangible. Right? The discredit is no fair. – sandyp Jan 07 '16 at 15:56
  • 1
    It is not meant to be discredit your answer. I simply feel that you state your opinion about the ease of finding collisions in SHA1 but represent it as having come from that article. It doesn't. While old, the article does try to predict the future and, even using those dubious predictions, you overstate what the article says. – Neil Smithline Jan 07 '16 at 16:51
  • 1
    If you want to duplicate an *existing* e.g. "captured" hash you need preimage not collision, and noone reputable thinks SHA1 preimage is remotely possible. But for the proposed scheme it doesn't look like preimage would help anyway. – dave_thompson_085 Jan 22 '16 at 23:25