0

I have to deal with a place that has some terrible security practices. For example, this place gives people passwords (eg. domain logon on Windows, but paired with their name as the username) that is also used for identification purposes (eg. as a PIN that works to identify them to give access to places, but it can also be directly used, if you have the right access, to pull up all sorts of details on the person, without any username).

These passwords are not secure, either. It is just a six-digit number.

In order to identify people (and give them authorization to a location), I only get this number (which, in itself, raises a number of problems like impersonation, but that is out of my hands) from a card that people in the organization have. Normally, if I were part of the organization directly, I'd have access to a database of information for which this number corresponds to, but I am not and I cannot get access to the information. I need this user information so I can have a separate log of which people (with names) have entered the room for security purposes, but I can request organization members to give their information separately to me so I can associate the number with the information and have my own database.

I cannot use a different number since it is the organization's requirements that organization members must use their card with that number to gain access to the room, although I could potentially have the users input a separate code if they desire that I could use in addition to the regular number.

How do I safely store this number, so that if my database is compromised, people cannot take it and use it as the users' password later on?

The way this system works is that I have a server with a database that would store this password (however it should be stored). There is a client that collects the number and sends it (or whatever should be sent) to the server to find the user in question. The server is (should) not accessible through any means other than the client, as the client is directly connected to the server over a VPN.

The client is the only client that collects the number, so, for example, if encryption is required, the client could store keys without the need to transfer them anywhere else. The client also has a TPM, which could also be used for storing keys, hashing, and any other required operations.

2
  • 1
    You talk mostly about how bad it is, but not what you are doing with this info. Your last paragraph needs details and context.
    – schroeder
    Sep 6 at 15:56
  • @schroeder Thank you for the suggestion. I have tried to add more details on the system and the situation, so hopefully my question is slightly more clear now. Sep 6 at 16:26
1

Just use Argon2id.

Disclosure of passwords is bad. In your situation is would be a little bit more bad than usual. This does not change the countermeasure. Your question is simple, it is just buried under a lot of irrelevant facts. Doing a proper threat model and risk assessment would help you clarify the situation.

Note: This answer only attempts to deal with your question about storing this critical piece of information. A full audit of this system should be performed by experts. Securing this data could be the least of this company's immediate concerns.

4
  • Wouldn't an HMAC be more worthwhile than encryption here (since that's what I was thinking of, plus hashing that again with some slow hashing algorithm like argon2) since if someone compromised both the key and the database, they still would not have the passwords without additional work, but I could still use the HMAC + argon2 as an identifier? Sep 6 at 16:17
  • @throwaway29018 If you need to use this data as an identifier and use its value, and not just verify its hash, then hashing them will prevent you to use them. If, however, you need to use them only as passwords, then just hash them using Argon2id following best practices. But then I fail to grasp the relevance of the first part of your question.
    – A. Hersean
    Sep 6 at 16:23
  • I don't need to use the data's value, but rather only use it as an identifier. For my use case, the data isn't a password, but if the data were compromised, it could be used as a password within the organization, which I am not a part of, which is why I don't want it to be possible for the data to be retrieved in its original form (eg. decrypt it), since an attacker could maliciously use it. Sep 6 at 16:30
  • @throwaway29018 I updated my answer.
    – A. Hersean
    Sep 7 at 8:11

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.