Subject: [OAUTH-WG] Preventing phishing attacks with auth server verification?

From: Aaron Parecki <[email-masked]>
Date: Tue, 6 Dec 2011 09:42:02 -0800

Has there been any discussion about supporting a 2-stage login similar to
what many banks are doing, where they show you an image or a word that you
previously chose so that you can verify you're talking to the right server?

For example, when I log in to my bank I first enter my username. Then they
show me my secret word, and if I recognize it, I enter my password. This
gives me a chance to verify the server I'm logging in to really is my bank,
and not a third party intercepting my login attempt.

It seems that this would be a nice way to solve the security concern around
embedded user agents in mobile apps.

I realize this would not be part of the OAuth spec since this describes how
to sign in to the authorization server. But I'm curious if this would allow
native apps (especially mobile apps) to safely use an embedded browser to
complete the OAuth flow? Or is the general consensus that opening an
external browser is better because the user may already be signed in in
that session?

Aaron Parecki
Geoloqi.com

---

From: William Mills <[email-masked]>
Date: Tue, 6 Dec 2011 10:10:04 -0800 (PST)

An OAuth authentication server can implement that in the Web UI, no need to include it in the spec.

________________________________
 From: Aaron Parecki <[email-masked]>
To: OAuth WG <[email-masked]> 
Sent: Tuesday, December 6, 2011 9:42 AM
Subject: [OAUTH-WG] Preventing phishing attacks with auth server verification?

Has there been any discussion about supporting a 2-stage login similar to what many banks are doing, where they show you an image or a word that you previously chose so that you can verify you're talking to the right server?

For example, when I log in to my bank I first enter my username. Then they show me my secret word, and if I recognize it, I enter my password. This gives me a chance to verify the server I'm logging in to really is my bank, and not a third party intercepting my login attempt. 

It seems that this would be a nice way to solve the security concern around embedded user agents in mobile apps.

I realize this would not be part of the OAuth spec since this describes how to sign in to the authorization server. But I'm curious if this would allow native apps (especially mobile apps) to safely use an embedded browser to complete the OAuth flow? Or is the general consensus that opening an external browser is better because the user may already be signed in in that session?

Aaron Parecki
Geoloqi.com

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth