ref: http://www.garlic.com/~lynn/2005t.html#27 RSA SecurID product
part of the issue with authentication techniques is there pervasive use in electronic environments. one of the issues with "something you know" shared-secrets, is that a unique shared-secret was required for every different security domain ... as a countermeasure to entities in one security domain compromising a different security domain (aka the students hired for a local neighborhood garage ISP accessing the online bank accounts of ISP customers). as electronic environments proliferated ... the number of different security domains proliferated and some people now have requirement for scores of shared-secret passwords. the early guidelines also were that shared-secret passwords be impossible to quess and memorize and also changed frequently. an old april 1st password corporate directive from the early 80s http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM. http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM. http://www.garlic.com/~lynn/2001d.html#53 April Fools Day the inability of humans to keep track of scores of impossible to guess and memorize shared-secret passwords that change frequently led them to recording passwords in various ways ... which opens up new vulnerabilities (the combination of password proliferation and difficult, "secure" passwords results in the creation of new vulnerabilities). another way of looking at hardware tokens ... is that they are a physical object that acts as a countermeasure to simply guessing (or capturing recorded) passwords (nominally you have to capture the physical object). however, some of the token technology in the past just produced static data as proof of their possession. however, static-data possession proof is vulnerability to evesdropping/skimming. furthermore, in two-factor authentication, the basic premise is that the different factors have unique and different vulnerabilities. unfornately all static-data authentication technologies may have common evesdropping/skimming vulnerabilities, aka a token that generates static-data as proof of its possession and the entering of a shared-secret password might have a common evesdropping/skimming vulnerability (an attacker inserts a skimmer and captures both token static data as well as an entered pin/password). even shared-secret biometrics may be vulnerability to evesdropping/skimming threat. the following is discussion of form of evesdropping/skimming attack on one-time-password standard specificed by internet standard RFC 2289 http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication? http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication? http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication? http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication? http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication? which includes discussion of a form of man-in-the-middle attacks. misc. collected postings on mitm-attacks http://www.garlic.com/~lynn/subpubkey.html#mitm part of hardware token authentication should be technology that generates unique values for each authentication operation .... as countermeasure to evesdropping/skimming attacks. and as previously noted, hardware token technology may also be used to move from shared-secret paradigm to a secret paradigm ... where the person effectively authenticates themselves to the token (pin/password or biometrics) and the token is certified to only operate properly when provided with the proper authentication. The relying party when presented with token authentication, then may assume two-factor authentication based on previously obtaining details of the token certification. if the token authentication technology for generating unique authentication is sufficiently robust ... then there is the possibility that you could actually have a single token (aka person-centric) that is acceptable for multi-factor authentication in multiple different security domains (since there is no knowledge in the possession of one security domain that could be used for attacking another security domain). misc. past postings on the subject of person-centric vis-a-vis institutional-centric authentication technologies http://www.garlic.com/~lynn/2005g.html#57 Security via hardware? http://www.garlic.com/~lynn/2005m.html#37 public key authentication http://www.garlic.com/~lynn/2005p.html#6 Innovative password security http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
