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.
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:
- The user believes that he is accessing good.com (where he already has an account), but is actually sent to bad.com. He may have clicked a link from the attacker, or just made a mistake when typing the address.
- Bad.com mimics good.com, so that to the user, it looks exactly like good.com (except for the address bar).
- The user doesn't notice anything wrong, so he logs in, sending his credentials to bad.com.
- Bad.com 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 good.com. The user continues his session, thinking the whole time that he's using the real good.com.
- Bad.com can now sign in and use the user's good.com account whenever they wish.
SQRL authentication takes place outside the context of the browser session, which automatically makes phishing more difficult. Bad.com has two options:
- Generate a new QR code pointing to bad.com. If the user logs in with this code, SQRL will send completely different credentials than it would have for good.com (because of the different domain name). This doesn't help bad.com access the user's account, so he has to:
- Show the user an original QR code from good.com. SQRL authenticates with good.com, and bad.com never sees the user's credentials. When the user SQRLs good.com, though, they are actually authenticating a session that bad.com started and controls, so bad.com 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 bad.com'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.