man in the middle, SSL

Anne & Lynn Wheeler lynn at garlic.com
Tue Feb 6 10:40:18 EST 2007


Leichter, Jerry wrote:
> Recall how SiteKey works:  When you register, you pick an image (from a
> large collection) and a phrase.  Whenever you connect, the bank will
> play back the image and phrase.  You aren't supposed to enter your
> password until you see your own image and phrase.

i.e. it is a countermeasure to a impersonation attack ... not a man-in-the-middle
(impersonation). all it presumably attempts to address is "are you talking to the website you think you are talking to" ... which is the same thing that SSL countermeasure to man-in-the-middle is supposed to be doing.

man-in-the-middle can defeat simple impersonation countermeasures by impersonating the server to the client and impersonating the client to the server ... and (somewhat) transparently passing traffic in both directions. requiring the server to present unique "something you know" authentication information is then straight forward for man-in-the-middle by having access to the "real" server.

i would contend that the issue for introducing sitekey ... was that SSL wasn't adequately protecting against man in the middle attacks ... i.e. previous posts
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
http://www.garlic.com/~lynn/aadsm26.htm@28 man in the middle, SSL

... however, i contend that sitekey isn't even designed to be countermeasure against man-in-the-middle attacks ... it only is a countermeasure against simple impersonation attacks ... so it isn't even addressing the short-comings in SSL that (my opinion) gave rise for the need for sitekey in the first place.

the other issue is that "your own image and phrase" is a shared secret (and a flavor of 
static "something you know" authentication) ... so it presumably requires similar practices required for password shared secrets ... if it had turned out to significantly address SSL short-comings (mitm-attacks) and saw wide deployment .... then presumably you would need a unique flavor for every unique security domain (ala password shared secrets). The implication then is that it would scale as poorly as password shared secret paradigm.

previous post mentioning that the paradigm might scale as poorly as other shared secret based authentication implementations
http://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules

misc. posts mentioning man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

misc. posts mentioning shared secret (authentication) paradigm
http://www.garlic.com/~lynn/subintegrity.html#secret

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



More information about the cryptography mailing list