How SQRL Can Thwart Phishing Attacks
Although the SQRL identity authentication login system does not promote itself as an anti-phishing solution, observers have hoped that, in addition to everything else it does, it might also be able to provide some relief from the classic and pervasive Internet worry over phishing. As it turns out, the SQRL authentication architecture does present significant opportunities for thwarting phishing attacks.
The Phishing / Man-In-The-Middle Problem
A “Man In The Middle” (MITM) exploit occurs when an attacker can somehow arrange to
interpose themselves between a web browsing user and the web server they believe they are contacting. The attacker becomes the “man in the middle”, able to eavesdrop and often intercept and alter the data passing back and forth between the user and the intercepted web site:
This typically occurs through a so-called “Phishing” attack, where a fraudulent — but very authentic appearing — eMail message induces an unwitting user to “click this link” to verify (for example) a Paypal transaction they have no knowledge of, approve the withdrawal of funds from their bank account (which they never made), etc. The fraudulent eMail link will direct the user to a website at a similar looking web address — perhaps paypol.com or paypal.cn — which will go unnoticed because everything else about the displayed page is absolutely correct.
The fraudulent “phishing” web site will ask the user to login by providing their username and password. But because the fraudulent site has interposed itself between the user and actual website, the user is unwittingly providing their confidential credentials to the attacking site. Since the attacking site has the user's confidential credentials it can then login as the user, impersonating the user, and transfer the user's funds wherever it wishes.
OAuth authentication (“login with Facebook”, “login with Twitter”) are equally prone to phishing exploits, and “six digit” multi-factor authentication systems, such time-based or one-time “Google Authenticator” style systems don't help in this situation because the malicious website can intercept and immediately use the time-based code before it has expired. Attackers are known to be doing this.
How SQRL changes things
When using SQRL, users do not identify and authenticate themselves with a username and password. Instead, their unique user identity is derived from their secret master key and the website's full domain name. Since SQRL generates a unique user identity for every web domain, the user's Internet identity for a look-alike phishing site such as paypol.com or paypal.cn, or anything
other than the authentic website the user believes they are visiting, would be useless to any attacker.
This means that the SQRL login link provided by a phishing site's otherwise fraudulent web page must be correct and authentic. In our example, it would have to be “paypal.com” because that domain name string is used in the generation of the identity by which Paypal knows the user. This means that the user's SQRL application will connect directly to the authentic website, rather than to the fraudulent phishing site:
The diagram above shows the SQRL Login Agent, its communication link, and the authentic web server in green to signify the significantly higher degree of trust and tamper-proof assurance that exists for this communication.
The SQRL system takes advantage of this stronger tamper-proofing and enhanced trust in three ways:
- Login Redirection
As we know, the user's web browser is not actually viewing the authentic web site. It is viewing a malicious copy of the authentic web site. In effect, it got off on the wrong foot by first visiting a spoofed web address. But as the diagram above shows, the SQRL login agent IS communicating directly with the authentic web site. So, if the authentic web site were to respond to the SQRL login agent with a correct link to the logged-in web session instead of logging in the fraudulent session which was initiated by user's browser, the SQRL login agent could follow the correct that link to safely login its user, thus bypassing and dropping the attempted and failed malicious login.
- Action Confirmation
Another way the authentic web server can take advantage of the SQRL login agent's direct connection to it is by sending confirmation requests for important actions back to the SQRL login agent rather than to the regular web session. If, for example, the malicious man-in-the-middle attempted to transfer money from the user's online account, but the user had logged in and authenticated using SQRL, the authentic web server could send a confirmation of this request NOT back to the user's web browser session (which may have been compromised) but instead to the SQRL login agent, thus bypassing any interference from the man in the middle. The user would receive a request to confirm an unexpected transaction and decline to approve it.
- Man In The Middle Detection
When the SQRL login agent resides on the same device (computer, tablet, mobile phone, etc.) as the user's web browser, both the web browser's web queries, and the SQRL login agent's login authentication queries, would share that machine's IP address. This is known as “same-device” SQRL login, and it provides another strong anti-phishing / anti-man-in-the-middle attack mitigation. As you can see in the diagram above, from the perspective of the authentic web server, fraudulent man-in-the-middle web queries will be received from the IP address of the MITM server — not from the user's web browser — but the user's SQRL login agent's queries will be received from the IP address of the SQRL login agent. When the authentic web server sees that those IPs are different, it will warn the SQRL login agent. If the SQRL agent expects that its queries should have the same IP as the user's web browser, it can warn the user and abort the login.
Details and Limitations of IP-based MITM detection
Although IP awareness is powerful and useful as an anti-phishing countermeasure and man-in-the-middle detector, it is not perfect. It can fail or be unavailable in the following scenarios:
- Cross-Device SQRL Authentication
We can only safely assume that the SQRL login agent and the user's browser will have the same IP address when they are operating within the same device; the so-called “same device” login mode. If a cellular phone uses an available local wireless network preferentially (for example in a residence or office), it might still have the same public IP address as the user, but this is less certain. However, when a smartphone uses cellular bandwidth to perform a cross-device login, it will have an IP address that's almost certainly unrelated to the user's browser. In this instance the remote web server would notify the SQRL login agent that its IP did not match the user's. Depending upon its user interface configuration, the SQRL agent might be expecting this when using cellular bandwidth and silently ignore the notice, or it might notify its user, which the user would also soon learn to expect in these situations.
The point, however, is that since an IP mismatch is expected in this situation, a man-in-the-middle attack, which would also present the expected “IP is different” status, would not be detectable in this fashion. Thus, any cross-device login where the SQRL login agent's IP is expected to be different from the user's browser won't provide us with man-in-the-middle protection.
- Multi-homed Cross-Device SQRL Authentication
It is at least possible, though unusual in the extreme, for a single device to emit outbound queries from different public IP addresses. If SQRL were used for same-device login in such a system, and if the SQRL login agent's IP differed from the user's browser, the result would be a false-positive warnings caused not by a man-in-the-middle attack, but by the normal operation of the system. In such an instance the SQRL login agent would need to have its IP detection warning disabled to prevent false positive warnings . . . and then, again, a true attack would go undetected.
- Nearby MITH Attacker
Man-in-the-middle attackers tend to be located anywhere other than in the next room on the same local area network. Such attacks are typically launched from another country. But because it's possible it needs to be addressed. If someone on the same local area network were to arrange some form of man-in-the-middle attack its malicious server would then have the same IP address as the user's SQRL login query so no cautionary warning flag about differing IP addresses would be raised in this case. Thus, a man-in-the-middle attacker who was somehow sharing the same public IP as the user would not be detected.
- ISP Carrier-Grade NAT
A slight variation on the “local attacker” scenario above, is one where multiple customers of a single Internet Service Provider (ISP) receive the same IP address. This broadens the definition of “local” somewhat since several different customers of the same ISP would present the same public IP address. Due to the approaching starvation of 32-bit IP Version 4 addresses, ISPs are beginning to deploy Network Address Translation (NAT) within their own fabrics. This so-called “Carrier Grade Nat” (CGN) typically allocates one IP address to up to eight customers, thus allowing the ISP to grow their customer base eight times larger than they otherwise could if every customer required their own public IP address. It's not immediately clear how one ISP customer could intercept the ISP-network traffic of another to establish a man-in-the-middle position, and it may not be possible. But since our goal here is to completely examine the tradeoffs inherent in IP-based man-in-the-middle detection, it needed to be mentioned.
- IPv6 and per-machine IPs
If the long-awaited Internet Protocol Version 6 ever actually happens, the world might someday return to the configuration originally envisioned by the Internet's designers: Where every “Internet Endpoint” (device of any kind) is uniquely identified by its own IP address. For what it's worth, this would be good for SQRL's IP awareness, since then, unlike today, large clusters of nearby devices would not all be sharing one overloaded 32-bit IPv4 address, nor would ISPs be clumping their customers into bundles of shared IP addresses.
The discussion presented above probably establishes sufficient background and details for understanding the features and tradeoffs inherent in IP address-based man-in-the-middle attack detection and mitigation. However, if you are interested in more, the discussion below assumes no knowledge of the subject, approaches it from more of an implementation direction, and also provides additional details.
Examining MITM Attacks More Closely
It's worth first pointing out that the presence of the SQRL login system inherently escalates the complexity of traditional passive phishing attacks. In fact, passive attacks no longer work:
A traditional phishing attack presents the unsuspecting user with a spoofed login page that mimics the authentic web page they expect to see. The user enters their personal credentials, typically a username and password, and clicks “Log me in.” In that instant the phishing site receives their valid credentials for the authentic site and can then impersonate them until the user's credentials are changed. Since the SQRL system uniquely identifies its user and authenticates based upon the domain name in the SQRL link, if the spoofed web site were to use its own domain name, the SQRL client would generate a new identity that would not match the identity used with the authentic web site. And if the spoofed web site were to use the authentic web site's domain, the spoofed site would not receive the user's identity and authentication information because the user's SQRL client would connect to and provide that information to the authentic web site server . . . not to the phishing site.
However, phishing sites might still attempt to mount “SQRL-aware” attacks:
How a “SQRL-aware” phishing attack would be mounted
SQRL significantly complicates phishing by forcing the attack to be active rather than passive. To mount a phishing attack against SQRL, a fraudulent website would need to first open a valid login session with the authentic website it plans to spoof. From the valid site's login page it would obtain a “fresh” and valid SQRL link URL. The fraudulent site would then present a spoofed login page containing the authentic website's valid SQRL code. When the SQRL application is used to login, they are actually logging in to the session that was originally initiated by the phishing site. The phishing site then completes the login and can impersonate the user for that login session.
Although this is not good, the SQRL system did require much more SQRL-specific work on the part of the phishing site, and the use of SQRL completely prevented the phishing site from obtaining any reusable login credentials. Whereas traditional passive phishing attacks obtain the user's reusable username and password, the active SQRL attack only obtains one logged in session . . . Or does it??
How SQRL can detect and prevent many phishing attacks
You will note two things about the description of the active SQRL phishing attack described above:
- The phishing web site was required to initiated a login session in order for it to obtain a SQRL link URL that it then passed on to the victim. In doing so, the authentic web site sent the SQRL link URL to the phishing site's web server, at the phishing site's IP address. There's no way around that.
- When the victim logs into the authentic web site using the link contained in the valid SQRL URL obtained by the phishing site, the victim's SQRL application connects to the authentic web site from the victim's IP address to provide the victim's identity and authentication.
As we know, SQRL can be used to log in either “same-machine” or “cross-machine.” When performing a same-machine login, the IP address requesting the SQRL link URL (where the logging in user is located) should always exactly match the IP address which then, several seconds later, is used to send the web server the user's login identity and authentication. If ever the two IP addresses do not match, there is very good reason to suspect the intervention of a malicious third party.
When the SQRL authentication client is located on the machine being logged in, the IP address of the original SQRL link URL request should be identical to the IP address of the SQRL client's authentication query. |
As explained further on the Implementation Details page, all SQRL login servers record the IP address to which any SQRL link URL is sent. This is typically embedded into the externally opaque and unpredictable token that the SQRL client cryptographically signs and returns. This allows for an on-the-spot comparison of the original requesting IP with the subsequent authenticating IP at the time of possible authentication. The SQRL client's “enforce” option, when present, will cause the web server to fail any login attempt whose original and subsequent IP addresses are not identical . . . thereby preventing successful SQRL phishing attacks.
Where this is effective?
This means that phishing attacks can be practically and automatically detected and prevented when the logging-in browser and the SQRL client are known to have the same IP address. This applies in all same-machine logins, as well as any logins where a smartphone is used in a cross-machine optical QR code scan login and the smartphone is networked using the same local area network as the logging in machine.
Where this cannot help:
Since this anti-phishing countermeasure depends upon an unexpected IP mismatch, it cannot help in any situations where an IP mismatch is expected. Smartphones using a cellular carrier's network will certainly have a different public IP address than another machine when they are being used to optically scan and cross-machine login. Although, once again, when a smartphone is logging in with their own web browser, that's again a same-machine login and full phishing protection can be provided.
This means that SQRL login can offer quite robust anti-phishing countermeasures when it is being used to locally (same-machine) login to a smartphone, tablet, laptop or desktop, and also when a smartphone is being used for optical QR scan cross-machine login where the smartphone is using the same network as the logging in machine.
How is this practically implemented?
The beauty of this solution is that the SQRL client application can ask the authenticating website for IP-match enforcement, and it can almost always determine when its SQRL-authenticating query should be seen by the remote website at the same IP address as the machine being logged in. For example, all non-mobile SQRL clients on laptops and desktops, and all non-optical scan smartphone and tablet logins, would always expect IP-match, since the client is running on the same machine as the web browser, thus the same IP.
Each SQRL client authentication query can include an option to request the website to enforce the same-IP policy upon the login. If the authenticating web server receives that option in the authentication query, and the IP that originally requested the SQRL link URL differs from the IP of the authenticating query, the authenticating web site will fail the authentication and inform the SQRL client of the reason. This allows the SQRL client to govern when the same IP-policy should be enforced, and also allows a user to gracefully bypass the policy when the user is sure that everything is okay.
| Same- Machine | Cross- Machine | Client on Same Net | Client on Different Net |
1. | X | | X | |
2. | | X | X | |
3. | | X | | X |
1. | If you imagine a future where SQRL login is widely available, you will predominantly be logging into web sites from your main workstation computer at home and at work. Your smartphone will have the same master identity key installed in it so that you can conveniently and securely login to your sites wherever you are, but for the most part your laptop, desktop, or tablet client will likely receive the most use. In that model, the SQRL client will always be able to safely request same-IP policy enforcement and consequently all of those login will receive strong anti-phishing protection. |
2. | If you wish to leverage the added security of cross-device login using any connected device with a camera, and when that device can be on the same network as your computer ‑ such as at home or in an open WiFi environment ‑ your connected, camera-enabled device could still request the enforcement of same-IP policy and you could make exceptions after being warned that the device is attempting to authenticate from a different network than your computer. |
3. | Since a cellular-connected, camera-enabled device can be expected to have a different IP than any cross-device computer you're logging into, the SQRL client will usually be configured not to request any same-IP enforcement from the remote web server. In this instance, same-IP policy driven phishing detection countermeasures will not be available so the user will need to be vigilant about the sites being logged into in these cross-device circumstances. |