Derek Atkins wrote: > And how does one know that the authentication server URL is "the right" > URL and not, say, a MitM/Fishing attack?
It's addressed at length: https://www.grc.com/sqrl/phishing.htm In summary, there are several measures to combat several different attack scenarios: -one is that the key sent is based on the domain used in the URL. So if an attacker uses a look-alike (slight misspelling) domain, they'll get a key that isn't usable with the real site. The authentication app will also connect to the wrong end-point (though the attacker could proxy the connection). -the domain in the URL is shown to the user for verification before the key is sent to the authentication web service. -there are optional modes where it may be required that the browser and the authentication app both connect from the same IP. -the communication channel with the authentication app serves as an "out of band" channel that can optionally be used to verify high risk operations, such as when making a transfer between banks. If the attacker has the ability to alter the DNS responses the user sees, and forge SSL certs for the site and authentication service, then they still might be able to pull off a MitM attack. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA "Predictable On-demand Perl Consulting." http://www.theperlshop.com/ _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss