- From: Bob Pinheiro <Bob.Pinheiro@FSTC.org>
- Date: Wed, 11 Apr 2007 21:28:37 -0400
- To: <michael.mccormick@wellsfargo.com>,<public-wsc-wg@w3.org>
- Message-ID: <E1HboAV-00085v-1V@aji.w3.org>
I agree that knowledge-based authentication does have a legitimate role to play in identity authentication, but (IMHO) only for initially helping to establish someone's identity when no prior business relationship exists. KBA should only be used infrequently, because the underlying assumption on which it is based is fundamentally flawed; namely that there is information about each of us that is "secret" and that would be difficult for an identity thief to obtain. Although I would agree that this assumption may be true enough most of the time to make KBA useful in certain circumstances, the ChoicePoint breach (and others too numerous to mention) demonstrates how apparently common it is for this "secret" information to be leaked. I think a better long term approach for identity authentication, especially when initially establishing one's identity with some entity for purposes of opening new accounts etc., might be to rely on a trusted third party Identity Provider to vouch for your identity in situations where you are initially unknown to the entity. This is the idea on which Microsoft's CardSpace Managed Cards is based. If Managed Cards were to become widely available from various IdPs, you presumably could go to an Identity Provider (possibly a bank or other FI) and rigorously establish your identity using KBA, paper documents, or whatever else is deemed to be sufficient. The IdP would issue you a Managed Card, together with credentials for subsequent authentication when you desire to use the Managed Card to assert your identity to some relying party (provided the relying party entity where you need to establish your identity trusts the IdP). So rather than having to verify your identity using KBA or knowledge of a SSN or whatever at each site where you are unknown, you establish your identity once at the IdP and then use Managed Cards from that point onward. As an example of how this might be useful, consider the website annualcreditreport.com, where you can go (in the US) to get a free credit report each year from the three credit bureaus. After asking for the usual identity information (name, birthdate, SSN, etc.), the site asks some knowledge-based questions. In my experience, these seem to be mostly mortgage or credit card-related questions. Imagine instead that you could choose some Managed Card to assert your identity to annualcreditreport.com. You choose the appropriate Managed Card and then must authenticate yourself to the IdP, using some strong mutual authentication scheme. The IdP then issues a token that you pass along to annualcreditreport.com, and that asserts your identity to the site. There are issues with using third party IdPs in this way, namely liability issues and a viable business model, but in concept this is interesting. Wells Fargo in particular is an IdP in the GSA's E-Authentication federation, but whether it could be a viable IdP for consumer-based CardSpace-type applications is (I assume) not yet established. Bob Pinheiro At 07:47 PM 4/11/2007, michael.mccormick@wellsfargo.com wrote: >I had to drop off the line for a few minutes at >the top of the hour during this morning's >meeting. Regrettably that moment came during >the Lightning Discussions just as Chuck Wade was >responding to MEZ's presentation on Shared >Public Knowledge (SPK). By the time I rejoined >to discussion had moved on to the next topic. > >What I would have said given the opportunity is >that Chuck is 100% right. In our industry this >battle has been fought many times and I see >little good coming from taking a hard line against all online use of SPK. > >Many US companies rely on services provided by >the likes of Choicepoint & Acxiom to perform >Knowledge Based Authentication (KBA) or Out of >Wallet Authentication (OOWA) of consumers in >certain situations, especially in cases where no >prior business relationship exists between the FI and said consumer. > >These KBA systems typically ask a series of >randomly chosen multiple choice questions >designed to score a user's knowledge of >semi-private information about himself or >herself. Examples might include "What model car >do you drive"? or "What’s the amount of your >monthly mortgage payment?". A determined >criminal could undeniably obtain this >information from public sources, perhaps even >use it to impersonate others, but that doesn't >mean there is no legitimate use case for KBA. > >A blanket prohibition against KBA is unnecessary >and would never be accepted. Asking the user >enough SPK based questions is not an >unreasonable authentication technique as long as >the associated risk is low, or when SPK is only >being used to supplement some other credential for extra assurance. > >The much maligned Mother's Maiden Name is an >example of weak KBA … but much stronger ones are >possible using tthe enormous databases of >personal data that are available from brokers >today. So I think the SPK "anti-pattern" would >benefit from being softened a bit to acknowledge >there's a place for it under certain conditions. > >Thanks, Mike > >Michael McCormick, CISSP >Lead Architect, Information Security Technology >Wells Fargo Bank >255 Second Avenue South >MAC N9301-01J >Minneapolis MN 55479 >(ï€ 612-667-9227 (desk) 7 612-667-7037 (fax) >( 612-590-1437 >(cell) J michael.mccormick@wellsfargo.com (AIM) >2 612-621-1318 >(pager) * ><mailto:michael.mccormick@wellsfargo.com>michael.mccormick@wellsfargo.com > >“THESE OPINIONS ARE STRICTLY MY OWN AND NOT >NECESSARILY THOSE OF WELLS FARGO" >This message may contain confidential and/or >privileged information. If you are not the >addressee or authorized to receive this for the >addressee, you must not use, copy, disclose, or >take any action based on this message or any >information herein. If you have received this >message in error, please advise the sender >immediately by reply e-mail and delete this >message. Thank you for your cooperation.
Received on Thursday, 12 April 2007 01:49:24 UTC