The real problem that https has conspicuously failed to fix

Anne & Lynn Wheeler lynn at garlic.com
Tue Jun 10 23:33:37 EDT 2003


At 11:26 PM 6/10/2003 +0200, Anonymous wrote:
>The problem to be solved is this.  Spoofed sites can acquire user
>credentials, especially passwords, and then use those to impersonate the
>user on the real sites.  With paypal and e-gold, this allows stealing
>real money.
>
>Using client certificates to authenticate would solve this, because
>even if the user got fooled and authenticated to the spoofed site, the
>attacker wouldn't learn the client cert secret key and so would not be
>able to masquerade as the user.
>
>The problem (among others) is that this allows a virus to steal the
>client cert.  If it is protected by a password, the malware must hang
>around long enough for the user to unlock the cert (perhaps because the
>malware sent a spoofed email calling for the user to visit the site,
>even the real site!).  It can then read the user's keystrokes and acquire
>the password.  Now it has the cert and password and can impersonate the
>user at will.

slight nit .... the solution is non-shared secret in conjunction with 
something you have authentication implementing, digital signatures, 
public/private keys where the private key is never divulged .... even to 
the owner (the private key housing can be hardware token ... or something 
embedded in the computer).

it seems that certificates sometimes are considered synonymous with 
public/private key and digital signatures. however, certificates were 
originated to address a specific issue with key distribution and trust 
involving parties that 1) had no prior business relation, 2) were unlikely 
to have any future business relationship, and 3) didn't have online access 
to trusted 3rd party. however, it is actually much more natural in a 
standard business process setting that public key is registered in lieu of 
shared-secret authentication material when parties are involved that have 
established business relationship (aka for example a person with some sort 
of an account, especially in any sort of online paradigm). A trivial 
examples is certificateless operation with public/private keys for radius, 
kerbers pk-init or x9.59 standard for all retail payment transactions 
(internet, non-internet, point-of-sale, debit, credit, ach, stored-value, 
etc).

Also note, a certificate tends to only contain the owners public key and 
some other information about the owner (and nominally is assumed to be 
freely distributable, somewhat in  the same way the PGP keyserver 
information is published). The certificate doesn't contain the private key 
... which tends to be either in a software encrypted file or an external 
hardware token.

for the various possible types of social engineering & virus exploits, 
eliminating shared secrets is only a partial solution (although shared 
secrets have a number of vulnerabilities and exploits, so eliminating 
shared secrets is not a bad thing)., if the individual has direct access to 
the private key in anyway, then it is possible to compromise that 
access.  That is where some flavor of "something you have" authentication 
comes in with hardware that houses the private key and there is no way to 
divulge the private key, even to the owner.  EU finread (financial reader) 
has an external reader with its own display and pin-pad. This addresses the 
issue (even with something you have hardware token) where a viirus can 1) 
display one value on the screen and send another value to the token for 
signing and 2) spoof keystroke entry with the correct PIN (perform 
fraudulent transactions w/o the owners knowledge).

If the

1) private key can never be directly physically accessed,

2) the digital signature is taken to represent a form of something you have 
authentication.

3) the display can be trusted to always display what will be signed

4) the keypad can't be spoofed and actually requires the person to hit the keys

5) hardware token never signs anything unless there has been (human) keypad 
entry

then the remaining types of fraud will tend to be no different than the 
phone scams, mail scams and the people coming to your door scams .... 
effectively no different than the types of fraud that has been going on for 
hundreds/thousands of years.


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


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list