共享用户标识令牌的合理安全性？

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.