Disney Biometrics
April 9, 2006 | 6 Comments
One of the oddest things I saw this year while at SunGard Higher Education’s Summit 2006 was the biometric finger scanners they now use at Disney. Yes, you read that right, Disney is now using biometrics to help crack down on people sharing multi-day passes and other gate fraud. Disney softens this fairly invasive technology by branding it “ticket tag”.
While there I asked the gate keeper what the machine actually does. He explained that the dimensions of your fingers are measured, and the first time this data is encoded on the magnetic stripe on the back of the card. On each subsequent visit, a new measurement is compared against what is on the card. He then assured me that the data is not stored in a central Disney database. Still a bit curious, I asked about reliability. He informed that they get their fair share of failed scans, especially on people with arthritis or other conditions which can cause a variation in someone’s finger dimensions.
I found this description on how you use the machine:
You insert your pass into the park entrance turnstyle just like everyone else. After you have inserted your pass, you put your index and middle fingers into the scanner located atop the turnstyle. Once your fingers are inside the scanner, you will feel two small rubber knobs. Place your fingers so that the rubber knob is between the index finger and the middle finger. *LIGHTLY* bring them together so they touch the rubber knob and push your hand all the way in so the web part between your index and middle fingers touches the small plastic spindle at the very front. Do not squeeze the rubber knob tight.
A quick blurb about how finger geometry works:
finger or hand scanning systems capture the physical, geometric characteristics of an individual’s hand – with most systems having the capacity to do so in less than a second. From these measurements, a profile or “template” is constructed which will be used to compare against subsequent readings by the user.
It is important to note this is not fingerprinting. I think in many ways it is similarly invasive, and if Disney is in fact storing and cataloging all this data it is far scarier than the police having your fingerprints. I was very surprised how few people seem to ask the gate attendants what is going on. Everyone accepts this a necessary act for entering the park. If this does bother you, you can refuse and show an ID card instead. I’d be curious how many people do… I bet it is less than .01%.
Also of interest are these further discussions:
Mickey Prints
Biometrics at the Disney Gates
Tags: biometrics, disney, disney world, finger geometry, identity, security, ticket tag, walt disney
Leveraging CAS with Luminis
March 28, 2006 | 4 Comments
In SunGard Higher Education's Luminis product one of the many add-on packages you can install is CAS support. CAS is an acronym for Central Authentication Service. This WebISO solution is one of the most common in higher education. CAS was created originally by Yale, but ongoing support has been taken over by JA-SIG. When the CAS package is installed in Luminis, it makes Luminis act as a CAS authentication provider. Coupled with this built-in Luminis support, we use a CAS library called phpCAS that adds to the simplicity of deploying this within our environment.
Time and again, CAS has been proven an effective and simple way for us to quickly drop authentication ability into our homegrown PHP applications. Once a function was developed, this was easily reused across dozens of applications within a few short months. The ease of deployment made it easy to convince various developers to switch from custom authentication schemes.
In a PHP application on any of the servers in your environment you can do something like the following:
-
<?php
-
-
function casify()
-
{
-
// import phpCAS lib (http://esup-phpcas.sourceforge.net/)
-
include_once($GLOBALS['INCLUDES'].'/cas/CAS.php');
-
-
// initialize phpCAS
-
phpCAS::client(CAS_VERSION_2_0,'luminis.institution.edu',443,'cas/');
-
-
// check CAS authentication
-
phpCAS::forceAuthentication();
-
-
// at this step, the user has been authenticated by the CAS server
-
// and the user's login name can be read with phpCAS::getUser().
-
-
return phpCAS::getUser();
-
}
-
-
-
$username = casify();
-
-
// nothing past the execution of casify() would occur without acquiring a valid CAS ticket
-
-
?>
Note: the preceding code is an example. There is more sophisticated functionality that can be accomplished using CAS, this is merely a starting point for people interested in this WebISO technology.
Tags: cas, development, education, higher education, identity management, jasig, luminis, php, phpcas, security, sungard, sungard higher education, web development, yale, yalecas
RFID in Passports
November 3, 2005 | 3 Comments
I've been concerned and generally against RFID since the first time I heard about it. Maybe its because I know a little about security, or identity management, or hell even the way markketing in a digital world works. Anyway, our brilliant US State Department is planning a roll out of RFID in passports for October 2006.
From Wired, Fatal Flaw Weakens RFID Passport:
In 2004, when the U.S. State Department first started talking about embedding RFID chips in passports, the outcry from privacy advocates was huge. When the State Department issued its draft regulation in February, it got 2,335 comments, 98.5 percent negative. In response, the final State Department regulations, issued last week, contain two features that attempt to address security and privacy concerns. But one serious problem remains.
Good that they fixed a couple problems, but a ton more are certain to crop up. I feel my fears aren't misplaced. I guess I'll have to keep posting this negative RFID stuff to help promote awareness of this garbage.
Tags: identity, passport, passports, RFID, scary, security
Establishing and Securing Identity in a Distributed World
September 2, 2005 | 10 Comments
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)
Tags: faces, identity, identity management, information technology, it, Jon Emmons, password, password management, passwords, PCAC, pki, pooch, security, Zach Tirrell, Zachary Tirrell
Single Sign-Out and Session Management
August 10, 2005 | 6 Comments
When dealing with portals we all get very excited about single sign-on (SSO), but I think we often forget single sign-out or overall session management. The end user really gets the main visual benefit from SSO, so this is what I find myself concentrating on. Yet, if somehow connections to external systems are not addressed when a user logs out, you have a potential security problem.
So, the apparently easy solution is to set things up so all sessions on externally connected systems are destroyed when a user logs out. But what if the user wants one of the external systems open? Personally I think that one is easy too, they learn from experience that all connected systems are logged out.
But, what if they don't explicitly log out, but rather their session expires from inactivity? You certainly don't want to log someone out of an external system when they might in fact be active in that external system. This leads to the need to be able to make a call which checks with the external system to see if a user is still active in that system. Then the portal can extend its timeout to wait for the external system.
In a perfect world, an external system could log a user out on demand and could also return some sort of last activity for the user in their system. We don't live in a perfect world. Very few systems are likely to understand how to do these two things straight out of the box. This leaves us trying to find some reasonable middle ground on an application by application basis.When we consider all these things and determine a way to accomplish this, we are no longer talking about single sign-out but complete session management. Just logging someone out is single sign-out, logging someone out conditionally and handling timeouts intelligently is session management. Obviously a well integrated external system will employ session management.
In our environment we have recently been opting for YaleCAS (or just CAS) as a solution to integrate all homegrown external systems. The phpCAS library we use does not do session management appropriately. Luckily we should be able to modify it to make this all work out.
For other systems we use Campus Pipeline Integration Protocol (CPIP). CPIP is far more complex that CAS, but does allow for complete session management. So for now, we need to use CPIP for important, secure apps, and be aware of the limitations of CAS.
Tags: authentication, authn, cas, cpip, identity management, phpcas, security, session management, single sign on, single sign out, sso, yalecas