The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Alan Altmark) writes: > And, more importantly, change. I know of a large multinational IT company > that has a 90-day password change policy, applying to system AND network > access. It doesn't close the window completely, of course, but it *does* > reduce risk. > - How long since I changed my pw did I lose/throw away my smartphone? > - How long did it take someone to find it? > - How long did it take them to break into it? > - How long did it take them to figure out it it was worthwhile to try it? > > Polices that suspend network/system access due to inactivity help as well. passwords and other shared-secrets paradigms http://www.garlic.com/~lynn/subpubkey.html#secrets are "something you know" authentication ... out of the 3 factor authentication model http://www.garlic.com/~lynn/subpubkey.html#3factor some number of the tokens are "something you have" authentication ... but they also use some sort of "secret" to "prove" the possession of a unique object. the issue in the "secret" paradigms ... is that the threat models involves leakage of the secret (especially when it is stored and used in so many places) and cross-domain exploits ... i.e. passwords and/or secret-based tokens require a unique value for every security domain ... as a countermeasure to entities in one domain attacking another domain, a form of insider attack as opposed to various outsider attacks skimming/harvesting secret. http://www.garlic.com/~lynn/subpubkey.html#harvest part of the requirement for frequent secret changes is that secrets can leak (guessing, skimming, evesdropping, harvesting) w/o the entities being aware .. and then authentication replay attacks. this can happen with some forms of tokens (like magstripe), which may also be susceptible to evesdropping, skimming, harvesting attacks and the creation of counterfeit token for replay attacks. The issue of a purely "something you have" token, the person can notice a lost/stolen compromise and report it. However, a guessing, skimming, evesdropping, harvesting compromise might occur w/o the person being aware of it happening. for cross-domain exploit and other reasons, there has also been a instititional-centric paradigm for hardware tokens ... i.e. each institution issues their own hardware tokens. I've frequently commented that if this were to ever take off ... you then would have one hardware token for every pin/password (which is scores or even on the order of hundred for some people). I've periodically drawn the analogy with the mid-80s use of unique floppy disks as a DRM paradigm for applications programs ... i.e. appearance of hard disks was evolving installation of applications. There was early use of specially coded floppy disks as a DRM countermeasure to software pirating. If this paradigm ever had a large uptake ... there could be computers with hundreds of associated unique floppy disks (one per application) that the person would have to continually shuffle as they switched between applications. In the case of emerging token use, having a hundred or so tokens stuffed into a (very large) pocket. As an aside, about the time of the ibm/pc announcement there were some investigation into adding a unique serial number chip to each motherboard and a software licensing paradigm ... similar to mainframe, based on storing the cpu identifier. there are two-factor authentication schemes using both a pin/password ("something you know") and a token ("something you have") also as a countermeasure to lost/stolen token. the issue here is an assumption that the multi-factors are subject to independent vulnerabilities. however, you find some of the pin/magstripe implementations being vulnerable to a common skimming compromise (i.e. both the magstripe and pin is recorded at the same), invalidating the assumption about independent vulnerabilities. a similar infrastructure problem showed up with the two-factor chip&pin deployments (with pin as countermeasure to lost/stolen token). the chip would present some static data authentication (as proof of having the unique "something you have") and then the infrastructure would ask the token if the correct pin was entered. the attackers would skim the static data (in much the same way that magstripes are being skimmed) and use it to produce a counterfeit "yes card". once the static data had been checked by the infrastructure, the chip would be asked some number of additional questions about business processes (like whether the correct pin was entered) ... and, of course, the counterfeit "yes card" would always answer "YES" (from where the exploit got its name). Again there wasn't an independent vulnerbility for the PIN entry ... and assumptions regarding multi-factor authentication was no longer valid. a few past posts discussing enabling token person-centric infrastructure as an alternative to institution-centric infrastructure ... http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards 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 http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing" http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
