Attack-Analysis

From SQRLauth.net
Revision as of 11:46, 13 February 2016 by Ramriot (Talk | contribs)

Jump to: navigation, search

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


Attackers have the following potential avenues of attack:-

  • 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 to active spoof site User Account Single Attacker Authenticated Session Client display of SQRL Domain Documented N/A
Over Shoulder Capture Optical Use of SQRL by attacker User Info Single User Authenticated Session Double request detection Discussed N/A
Panopticon MITM http://www.GRC.com/groups/sqrl:2859
Undetected MK Clone Malware / Temp' Loss Master Key Identity Theft Scrypt at 1s/60s per guess Documented 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
Example Example Example Example Example Example Example Example Example Example Example Example

Links to further Attack scenario to be considered for above:-

http://www.GRC.com/groups/sqrl:3264

http://www.GRC.com/groups/sqrl:3311 - Attacker Motivations and Capabilities

http://www.GRC.com/groups/sqrl:3365 - Example of De-Anonymise Attack

Key:-

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:

  • Attacks*

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.