This page examines the design of SQRL from the standpoint of its susceptibility and resistance to any form of attack by adversaries having any degree of access and knowledge of the system and user-specific secrets. We divide attacks into online information-based attacks, offline device attacks, and hybrid online/offline attacks.

The SQRL system's public key based cryptographic design provides its operational network security with strong resistance to attacks upon the user's secret private key, and cryptographic signatures using that key. It is believed that the system's “25519” elliptic curve cryptography provides no less than the equivalent of a 2¹⁴⁰ key strength. And while we believe that this renders the system extremely robust against attack, we'll note that the system's inherent use of per-site public key pairs means that even if it were possible to breach a user's security for one site, no information would be gained about the user's identity master key, nor about the keys used for identification and authentication on any other website.

The system's cryptographic design therefore appears to be extremely strong and highly resistant to fundamental breaches.

< to be written >
• Examine SQRL login-page security requirements and implications.
• Examine smartphone authentication link security requirements and implications.

As discussed on previous pages, the only known area where explicit attack resistance must be added is in the protection against offline brute-force password guessing attacks. Online password guessing will be quickly foreclosed by a local password lockout and identity master key erasure. Since user passwords are used in two places, we'll examine each in turn:

< to be written >

< to be written >

< to be written >
• Okay... not really an attack, but we need to address the consequences.

< to be written >
• It's clear how much damage could be done by any SQRL app that chose to betray its users.

< to be written >

• The Problem: Evil website obtains SQRL code from innocent site, presenting that to the user in place of the SQRL code for the Evil site. The unwitting user snaps the SQRL code without noticing that it's for a different website. Thus the Evil website, effectively impersonated the user to the innocent site and can authenticate as them.
• The Defense: The form of “phishing” attack arises because the domain name contained within the SQRL code is not immediately obvious. So a different domain name can be presented by the Evil site. This is why the user will always be clearly shown the domain name contained within the SQRL code and warned that they will be providing their login credentials for THAT website domain, not necessarily the one they are apparently logging in to.

(Taylor Hornby of defuse.ca foresaw this attack. Thanks Taylor!)

< to be written >
• Note: DNS spoofing / MITM

< to be written >

< to be written >
• Note: Proof-Of-Work

< to be written >
• What happens if someone snaps the SQRL code over one's shoulder?