php - Reasonable Security for a shared user identification token?

Question

I've run into an odd crypto problem that I'm probably making more of than needs to be, on which I will blame my current low fever. I just really dislike rolling my own solution on anything crypto related without at least some review.

I'm in the process of implementing a SSO solution for integrating a third party service, wherein I authenticate users against our own authentication platform, which returns to me a limited number of consistently available variables when the user properly authenticates against it.

One of these that is guaranteed to always represent a given user is their login ID on our network. None of the others which are allowable in this context are guaranteed to remain the same for a given user.

I can't store the login ID in plaintext on the third party service as a shared token. (before you question why, there is a very simple reason: legal doesn't like it... while this identifier was created specifically to not be FERPA sensitive, it's essentially only once removed)

I can hash it. Since there is presumably a good reason for not storing it elsewhere in plaintext, I would like to hash it at least reasonably well. Normally, if there were some other, non sensitive identifier for a given user, I could bcrypt the sensitive information (like, if it were a password) and store that salt+hash and a PK non-sensitive identifier in a table, then look it back up based on the non-sensitive identifier when doing a comparison.

Without a non sensitive identifier to perform retrievals with, it would seem I would be stuck just doing a basic hash operation without a unique salt (I can still pepper them). Anything I store in my own DB would be just as vulnerable as what is being passed as a token, so there's no point in creating a map table of raw login IDs to salted and hashed login IDs. Blindly testing a given hash against every salt+hash I have stored would be ridiculous.

I could just go ahead and SHA2 with a pepper the login IDs and call it a day (these are, after all, "just" login IDs and not passwords--and that solution has been deemed at least adequate), but I'm wondering if there isn't a better solution for this case?

Answer 1

I guess you should know this: letter from US Department of Education to University of Wisconsin-River Falls:

We believe that FERPA allows an institution to designate and disclose as "directory information" a unique personal identifier, such as a student's user or account logon ID (or an email address used as a logon ID), as long as the identifier cannot be used, standing alone, by unauthorized individuals to gain access to non-directory information from education records. In other words, if a student must use a shared secret, such as a PIN or password, or some other authentication factor unique to the student, along with their personal identifier to gain access to their records in the student information system, then that identifier may be designated and disclosed as directory information under FERPA in accordance with the requirements of § 99.37 of the regulations. (Allowance is made for school officials to use the student's published personal identifier alone, just as they use a student's name, to obtain access to the student's education records, provided the school official has a legitimate educational interest in accordance with § 99.31(a)(1) of the regulations.)

Conversely, if an institution allows students to access own education records using a personal identifier but without the use of a password or other factor to authenticate the student's identity (or if the identifier itself is also used to authenticate the student's identity), then that identifier may not be disclosed as directory information under FERPA because it could result in the disclosure of protected information to someone other than the student and thus would be "harmful or an invasion of privacy if disclosed." (Some institutions may continue to use a student's "official ID number" in this manner.) Under this reasoning, an institution that allows a student (or any other party, for that matter) to obtain access to education records by providing just publicly available information, such as a student's name or published email address, without any additional proof or authentication of identity, could have a policy or practice in violation of FERPA because it could lead to the disclosure of education records to unauthorized recipients.

However, if this isn't acceptable, consider an additional ID (shared secret) that is temporary.

You could use random tokens (prefixed with a peppered time and user ID to avoid having to check for collisions) that are temporarily assigned to users (most likely via some kind of lookup table) and cleared out in reasonable time intervals.

If you still don't want anything that's tied to the user, even temporarily, you won't be able to use hashes, because hashes aren't reversible. You'd be stuck testing the hash against each record, which would not be technically feasible.

Finally, you could use a hash + random token and user ID, similar to SSO, but encrypt the user ID using a secret key stored on the server in code or configuration. This way, an attacker would have to gain access to both the database and your code or configuration to make use of the data. Ideally, change the secret key daily.

Answer 2

Currently implemented solution

The login ID is currently being run through a series of algorithms to create a unique salt that can be regenerated based on the given raw login ID at run time, allowing for a repeatable lookup process. With the salt and a pepper, the login ID is bcrypt hashed.

Known issues

low entropy (relying only on the login ID's inherent entropy), and an algorithmic process to create the salt severely limits the strength of this crypto process: with knowledge of the process to create the salt and the value of the pepper, it would be possible to create a rainbow table for these hashes. Still, any standard pre-genned rainbow table would not work: it would have to be custom done for this set of hashes, and would require enough programming knowledge/a flexible enough generator to duplicate the salt creation process. The use of bcrypt and the custom salt routine hopefully makes the process more time consuming than the retrieval of the associated values would be worth.

Unfortunately this is essentially security through obscurity, by degrees. But it's the best I can come up with at the moment.

Further considerations

Per Marcus Adams' answer, one possibility that might improve security would be to store the hashed login IDs in a lookup table, and then only pass a completely random/unique GUID style token to the third party software for SSO purposes. This would eliminate the chance of an intercept of a hashed login ID in transmittal (relatively low to begin with, as every step of this is SSL encoded via https, and the hashed login ID is folded into an SSO payload encrypted via rijndael and a PSK before being sent). While this eliminates the chance of a third party compromise leading to potential breach of the login IDs, it only shifts that potential to our systems, which we can't assume are necessarily any more secure. Given that the current solution would require a compromise of the source code to find the pepper and the salt algorithm, and given that any such compromise would also be capable of revealing any DB keys, there seems to be no real added security to using a lookup table in terms of any potential full compromises.

Deeper analysis into exactly how at risk what I have implemented is to attack is beyond my own cryptographic knowledge or what I have the time to devote to at the moment.