Storing email addresses in plain sight

Question

What would be the best approach for storing a list of hardcoded email addresses in plain sight (in a public JS file or such)?

The site is pretty low-key, for a small community of friends. Starting out, I'd like to just hardcode some email addresses as hashes, which would then be checked against a users input to check that they are an invited member of the site.

Rather than creating an api with authentication etc, I'd prefer to keep it all in the front end. The 'account' would only be used for tracking user and guiding them to the right resources. Nothing financial, or sensitive.

I understand I could use an MD5 hash, though I hear this would be easily cracked?

Answer 1

It sounds like you have a public store for some data, and you want to use it to store a set of secret elements, with the following operations:

1. Add a new element to the set.
2. Query whether an existing element is in the set.

(I'll assume that this is where the story ends—if you're actually trying to do some kind of authentication, there may be substantially more to it. I'll also assume that you already have a mechanism for authenticating changes to the set, and your main concern is to prevent disclosure of the elements of the set.)

If the party that needs to perform these operations can additionally keep secrets, say a 256-bit secret key $k$, then instead of storing an element $e$, you could store a secret pseudorandom function of $e$, such as $\operatorname{HMAC-SHA256}_k(e)$. Computing $\operatorname{HMAC-SHA256}_k$ requires knowledge of $k$; nobody without $k$ can tell the difference between your set of hashes and a set of independent uniform random 256-bit strings.

However, compromise of $k$ would enable anyone to verify elements of the set, enabling dictionary searches and batch speedups like rainbow tables. If you're concerned with compromise of $k$ in addition to disclosure of the list of hashes, you could:

1. Use a password hash like Argon2id instead of HMAC-SHA256 to raise the cost of testing guesses.
2. Use a Bloom filter rather than a list of hashes. This raises the false positive rate for membership tests from totally negligible (at most $n/2^{256}$ when there are $n$ elements) to something you have to worry about based on the Bloom filter parameters, but it also gives an adversary less to work with by not even exposing individual hashes to attack—raising the probability of false successes for the adversary.

Answer 2

If you have or just want to have just the email address for authentication then you could store a password hash as value in the public JS file. You could for instance use PBKDF2 with salt and relatively high iteration value. Basically, if you do that, you treat the email address as a passphrase.

However, please keep in mind that an email address is really easy to guess, and therefore an adversary could just try email addresses and try to get to the same hash in an offline attack. It's unlikely that the iteration count / work factor will be a prohibitive measure. However, your friends could use a complex mail address if they would wish (e.g. Google allows to use [email protected] as alias for [email protected]) and be more secure.

MD5 - or any other cryptographically secure hash - is not secure for password hashing by itself.

---

Another issue is that adversary can change the code in the client and skip any verification that takes place in there. So your security should at least be partially implemented at a different place than the page anyway. Generally you'd try and secure your system starting at the server. For that however you do need code execution on the server. If the server can e.g. store the hash, and limit the amount of tries, then you're already much more secure.

If the system is for sending messages then you could also put some verification / security at the receiver of the messages if the server is unavailable to you.