Jeffrey Paul: sneak's Law

Jeffrey Paul

sneak's Law
22 October 2018

sneak’s Law

Since at least 2013 I’ve been repeating something I’ve come to call “sneak’s law” (Stigler’s law of eponymy notwithstanding):

Users can not and will not securely manage* key material.

* == { generate, store, backup, transmit, authenticate }

Even users that can, such as you and I, don’t do such things: when was the last time you verified someone’s “safety number” (key fingerprint) on Signal? When was the last time you verified a PGP fingerprint that wasn’t at a signing party, or actually used the web-of-trust?

…and you’re the minority, the tiny fraction that knows that you should be authenticating keys. The vast majority don’t even know that they should. It just ain’t gonna happen.

Real World Examples

Today I came across and old blog post from Ted Dziuba advocating for doing this very thing (avoiding the authentication of keys in the service of getting work done). Here’s a textbook example of someone who knows very well why it’s important deprioritizing key authentication in service of practicality.

What This Means

  1. Your users will not back up their keys.
    • Their keys will be lost unless you back them up.
  2. Your users will lose their passwords.
    • If their keys are derived from their passwords, their keys will be lost.
    • If their key backups on the server are encrypted with their passwords, their keys will be lost.
  3. Your users will ignore warnings about key rotation/MITM.
    • …they’ll just click OK.
    • …even if it’s a “Do you want to add this untrusted CA?” dialog.
  4. Your users will not validate that the application they are running was signed by the right key.
  5. Your users won’t notice or care what the address bar says. Ever.
  6. Your users won’t ever use a displayed fingerprint.
    • …even if you rename it to a “safety number”.

Light At The End Of The Tunnel

Pretty much everyone carries around an HSM now. You can’t trust users to store keys long-term, but you can trust that if you give them a client certificate, they will have it for as long as they have their phone (that specific phone, that is), and they probably won’t be able to figure out how to get it out of their phone. If they have an iPhone, malware authors probably won’t be able to figure out how to get it out of their phone either.

There still need to be other backup authentication mechanisms for when they drop their phone in the toilet or out of a taxi (because not everyone is like you and I and has 3 phones), but this is at least a starting point for the day to day elimination of passwords and stupid abominations like JWT.

See Also

About The Author

Jeffrey Paul is a hacker and security researcher living in Berlin and the founder of EEQJ, a consulting and research organization.

@sneakdotberlin

@eeqj

sneak@sneak.berlin

keybase.io/sneak

linkedin.com/in/jeffreypauleeqj