Phishing Link

From SQRLauth.net
Jump to: navigation, search

Phishing Links

This is a well-known attack mode where a user is invited to click on a link that opens to a login dialogue which does not come directly from the indicated source, but is actively tunnelled via the attacker's server.

Generally, the user is fooled with a look-alike link. The hacker may have registered paypaI.com instead of paypal.com, relying on the similarity in appearance between the lowercase "L" and the uppercase "I." Another historical example is tvvitter.com, which on casual reading looks very similar to twitter.com.

Another method is to use a malformed URL to misdirect a user. For example, the link:

at first glance might appear to be a link to Amazon.com, but in reality takes the user to GRC.com. Instead of GRC.com, the hacker would just substitute the name of his phishing website and most users might be fooled entirely.

Since SQRL uses the domain name as the basis for authentication, this would not work. SQRL is not fooled by visual tricks or bad URL formatting. If the SQRL client displays the proper URL (GRC.com in this case), the user will have the opportunity to realize he isn't authenticating to the website he thinks he is; even if the user is fooled, the identity the SQRL client uses to authenticate to the server will be the one generated for GRC.com and have nothing to do with the user's identity for Amazon.com. So the problem of phishing sites capturing passwords will be irrelevant, although the hacker could attempt to get the user to type in other sensitive information such as a credit card number.

Many phishing attacks today are now pass-through attacks, where the phishing site acts as an active Man-In-The-Middle (MITM), visiting the website and showing the pages to the user, and passing along the user's clicks and form fills. Not only could the hacker obtain the user's password, this method also foils MFA such as requiring a 6-digit code, either texted to the user or generated by a time-based authenticator, since the user enters the code on the phishing site, which simply passes it on to the website.

In such a scenario, when the SQRL link is clicked to use a SQRL client on the same device, SQRL's same-IP enforcement will defeat the attack: the website's SQRL server will see the response from the client come in on a different IP address than the one that requested the page (i.e., the phishing site), and advise the client of an IP mismatch. The client, knowing that the link was clicked and therefore should have been on the same IP address, will fail the authentication attempt and alert the user.

A user scanning the QR code might be defeated in such a manner, since the SQRL client will in such a case expect the IP mismatch, but generally this is only done when a computer is untrusted, in which case the user is more likely to type in the website directly instead of clicking a link. In this case the user would only be fooled if the hacker also engaged in DNS Poisoning on the untrusted machine. Such an event would fool every other known authentication method as well.