2

Is it okay to store single-use beta keys in plain-text in the database? I'll be pre-generating and storing about 2M keys. The keys get passed around so that people can sign up with it, rather than let random people sign up.

The only bad thing is that if someone could steal all the beta keys with a db dump, if that ever happens. Temporary protection could be hashing them using bcrypt, and then comparing the user's hashed input to the key hash (like a password), but then pre-generating 2M keys and hashing it all would be too slow.

1
  • 3
    Or implement a key-revocation procedure... Commented Feb 20, 2015 at 7:22

1 Answer 1

1

In your question you have identified a potential threat. If you think this threat is real and it would have a sufficiently negative impact on your operations if it were exploited, you should take additional measures as you suggest in your question.

If you are saying the keys in this case are unique identifiers which you do not want exposed, you may need to employ hashing and encryption as needed. If you need to store the keys and need to use the same DB to assign them, you cannot hash them since you would have no way to reverse them in order to hand them out. You would need to encrypt them.

Does the benefit of pre-generation outweigh the risk of having them compromised and the cost of creating keys on the fly? It may make more sense to create them on demand and look at solutions for email verification tokens and how they are managed since it seems you are doing something similar.

You must log in to answer this question.

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