Jump to: navigation, search

Many variations of phishing attacks have been discussed in the newsgroup... Some of those are described here, along with how SQRL can mitigate them (or not).



For the purpose of this discussion:

the activity of defrauding an online account holder of sensitive information by posing as a legitimate company.

Most of the discussion in the newsgroup about Man in the Middle (MitM), and website spoofing are referring to various types of phishing.

Traditional Phishing

In a traditional phishing attack, the attacker gains access to a user's account credentials in the by creating a spoofed copy of a website and tricking a user (probably by some "social engineering") into using that copy instead of the real site. It works something like this:

  1. The user believes that he is accessing (where he already has an account), but is actually sent to He may have clicked a link from the attacker, or just made a mistake when typing the address.
  2. mimics, so that to the user, it looks exactly like (except for the address bar).
  3. The user doesn't notice anything wrong, so he logs in, sending his credentials to
  4. can either:
    • take the user's credentials and run. The user wouldn't know what happened, just that his login didn't work right for some reason.
    • proxy the user's requests to The user continues his session, thinking the whole time that he's using the real
  5. can now sign in and use the user's account whenever they wish.

SQRL Phishing

SQRL authentication takes place outside the context of the browser session, which automatically makes phishing more difficult. has two options:

  • Generate a new QR code pointing to If the user logs in with this code, SQRL will send completely different credentials than it would have for (because of the different domain name). This doesn't help access the user's account, so he has to:
  • Show the user an original QR code from SQRL authenticates with, and never sees the user's credentials. When the user SQRLs, though, they are actually authenticating a session that started and controls, so has full access to the user's account for that session only.

So, phishing is still possible with SQRL, but the attacker only gets access to the current session, not future ones. SQRL still has another trick up it's sleeve, though. The IP address of the original request is embedded in the QR code. In the case of a phishing attack, this would be's IP address. If the IP of the web session and the SQRL authentication don't match, the login can be rejected. This effectively eliminates the problem when the user is logging on from a trusted machine.

If the user is using a cross-machine logon, where they are actually scanning the QR code with their phone, the phone's IP is likely different than the computer's, so in that particular case, there is some vulnerability, and the user must still ensure that they are accessing the correct web site before completing the log in.