0

I am using a syymetric token, a fernet from the python cryptography module. I am trying to make it such that a terminal logs into a website automatically.

I store the serial number and mac address of the terminal. The terminal authenticates itself by sending the serial number as a user name, and the encrypted messasge as the password. The key to encrypt the mesage is made up of the serial number and the mac address of the terminal (but not limited to), and the message it send is also the serial number and mac address.

The server then receives the password, checks in its own DB the mac address of the serial number, then knows how to recreate the key, then unencrypts the messasge and checks if the message contains the serial number and mac address correctly.

Is it better to:

  1. Leave it as is
  2. Make the encryption message always the same for all terminals (ie. a constant), as mac address and serial number change the encryption key anyways.
  3. Leave the encryption key the same for all terminals (i.e. a constant), since the message contains the serial number and mac address
  4. Something else?

It just seems a bit "daft" what Im doing but not sure what is better.

2 Answers 2

2

As long as you're using a standard modern cipher, it shouldn't matter at all how related (or unrelated) the key and message are. As a practical matter, you should perhaps be hashing the inputs to the key, both to produce a fixed-length key regardless of the number and length of inputs, and (if you use a slow hash, rather than a fast one) to make attempting to brute-force the key much more computationally expensive. That would make the key and the message superficially quite different (though this isn't why you would do it, exactly). In theory you don't need the same data as duplicated inputs to generating the "password", but it doesn't hurt.

The actual security of this scheme, in terms of ability to prevent something that is not one of your terminals from logging in, or prevent terminal A's user/owner from logging in as terminal B, is questionable. You haven't provided enough info about that to be sure, but what you have provided is concerning (there's very little entropy in MAC addresses or in serial numbers). But that's not what you asked about.

3
  • Thanks for that great insite. That is a good point about the entropy. The reason is that I wanted to be able to create the key from knowing just the SN and MAC address. At the moment I have an algorithm to create a 32 key by padding with a secret string, but in light of what you said, I think hashing them is much better, even if SN is off by 1, it will be totally different. Jul 14, 2021 at 10:23
  • Actually, is it worth encrypting? I could just send a hash of the SN + MAC address Jul 14, 2021 at 10:36
  • 1
    You'd probably want a keyed hash (an HMAC or similar, using a key common to all the devices and embedded within the device), since the serial and MAC are both presumably public info and you don't want it trivial to generate the auth token from them. That's still only going to require a bit of reverse engineering, but it would at least be secure against somebody who knows the process of generating the "password" but doesn't have access to a device to extract the key from.
    – CBHacking
    Jul 14, 2021 at 11:22
0

Hope you queries solution is very similar to below scenario..!

I don't see any issue, in the world of threat feed are getting allowed with API key.

1
  • Sorry I am struggling to understand your answer, but I am guessing you think its ok, thanks! Jul 14, 2021 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .