I gave a talk at the BSides Austin conference yesterday. We looked at a number of authentication factors and did some threat modeling, with the attendees helping me to estimate the attack potential necessary to exploit certain vulnerabilities by voting on pre-defined adversary types. This included taking a look at how Steve Gibson’s SQRL scheme works, possibly the most interesting part of the talk to many. 😉
The slides are available on Google Drive.
To those of you who actually attended and participated in the online survey, thanks for humoring me!! Next time I include audience polls in a presentation, I shall figure out how to present the results in real time. But for now, below are the results of yesterday’s poll. (Including those for the backup slides we didn’t get to but that a fair number of you filled out anyway.)
Those of you just tuning in, please don’t take these results out of context. We made a number of assumptions during the talk that aren’t properly represented below. (But you can find most of them in the slides.) Also, these votes are best guesses by a small number of InfoSec professionals that aren’t necessarily all experts in those particular exploit types. (Although some might be. ;-))
There were some surprising results (to me), maybe based on misunderstandings, but maybe you guys just know better than I do. The two that stood out to me most were:
- Five votes for it taking the resources of a nation state-sponsored type of adversary to get a smartphone-based TOTP token to generate one-time passwords valid in the future by setting the system clock to a future time. All that takes is (physical?) access to the phone — it’s the one exploit even I was able to reproduce within minutes. Admittedly, if the phone is locked, you’ll have to get around the locking mechanism as well.
- Seven votes for criminal organizations likely being able to make advances against well-known crypto algorithms in order to reduce the effort for brute force guessing attempts. In general it might just take a brilliant mathematician or cryptanalyst to pull this off, but doing it in a dedicated fashion for a particular algorithm in pursuit of a user’s account I personally imagine to be much harder.
The graphs below represent number of votes (on the y axis) for a given threat model from the slides (on the x axis).
(1) Passwords
Type of adversary necessary to succeed in (x axis):
1: social engineering (user)
2: social engineering (password reset)
3: theft of database (brute force guessing)
4: theft of database (improperly hashed)
5: keyboard logger
(2) Shared Secret- & Time-Based One-Time Passwords (soft & hardware)
Type of adversary necessary to succeed in (x axis):
1: weak RNG exploitation
2: cryptanalysis reduces brute force effort
3: (crypt)analysis of proprietary algorithms
4: extracting master key from HSM
(3) OTP tokens continued…
Type of adversary necessary to succeed in (x axis):
1: extract key from phone (remotely)
2: generate future time-based values
3: physical reversal of hardware
4: non-invasive analysis of hardware
5: malware-channeling of OTPs
6: Write-in: extract key from phone (physical access)
(4) Steve Gibson’s SQRL
There weren’t any threat vectors we hadn’t voted on already.
1: Exploiting the smart phone OS to extract master key from memory — see (3)(1) above…
2: Weakening the particular elliptic curve or ECC in general — see (2)(2) above…
(Backup A) SMS / text message-based OTPs
Type of adversary necessary to succeed in (x axis):
1: base station spoofing
2: core network wiretap
3: sales agent social engineering
4: SIM cloning
5: lawful interception
6: phone / SIM theft
(Backup B) Public Key Tokens
Type of adversary necessary to succeed in (x axis):
1: malware on client OS
2: reader firmware replacement
secuilibrium.com 