RE: Shared Public Knowledge

The knowledge-based questions that are used by 
the credit bureau sites really are geared 
strictly for user-to-site authentication.  They 
are not especially useful for site-to-user 
authentication, because users do not even get to 
the point where these questions are asked until 
after they first provide sensitive identifying 
information such as name, SSN, birthdate, and 
address.  So if you have any doubts that the site 
asking for this information is truly a legitimate 
credit bureau site, you presumably wouldn't 
provide this information in the first place, and 
hence would never be asked these knowledge-based 
questions.  By the time these questions appear, 
it's too late to protect your information.

Bob

At 08:28 AM 4/18/2007, you wrote:

>Hi Tim,
>
>Can you give an example of a question that the 
>site could not appropriately ask unless it knew 
>the answer? Is it something that includes some 
>data about the user, and is not generic? More 
>like "What amount was charged to your Sears card 
>on April 1, 2007?" and not something generic 
>like "What is your current balance?".
>
>           Mez
>
>Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>Lotus/WPLC Security Strategy and Patent Innovation Architect
>
>
>
>Timothy Hahn/Durham/IBM@IBMUS
>Sent by: public-wsc-wg-request@w3.org
>
>04/18/2007 02:08 AM
>To
>public-wsc-wg@w3.org
>cc
>Subject
>RE: Shared Public Knowledge
>
>
>
>
>
>Mike,
>
>Your example below reminded me of the method 
>that Experian, TransUnion, and Equifax use to 
>help them understand that the person they expect 
>to be talking to them to get their free credit 
>report is who they think they are.  All of them, 
>by my recollection, put up a question asking to 
>answer something about one of your accounts 
>before displaying your credit report.  The 
>questions change, as do the accounts about which 
>the questions are asked.  But the answers given 
>do lend some credence to the site since they had 
>to have that information in order for them to 
>present it to the requester as a possible answer.
>
>Regards,
>Tim Hahn
>IBM Distinguished Engineer
>
>Internet: hahnt@us.ibm.com
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: 919.224.1565     tie-line: 8/687.1565
>fax: 919.224.2530
>
>
><michael.mccormick@wellsfargo.com>
>Sent by: public-wsc-wg-request@w3.org
>
>04/13/07 11:41 PM
>To
><Mary_Ellen_Zurko@notesdev.ibm.com>
>cc
><public-wsc-wg@w3.org>
>Subject
>RE: Shared Public Knowledge
>
>
>
>
>
>
>SiteKey (actually RSA Passmark) is just one of 
>many commercial products that use user-selected 
>images and/or passphrases to authenticate site 
>to user.  However that's not really SPK in my 
>opinion since the user's choice of image / 
>phrase does constitute a shared secret.
>
>I agree true KBA / OOWA is generally about user 
>authentication, however there's a subtle 
>(perceived) site-to-user authentication that 
>also occurs as a by-product.  If a site asks me 
>a multiple choice question "What model car do 
>you drive? (a) 1977 Ford Pinto, (b) 2004 Ford 
>Mustang, (c) 2007 Toyota Prius, (d) 1981 AMC 
>Pacer" this has a strong psychological 
>effect.  Seeing that the site obviously knows 
>what car I drive (it's "b" by the way :) 
>reassures me this site must be the legitimate 
>one that I have a prior relationship with.  If 
>the site knew something even more personal about 
>me (e.g., monthly mortgage payment) it would be 
>even more reassuring.  I know it's an irrational 
>response, but in this arena perception trumps reality.
>
>Mike
>
>
>----------
>From: Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com]
>Sent: Friday, April 13, 2007 4:53 PM
>To: McCormick, Mike
>Cc: public-wsc-wg@w3.org
>Subject: RE: Shared Public Knowledge
>
>
>I disagree, and if it makes sense as a site to 
>user antipattern (and I sense the jury still out 
>on that), if there is concensus, we can say 
>something appropriate about what, if anything, 
>should be implied for the other direction (and 
>the going in position from me would be, nothing 
>should be implied for the other direction).
>
>What things other than SiteKey use information 
>(secret, public, or shared public) to (attempt 
>to) authenticate the site to the use? Anyone 
>have more examples? Thanks Chuck for the Sitekey 
>one. And Chuck, is the last login time _really_ 
>meant to authenticate the site to the user? I 
>thought it was to give the user a hint if the 
>account had been unknowingly used by someone else.
>
>         Mez
>
>Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>Lotus/WPLC Security Strategy and Patent Innovation Architect
>
><michael.mccormick@wellsfargo.com>
>
>04/12/2007 07:34 PM
>To
><Mary_Ellen_Zurko@notesdev.ibm.com>
>cc
><public-wsc-wg@w3.org>
>Subject
>RE: Shared Public Knowledge
>
>
>
>
>
>
>
>
>Thanks for this clarification.  But my concern 
>is if W3C declares SPK based site-to-user 
>authentication to be an anti pattern, that 
>certainly implies it should never be used in the other direction either.
>
>
>----------
>From: Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com]
>Sent: Thursday, April 12, 2007 3:17 PM
>To: McCormick, Mike
>Cc: public-wsc-wg@w3.org
>Subject: Re: Shared Public Knowledge
>
>
>I would like to do a rewind on this thread. 
>Everyone who participated, go back to the 
>proposed recommendation that we discussed:
>
>http://www.w3.org/2006/WSC/wiki/SharedPublicKnowledge
>
>It's about authenticating the server to the user 
>(since that's one of our primary goals). Not the user to the server.
>
>So I will assume all discussion of the latter 
>was interesting and informative (it was for me), 
>but not about the actual proposal being 
>discussed. Maybe that's because the proposal is 
>about something nobody does or wants to do. That 
>would make it nice and safe for our recommendations :-).
>
>        Mez
>
>Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
>Lotus/WPLC Security Strategy and Patent Innovation Architect
><michael.mccormick@wellsfargo.com>
>Sent by: public-wsc-wg-request@w3.org
>
>04/11/2007 07:47 PM
>To
><public-wsc-wg@w3.org>
>cc
>Subject
>Shared Public Knowledge
>
>
>
>
>
>
>
>
>
>
>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 ¡K but much stronger ones 
>are possible using the 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
>(ƒn     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.
>