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

William Mills <> Tue, 06 December 2011 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4960721F8C06 for <>; Tue, 6 Dec 2011 10:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.548
X-Spam-Status: No, score=-17.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4BROYCYM6YxQ for <>; Tue, 6 Dec 2011 10:10:52 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 0D79C21F8BEF for <>; Tue, 6 Dec 2011 10:10:16 -0800 (PST)
Received: from [] by with NNFMP; 06 Dec 2011 18:10:05 -0000
Received: from [] by with NNFMP; 06 Dec 2011 18:10:05 -0000
Received: from [] by with NNFMP; 06 Dec 2011 18:10:05 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 69827 invoked by uid 60001); 6 Dec 2011 18:10:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1323195004; bh=2Eryy/G4RD2CCQ81JPIT7hpmtB4oOqJm2Kw9kQ5AfWs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YawlWB8YaJ+YJ0H1gx/eVPTsvH3jgDnwmL2HYCctcZwnkVUCznUjGPtkNmDFMRQFRdXVVih7o/RgwZX05VdXD3yfPGzJYf8qeAqxMphmCVoaKVj4SDrQ0YC8Ss+DiAr59+F1XUsm+GHZRsTkOxrQN5MkEgVyY9/JlU57tMHp7yE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rnccdIyfhgEG1J9EHACTQerRfVcBybL9BTJ7ETStzes1U4WtNExpNXPB07y7fcWWzD6PBIu6QbGF/iowveK7QjLFTy5Fy0y1ehYOXW+gOayGxLmK938OZkSK9Qz+2JXmrkyyoYWLccIR1QH65FBc/Hg3cehjU8ip2T7b6zcO4C8=;
X-YMail-OSG: gns_yWQVM1kG4dX53bpAX0eEfkLJ7f5G6tTscyJUWeR.mqv _c7iGfZa4OoSmaBBMtLk.SsCAb1wbzh_fnUMqDoBjt1TvS_kkLTI2j5mqqv_ 6HKCmZjja74oVn39eEN4LP6.L.RlixAWkvs.X01jf1yeuogikPiEwJt.NEm_ kqgc46zcVf4x2ZX1WBuzhuRelUSmr4kquRRaAgcbZg1HUCjshz9Uzvq.nrgb M.T4jbU6ewmpZzwHMOC7YlBJDU6AbBZhK81yrmkIOvpkiPPo4Wx.AMa6fnX7 15RVhnldI2wm7efD2dqHF63qlwrKIkAZmVw4qeAZqYQFmzaR5aG4yfChYXWT NLZqQiAIyz6aVQqdfGXarBJbIkNhMjzXSn1nBt6QGIGey49tcDl6Z7KUsUO_ 4OSHfVU8MMHuFfoWPcmc2Qa_CDNggs092T8c4msX3YE7i7hSXG6p9NFUa6YN hOdUPKlI-
Received: from [] by via HTTP; Tue, 06 Dec 2011 10:10:04 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Tue, 06 Dec 2011 10:10:04 -0800
From: William Mills <>
To: Aaron Parecki <>, OAuth WG <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1458549034-1924750945-1323195004=:74431"
Subject: Re: [OAUTH-WG] Preventing phishing attacks with auth server verification?
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Dec 2011 18:10:57 -0000

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

 From: Aaron Parecki <>
To: OAuth WG <> 
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

OAuth mailing list