[OpenID] (Slightly off-topic) - Suggestion for in-browser secure2-way authentication resistent to online and offline attacks

Jared Williams jared.williams1 at ntlworld.com
Thu Mar 8 03:53:50 UTC 2007

	Reading this did get me thinking. 
	If have 

	input[type='password'] { -moz-user-input: disabled; background:
#ff6347; }

	@-moz-document url-prefix(https://myopenprovider.org/)
		input[type='password'] { -moz-user-input: auto; background:
#fff; }

	in a custom user (userContent.css) stylesheet, it effectively
creates a whitelist of url-prefixes / domains that I'm allowed to enter
passwords too.

	Obviously not a solution for the masses, but thought I'd share.

As for 

> iv) passwords now consist of a 2-way authentication step including
>     mouse clicks and visual elements, making the automated theft by
>     existing trojans difficult.

I don't think that is difficult. Its just a matter of logging js event
objects, and replaying. So would have to alter the position of the hotspot
relative to the (0,0) of the image, via padding/scaling/shearing perhaps?
Not sure generating a single image tiled from say 9 (3x3) images randomly
would be enough.


> -----Original Message-----
> From: general-bounces at openid.net 
> [mailto:general-bounces at openid.net] On Behalf Of Chris Drake
> Sent: 07 March 2007 14:26
> To: general at openid.net
> Subject: [OpenID] (Slightly off-topic) - Suggestion for 
> in-browser secure2-way authentication resistent to online and 
> offline attacks
> Hi All,
> Since authentication has been mentioned a few times in the 
> past, I wish to propose here a simple solution to the variety 
> of authentication problems we've been attempting to solve.  
> Here is how it works. 
> At enrollment, a user
>  A) chooses or gets assigned a username (eg: their email address)
>  B) chooses or gets assigned one or more of
>     1. A password
>     2. A client certificate
>     3. A hardware token
>     4. A Biometric identifier
>     5. Etc...
>  C) chooses or gets assigned a photograph (for sake of my example -
>      lets assume they pick a photograph of a dog out from a selection
>      of 16 random photos.)
>  D) selects some point on their chosen photograph to be their login
>      "hot spot" (for example - the nose of the dog).
>  (Vision impaired folks may instead choose song snippets and 
> some  particular point in their chosen song, rather than use visuals)
> Here is how a login would proceed:
>  E) User loads up the login page, which contains the following
>     elements:
>     1. a single disabled input box for their username
>     2. a button, positioned as close as possible to the page URL
>     3. an instruction, in or near the button of the form:
>        Click the button after you confirm that your login url
>        above reads "https://example.com/"
>     4. Another button position as close as possible to the SSL padlock
>        icon
>     5. an instruction, in or near this button of the form:
>        Click the button to confirm that the SSL padlock is showing
>     6. Optionally - A "report problem" button
>  F) User clicks button E2, clicks button E4 (which enables the
>     username box), and then enters their username (or accepts a
>     cookie-populated username in the case of "cached" logins)
>  G) User authenticates to the server using their one-or-more
>     authentication elements from step B
>  H) Server authenticates to user by showing one or more photographs,
>     including their assigned one (the dog).
>  I) Use logs in by clicking on their "hot spot" (dogs nose.)
> Numerous problems are thus solved.
> i) users are physically blocked from being able to log in to spoof
>    sites, because spoof sites cannot know the users photo, thus the
>    user can't find it to click on.  Users also know immediately that
>    something is wrong when they don't see their photo.
> ii) users can't be easily tricked into telling anyone their password,
>     since it now consists of "difficult" things (pictures and places
>     in them) that are not always easy to explain (excluding my
>     simplistic dog example).
> iii) users cannot easily write down their password for other people to
>      find.
> iv) passwords now consist of a 2-way authentication step including
>     mouse clicks and visual elements, making the automated theft by
>     existing trojans difficult.
> v) man-in-the-middle (proxy) attacks are made very difficult, since
>    the user is instructed to check the SSL status initially, and the
>    server will be able to verify logins are occurring from legitimate
>    IP addresses.
> vi) dictionary attacks can be made difficult by giving no indication
>     of incorrect password attempts, besides the decision to NOT show
>     the users photo on the next screen: users will understand the
>     mistake immediately when they don't see their photo - hackers
>     would not know what photo to look for - thus won't know when
>     they've found the correct password.
> vii) Most robots are unable to log in, which may improve security.
> viii) About 30 more benefits exist - see the URL at the end of this
>       message.
> Layered security can be applied based on the value of the 
> site being accessed - for sites willing to allow users to 
> "remember" login data, they can opt to also "remember" the 
> step (B) authentication data as well, making the 
> re-authentication procedure for the user on subsequent visits 
> extremely easy: they simply load up their login bookmark 
> (which displays their photo based on their "remembered" login
> preference) - and click once on their photo hot-spot to log in.
> So - to summarize - a fully authenticated login consists of the steps:
>  E) Enter username
>  G) Enter password
>  I) Click photo hot-spot
> A re-authentication login consists of the step
>  I) Click photo hot-spot
> All the above is suitable for immediate deployment in 
> existing web browsers - no additional plugins, software, 
> security, or chrome is required.  In my limited testing, 100% 
> of my subjects (including
> computer-phobics) understood and operated this system 
> successfully with no training.
> Here is the list of threats that I hope my proposal mostly solves:-
> http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-J
> uly/000342.html
> --
> Please pick apart my idea, suggest attacks, suggest 
> improvements examine the full list of threats, and otherwise 
> comment on my proposal.
> Kind Regards,
> Chris Drake
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

More information about the general mailing list