Re: passwords

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 01/20/04 

Date: Tue, 20 Jan 2004 20:19:22 GMT

Colonel Flagg <colonel_flagg@NOSOUPFORJ00internetwarzone.org> writes:
> 3-6 months ago, either in here or on slashdot, someone posted the URL to
> an article written about password strengths and statistics attempting to
> show that passwords above a certain number of characters was no more
> "secure" than a password of lesser characters.... anyone remember the
> URL or have it bookmarked?

the number of characters in theory are analogous to the number of bits
in crypto key ... and therefor can be viewed from the stand-point of
how long will a brute-force attack take. however, if the
infrastructure supports limit on consecutive bad passwords or other
defensive methods ... then brute-force attacks can be thwarted (and it
is no longer necessary to have ever increasing key sizes to make
repetitive trying of all possible values impractical).

there is a second order problem .... the whole issue of
1) frequently changing shared secrets
2) shared secret paradigm propogated into scores of environments
3) requirement that unque shared secret be used for every
   different security domain

overloads typical human memory capability leading to people having to
write the scores of passwords down. long, complex passwords can
aggrevate the human memory limitations. many/most of the password
articles seem to address the issue from purely myopic position that an
individual never will be in position of dealing with more than a
single security domain (and never having to remember more than a
single password that may never change).

what in fact happens, the threat model can be against the aid used for
remembering scores of passwords ... not the actual password themselves
(trojan horses looking to harvest password files).

an alternative is to go to a two-factor authentication based on
non-shared-secret (something you have and something you know)
.... aka

1) a hardware token that does a digital signature and can be validated
by a public key (that has been registered in lieu of a shared-secret
password). having access to list of registered public keys in one
security domain wouldn't compromise the use of the same public keys in
a different security domain ... aka a shared-secret can be used to
both originate as well as validate an authentication ... while a
public key can't be used to originate an authentication ... but can
only be used to validate an authentication

2) a PIN that controls the operation of the hardware token. both
shared-secret and hardware token PIN represent "something you know"
authentication. However, if a shared-secret something you know, is
divulged, it possibly enabling others to fraudulently use the
shared-secret to impersonate (the security requirement for unique
shared-secret for every security domain). A hardware token PIN is also
a form of "something you know" ... but since it never has to be
divulged, it can drastically simplify the human memory issues. Instead
of having scores of shared-secrets ... the person has a single
hardware token, controlled by a single PIN ... that is never divulged
and is not a shared-secret.

It is in the non-shared-secret, hardware token PIN paradigm ... that
you can start talking about a threat model being against the PIN
itself, the length of the PIN, etc ... since the human memory issues
with large numbers of security domains and scores of shared-secrets
are significantly mitigated.

Note, a trojan horse that harvests a person's password file ... can
lead to being able to impersonate that person in large number of
different situations. Any sort of virus or trojan horse that harvests
a hardware token PIN still isn't able impersonate w/o also having
access to the hardware token. From a fraud return-on-investment
... the costs for harvesting a hardware token PIN and gaining access
to the hardware token itself is significantly higher than the cost of
harvesting password files (or in the electronic commerce scenario, the
merchant master transaction file). Such hardware token related
acquisition costs might even be larger than any expected fraud return
... making it more attractive for the criminals to go elsewhere.

and even more topic drift about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

lots of past stuff about non-shared-secrets
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aadsm12.htm#60 signing & authentication (was Credit Card Scam)
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002h.html#40 [survey] Possestional Security
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
http://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
http://www.garlic.com/~lynn/2003h.html#55 PKINIT
http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
http://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#9 Bank security question (newbie question)
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003o.html#44 Biometrics
http://www.garlic.com/~lynn/2003o.html#50 Pub/priv key security
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication? 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm