Establishing and Securing Identity in a Distributed World

// September 2nd, 2005 // Technology Bits

We have found ourselves in an interesting position. We need to establish, ensure, and maintain identity with remote users without ever exchanging SSN or other highly confidential identifiers or information. Popular solutions include security questions, requiring initial email address, authoritative remote identity providers (ex. notary), or physical presence. First let me debunk all of these in our environment.

Security questions:
- limiting questions to predetermined ones, simplifies ability to automatically guess answers.
- with increased personal information becoming available online, personal questions may have answers easily found.
- open questions often lead to simple question/answer combinations (ex. what color is the sky? blue.)

Initial email address:
- we provide email accounts as a service, requiring an email account to get an email account is laughable
- expired or abandoned accounts are a dead end for ongoing use

Remote identity providers:
- time consuming and cumbersome for the user
- costly for the user
- much manual work
- difficult globally

Physical presence:
- could be time consuming
- online education implies never needing to come to campus
- difficult globally
- not remote, if they have to come here

One potential solution in this space is Faces. This is also potentially cumbersome and the cost is unknown.

Now let me present our solution.

Upon account creation at the institution (student, faculty, guest, alumni, etc), we generate a 32 character password change authorization code, or PCAC, (ex. KLAS-DFHL-KASD-FKLJ-KKL3-243I-HF34-POI2) and a unique username. The account is initially locked. The user receives the username and code through the postal service to a known address, in person, or it is presented to them online if they are able to establish an account-creating relationship online.

Once they have the PCAC, they are instructed to keep it in a safe permanent location (ex. with birth certificate or social security card). They are also intructed to use this code to activate their account and set their password online. From anywhere in the world they can enter the PCAC and username into a secure web form, to set their password.

Once the user has a known username and password combination they use this to access all their services.

This same procedure can be used in the future to instantly reset their password if they have lost or forgotten it. Of course if they know their password they will always be allowed to use that to change it to something else.

At this point they have established identity, received credentials, and with their PCAC can always recover from lost or forgotten passwords. All these steps can be performed online, self-service. The security of their account is primarily in their hands. No one at the institution ever knows their password, and their is no formulaic way of figuring it out. There are no guessable hints.

All of this explains the situation where the user has their PCAC or password. In the contingency where they have lost or misplaced their PCAC, they can have a new one created immediately in person, or request a new one to be mailed to them via an online form.

I have posted this with hopes that people will review this and comment on their opinion of its viability. Please leave comments if you see problems or advantages in this we have not.

This solution is not useful for schools with a PKI solution, but could be used very easily as a cheap intermediary solution while that area matures.

Flowchart of this process (PDF)
PCAC Example (PDF)

Jon Emmons’ article on this same topic: Password Management in an Identity-Theft World

(This proposal authored by Jon Emmons and Zachary Tirrell - 2005)

faces, identity, identity management, information technology, it, Jon Emmons, password, password management, passwords, PCAC, pki, pooch, security, security, Zach Tirrell, Zachary Tirrell

Related items

17 Responses to “Establishing and Securing Identity in a Distributed World”

  1. Life After Coffee » Password Management in an Identity-Theft World says:
    September 2, 2005 at 1:55 pm

    [...] To read more about our procedure, check out Zach Tirrell’s post about this procedure on his blog.   [...]

  2. Dw says:
    September 7, 2005 at 5:12 pm

    This is an interesting solution. I like the self-service aspect, along with the personal accountability.

    Here are questions and comments that come to mind.

    1. Why 32 characters…that’s rather long, isn’t it. I assume it is a standard.

    2. So once the user logs in with their new PCAC, they can immediately reset their username and password. Cool.

    3. If they forget their username and password, and forget where they put the darned PCAC, or they are away from it, they have to show up to Library (HD next year) to get a reset or wait for snail mail. The accountability factor is good, the time delay on service may not be acceptable. Case in point: Grad student working from a distance. 2-3 days for mail is going to be a problem. The more online we go, the more this will impact us.

    4. Can we have an intermediary step?

    Let’s keep rolling this around, not a bad idea.

    We might want to talk to some non-ITS folks. Let a lay person respond to it.

  3. zbtirrell says:
    September 7, 2005 at 6:05 pm

    My responses to DW:
    1) 32 characters is pretty standard for product codes and things, also would allow us to simply generate and store an MD5 for the user. Also, we don’t want users or even casual observers to remember or simply memorize this code.

    2) for now we’re saying set their password, their username would be preset. But, this would obviously be easy enough to go one way or the other on.

    3) If a user forgets their username and password, AND loses the PCAC, the accountability is clearly on their end. That said, it is clearly a problem wiht distance ed to have any kind of lag. What other solution would allow for quicker re-entry than PCAC? Right now I can’t think of anything that would be both secure and at all faster… I’d love to entertain ideas here if anyone has a solution.

    4) intermediary step… hmm, not really, our structure isn’t radically different than this now, so we’re sort of at an intermediary. I have a flowchart of the current process and you can see this is true. (I didn’t really want to share that sad/scary process with the world)

    As this is on the Internet… I hope other non-ITS people can be pointed here and review this. I welcome comments from the world.

  4. Erich says:
    September 8, 2005 at 8:22 am

    1. I agree that 32 chars is a proper (and standard) length for the PCAC, or any other token scheme that you decide to use.

    2. One of the benefits of using a PCAC or token to provide temporary authentication is that you could embed the code in a URL and present that URL to the user, which would bring them to a password change form online. Unfortunately, this would kind of require that the user already has an email address that could be used to send the PCAC to. Perhaps there could be two methods - email and snail mail and let the user choose how to receive the PCAC. Otherwise, I would be concerned about snailmailing this stuff and the time lags there.

    3. The other concern is that a PCAC is tough to enter manually, and may scare users off. Then again, it’s no worse than manually entering Micro$oft license codes…

    4. Is there a benefit to keeping the PCAC valid after a password has been changed? If it is still valid, there is a small security risk there by having a backdoor. In the event of a lost password, should you just send a new PCAC?

  5. al says:
    September 8, 2005 at 2:49 pm

    Regarding the lag of having to snail mail another pcac to the user should they lose it … Unfortunately email is inherently insecure and very easy to spoof, but what about a fax process similar to what network solutions does? Domain registrars have much the same problems as you’re looking at here, with the exception that they never see anyone face to face, yet people are always trying to hijack domains.

    If you’re not familiar with netsol, here’s how it works: If you lose your password, and your email has changed so that you can no longer use a forgot password link to have your password emailed to you, you can fill out a form on their website with your information, then print that form, attach a copy of your driver’s license, and then fax it in. In this case should a user forget their password and lose their PCAC, they could fax in a new request for a pcac with a copy of their photo id along with the email they want their new pcac sent to. Turn around time should be very low …. if you don’t include a username with the pcac in the email, then anyone who happens to intercept the email or get it through an error in the email address will find a pile of letters that won’t get them anything without the username. Just a thought.

  6. fportnoy says:
    September 8, 2005 at 3:49 pm

    Seems plausible on the “face” of it ….. but maybe the username and the PCAC should not be distributed together, but kept seperate, as banks do when mailing out the ATM card and the PIN.

  7. bhoch says:
    September 8, 2005 at 3:50 pm

    I agree the plan looks like a bear of an undertaking and I wonder if there are more worthwhile IT projects to complete on campus (a consolidated place to obtain computer help for users & sysadmins for starters). How many email accounts have been comprimised as a result of SSNs being stolen (or vice versa?) I think this plan might cause more confusion among users and the number of users whose identities would be “saved” by this would be minimal. I would prefer to see increased usage of the student IDs (generated by PSU randomly*) and decreased usage of SSN across campus. For example, a user may not obtain an email account without first having a student ID # (ideally a card too). The student number should be used in the account/password creation process, NOT the SSN as is currently the case.

    Anytime I see an SSN on campus, I ask myself, why an SSN and not a student or employee ID? Some campus depts obviously need it (HR, Financial Aid), but can they be more properly cared for? Does HR really need to ask for an SSN on the job application, or can it be ascertained after the indivdual has been hired? I was able to obtain 3-4 SSNs just by looking at faculty candidate folder in our office this past year! The big question goes beyond ITS and really is geared more towards indivdual departments who do use SSNs. There’s some social engineering that needs to happen here, and I believe that some of that burden must fall on campus entities other than ITS.

    That’s my 2 cents. You guys are on the front lines of all this, though, so you may have a different perspective. It’s a tough problem no matter how you slice it. Let me know if I can provide more feedback.

    Good luck!

    Brendon

    * PS: Not sure if “student ID” is the same as “Banner ID” is the same as “Employee ID”, but I’m simply refering to an internally generated random alphanumeric number.

  8. zbtirrell says:
    September 8, 2005 at 3:52 pm

    Fred - I love the idea of sending username and PCAC seperately. This helps to assure intercepts will not cause a security problem.
    Brendon - There are 2 major forces driving the need for this change. First, in our current system we have to have the SSN to generate the password and let users know what the password is, this isn’t legal, so must change. In fact we have already started making numerous exceptions, and in turn these are cumbersome to support and time consuming to maintain. Second, as we look more at federated identity management, we need a secure industry accepted method of establishing and maintaining identity, ours currently would not be acceptable.

  9. Casey says:
    September 8, 2005 at 4:18 pm

    Whatever solution we choose, it will likely be better and quicker than the “show us that you’re receiving a utility bill in our town to prove that you’re a resident” baloney that goes on all over New Hampshire.

  10. NoSheep! » NERCOMP: Identity Management SIG says:
    September 27, 2005 at 9:45 pm

    [...] In the final time slot was a general group discussion. I took this opportunity to ask how schools are establishing and maintaining credentials remotely. No one had an answer that was ideal, I suggested our current proposal and no one seemed to have any criticisms. One person suggested that maybe we don’t need to have as secure a system as we’re proposing to merely secure someone’s email. My reply to this was in a federated world with connections to the federal PKI bridge, InCommon services, and more, we are securing far more than email. It is our responsibility to have as high a level of assurance as possible. [...]

Leave a Reply

Sponsored Links