In my last blog post, If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later. Redux, I mentioned the use of social security number as a potential record lookup key when mapping a CSP identity to a RP record. This blog post looks at that process in a bit more detail, and explores both the value of social security numbers and the potential dark side (id theft) when they are misused.
To start, it is important to distinguish between “Authentication”, which is the process of verifying that someone is who he or she claims to be and “Identification”, which simply matches an individual with his or her records, but does not prove that the individual is who he or she purports to be.
That in turn points to the current (bad) practice of using SSNs as both an identifier and an authenticator, which raises significant identity theft concerns.
From the FTC Report on SSNs and ID Theft:
There appears to be broad consensus that the use of the SSN as an identifier – to match individuals to information about them both within an organization and between organizations is prevalent and, in many contexts, beneficial
Many entities also use SSNs to authenticate consumers, i.e., to verify that individuals are who they say they are. These entities, in effect, treat the SSN as a secret piece of information, available only to the consumer and themselves, and give access to information or benefits only when the consumer is able to supply and confirm his or her SSN
This dual use of the SSN as identifier and authenticator has created significant identity theft concerns [...] Identifiers are effective only when they are widely shared. [...] Authenticators, on the other hand, are effective only when they are secret and thus not widely known. [...] SSNs do not function well as authenticators because they are used commonly as identifiers and thus are widely available.FTC Report: Security in Numbers, SSNs and ID Theft
What I proposed, in cases where there are no other shared pieces of information AND if the SSN was already in the RP system, is to use the SSN as an “identifier of last resort” to look up the RP record. It explicitly does not use the SSN as an authenticator.
This approach has also been called out in the FTC Report on SSNs and ID Theft:
Although the SSN generally is inadequate as a sole authenticator, it can be used effectively in the authentication process. Indeed, numerous organizations reported that they may ask a consumer to produce her SSN not because it is adequate authentication, but rather to link to other data sources that contain additional information about her that can be used to verify her identity. [...] the SSN may not be well-suited as an authenticator itself, but can be and is used effectively to detect potential fraud by permitting access to other authentication-related information.FTC Report: Security in Numbers, SSNs and ID Theft
Having said that, this does require an organization to have a clear but nuanced view of the enrollment process and about how/why the SSN is being used. Unfortunately, what you often get when SSNs are brought up is a one-size-fits-all “Here be dragons” reaction.
- If You Don’t Plan For User Enrollment Now, You’ll Hate Federation Later. Redux.
- FTC Report: Security in Numbers, SSNs and ID Theft (PDF)
- Wikipedia: Here be dragons
- How To Enroll a User, Even When There are No Shared Identifiers
- User Enrollment Challenges with PKI Credentials
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.