SQRL Attack Analysis and Mitigation Status
In considering an attack against SQRL their are Three communication channels available:-
- A) The Browser/Server channel
- B) The SQRL-Client/Server channel
- C) The Browser/SQRL-Client Channel
We consider here the following attacker gains:-
- 1) Session Theft
- 2) Site Credential Theft
- 3) SQRL Association to attackers Site credentials
- 4) Master Key theft
- 5) Removal of pseudonymous nature of SQRL authentication
- 6) Introduction of malware
|Attack Name||Vector||Target||Gain||Defence||Defence Status||Support Status||Ext. Discussion Links||Lead||Int. Discussion Link||Notes||Reference|
|Phishing Link||Link to SQRL Auth' clone||Session Theft||Single Attacker Authenticated Session||Client display of SQRL Domain||Documented||N/A|
|Evil Router||Local network DNS/TLS compromise||Session Theft||Single Attacker Authenticated Session||No Defence||Documented||N/A|
|Over Shoulder Capture||Optical Use of SQRL by attacker||User Info||Single User Authenticated Session||Double request detection||Discussed||N/A|
|Undetected MK Clone||Malware / Temp' Loss||Master Key Theft||Identity Theft||Scrypt at 1s/60s per guess||Documented||N/A|
|DNS Poisoning||Malware / unauthorized device access||Connection hijacking / Phishing||Single Attacker Authenticated Session||Cross-device login||Discussed||N/A|
|Possible MK Clone||Loss of device||Master Key||Identity Theft||Scrypt at 1s/60s per guess, ID-lock||Documented||N/A|
|Evil Client||Look alike App||Master Key||Identity Theft||App certification, Reference App ...||Discussed||N/A|
|Persistent Server Compromise||Multiple||Database / MITS*(a)||SPuK,PuUK,KV*(b)||Does not allow front end authentication but access unwise||Discussed||N/A|
|Exfiltration||SQL Injection||Database Tables||SPuK,PuUK,KV*(b)||Does not allow front end authentication, New keys not required||http://www.GRC.com/groups/sqrl:3295|
|Dummy Account||MITM Switch of spk,sig||user on account not under their control||User Observance||Weak||Example||Example||Example||Example||Example||Example|
|CPU Flooding||Malware||EnScrypt||Weaker protections against Master Password cracking||Example||Example||Example||Example||Example||Example||Example|
Links to further Attack scenario to be considered for above:-
http://www.GRC.com/groups/sqrl:3365 - Example of De-Anonymise Attack
a) MITS => Man In The Server
b) SPuK - Site Public Key, PuUK - (ID-Lock) Public Unlock Key, KV - (ID-Lock) Agreed Key Verifier
Notes added for inclusion above:
NB: These all require an undetected breach of the secure authenticated connections, either in TLS or Optically. Plus in a), b) & possibly c) a compromise in local DNS resolution.
- a) Credential Replacement Attack:*
During the action of registering SQRL as an authentication method on client<>server channel it is possible for a MITM attacker to strip all the signatures and public keys and replace them with ones generated by the attacker. To be undetected by the client and user it is also required that the attacker detect and drop all MITM attacks should the response from the server be that the user has an existing attack. The attacker also must alter the TIF bits returned by the server to the client (e.g. to mask expected same origin IP) and then alter them back in the clients next query.
The result is that the users current session is inviolate but the SQRL credential needed for later login belong to the attacker, who should probably make best use of them quickly and then use the Recovery Key processes to remove the SQRL authentication from the account to mask their actions e.g.
If the target was a bank, they could set up a small denomination regular standing-order, direct-transfer to an innocuously named third party (with introspection of the diversity of the captured account) in the expectation that it will go unnoticed.
If say the attacker limited themselves to $7.95 per month per breach and we have an online banking population of ~100 million (http://www.pewinternet.org/2013/08/07/51-of-u-s-adults-bank-online/) then even with a 1% breach the attacker nets ~$8M per month.
- b) Substitute Account Attack:*
During normal authentication method on client<>server channel this is similar to a) but since the user has an expectation that they already have an account and the server responds with TIF values supporting this they attacker can only replace the signatures and keys with ones known to the server which would not represent the users existing account.
Because of the nature of how online accounts collect meta-data and become unique to their users, this attack is limited to either spear-phishing or low meta-data accounts to fool the user into assisting in an eventual identity theft.
- c) Session Theft Attack:*
At all times in the server<>browser channel is possible should the site use a session authentication mechanism that present or is triggered by the authentication page of the website.
The result would be the attacker logged into the users account for that specific session, able to see and modify anything that does not require additional authentication (modifying or removing SQRL as an authentication means for example)
- d) Optical Shoulder Surfer Attack:*
At all times in the browser display of the SQRL-QR code this is expected to be a hyper-local attack similar to b) in its result but using the fact that the SQRL-Link is displayed to the user in an optically readable way.