Jeremy Smith's blog

Entry Is Labelled

Use of EmployeeID/StudentID Considered Harmful

(With apologies to Eric Meyer.)

At Case (as with most Universities), many of our information systems are migrating away from using SSNs (internally or otherwise) to uniquely identify individuals. This is a good thing, most certainly.

On the ITS page located at http://securityaware.case.edu, it recommends (down in the "5 Key Steps" area as step #5):

Plan for transitioning to using the EmployeeID/StudentID (emplid) as the primary identifier.

I would actually recommend against that. Not everyone associated with the University has an EmployeeID/StudentID (only employees – i.e. faculty and staff – and students have them). That doesn't include:

Instead of using the EmployeeID/StudentID as the unique permanent identifier, I would recommend using email addresses i.e. jms18@case.edu. Everyone associated with the University has an email address that can be used to uniquely and permanently identify them. (I would not recommend using the first.last@case.edu format as the unique identifier because when name changes occur (marriage, maybe other reasons, too), those email addresses do change while the userid@case.edu format does not.)

Email addresses (a.k.a. usernames) are much better for uniquely and permanently identifying individuals than EmployeeID/StudentID.

In addition, using email addresses gives another benefit. If you need to key some information on me, for example, and you ask me what my EmployeeID is… well… I have no idea what it is. It's just another number that I guess I was supposed to memorize, but I have enough numbers (Bank PINs, SSN, Account #'s, phone numbers, etc.) to memorize. Ask me for my email address, yea, I can tell you that. So, in addition to being unique and permanent and universal (which EmployeeID/StudentID is not), it's easier for people to communicate and remember.

A couple of people I've told this to have retorted that email addresses were not appropriate because they are publicly known. That is, they were wanting to use EmployeeID/StudentID in a "shared secret" or secure fashion. That's not appropriate as the EmployeeID/StudentID is not a random number (it's an auto-increment deal in a database table). As such, it is guessable. In situations where you need to securely identify a person, I would recommend using the tried-and-true method of having them enter their credentials. If it's a face-to-face meeting, use the Case Card. If it is an over-the-phone, IM, or email centered process, I would recommend changing the process to a web-based one where persons' credentials can be used.

Comments

  1. gravatar

    The library has been using LDAP numbers for a long time now. See http://library.case.edu/loc/caseacct/

    According to our page, "If you are a special borrower, or a patron of the Cleveland Institute of Art, Cleveland Institute of Music, or Siegal College you will still continue to use your SSN. We are working with these institutions to migrate over to Case Account Number."

  2. gravatar
    The library has been using LDAP numbers for a long time now.

    By "LDAP numbers" do you mean cwruEduIDPerson?

  3. gravatar

    I agree with you in general, and I've always advocated that as the ID of choice. About five years ago, we started putting this on forms instead of the SSN. Not only is it easier to remember, it actually has some meaning to you if you look at a list of them.

    Are you sure that list is correct, though? Last time I checked, most adjunct faculty want to get paid, which means they would have an employee ID.

    Most contractors that I work with do NOT have Case email addresses (there are a lot more contractors floating around here than most people know). I don't yet know how we will deal with their card access in lieu of an SSN.

    Do CIA students have our email? I know CIM does, but I didn't think we did CIA.

    I think the library uses uidNumber.
    Joel

  4. gravatar
    Are you sure that list is correct, though? Last time I checked, most adjunct faculty want to get paid, which means they would have an employee ID.

    I know we handle some Adjunct Faculty who aren't in Peoplesoft. I don't know the entire extent of them who are or aren't in it. There's enough of them not in it to warrant being on the list.

    Do CIA students have our email?

    Yep.

  5. gravatar

    No, it's not the uidNumber--they're using the "cwruEduIdNumber" (probably what Jeremy meant, but dang if there aren't a lot of confusingly similar field names in our LDAP schema).

    I don't see how we can possibly eliminate SSNs by using EplId/StudentId; there are way too many users not covered by the HCM & Student systems (and personally, I suspect it would be much easier to give those who lack one a Case e-mail account, or use an external email account as a universal key field).

    I also agree strongly with Jeremy that "xxxId" numbers as shared secret authentication tokens are a Very Bad Thing(tm). That's what the Kerberos/AD/LDAP passwords are for.

    We've made a lot of progress over the last few years in getting disparate services/applications to authenticate against the unified password system, but there is still more to go. The last thing we need to do is screw it up by picking key fields via the 'dart board' method, and compounding the error by using non-secret information as shared secrets.

  6. gravatar
    The last thing we need to do is screw it up by picking key fields via the 'dart board' method, and compounding the error by using non-secret information as shared secrets.

    Exactly.

  7. gravatar
    I know we handle some Adjunct Faculty who aren't in Peoplesoft.

    If they're teaching any courses, then they'll be added to the new PeopleSoft student system, which means they'll get EmplIDs, even if they aren't in HCM (to the best of my knowledge).

    compounding the error by using non-secret information as shared secrets.

    I would say this error is bound to happen any time someone tries to use the same piece of information for both identification and authentication. There's no such thing as a secret identifier. If something is an identifier, it will inevitably be passed around (to refer to a person, not just to state one's own identity) too much to stay secret, so if you count on it for authentication too, you're headed for disaster. The best case you can possibly hope for is a less severe disaster than SSNs - EmplID and cwruEduIdNumber have no meaning outside the university, so the problems will not be as bad as fraudulent activity showing up on your credit report. But the problems will come, just the same.

Post a comment