Slide 1

Slide 1 text

Simple is Hard: Making your awesome [security] thing usable GrowClovyr AmberBaldet pmylund (Patrick Nielsen)

Slide 2

Slide 2 text

Obligatory disclaimer ● Everything we’re about to talk about (except one thing, which will be obvious) is awesome. It all deserves your attention and use. ● Everyone mentioned has contributed substantially to our collective technological health. ● These slides contain hyperbole for effect. ● A lot of these comments are just, like, our opinion, man.

Slide 3

Slide 3 text

1 Developer experience matters

Slide 4

Slide 4 text

Argon2 Who has heard of it?

Slide 5

Slide 5 text

Argon2 Who has used of it?

Slide 6

Slide 6 text

The Password Hashing Competition (PHC) ● Contest like the one NIST ran to select SHA-3 (Keccak) ● Objective: Select the new de facto password hashing algorithm to replace md5crypt, PBKDF2 and others ● Ran from 2013 - 2015 ● Participation by some familiar names: ○ Jean-Philippe Aumasson / @veorq (organizer) ○ Tony Arcieri / @bascule ○ Matthew Green / @matthew_d_green ○ Zooko Wilcox-O’Hearn / @zooko

Slide 7

Slide 7 text

Argon2 ● Winner of the Password Hashing Competition ● Designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich at the University of Luxembourg ● Memory- and CPU-hard: scrypt on steroids ● Multiple variants: Argon2i (timing-attack-resistant), Argon2d (GPU-attack-resistant), and later a combination Argon2id

Slide 8

Slide 8 text

Argon2 ● Winner of the Password Hashing Competition ● Designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich at the University of Luxembourg ● Memory- and CPU-hard: scrypt on steroids ● Multiple variants: Argon2i (timing-attack-resistant), Argon2d (GPU-attack-resistant), and later a combination Argon2id An impressive feat of research and engineering!

Slide 9

Slide 9 text

Argon2 ● Winner of the Password Hashing Competition ● Designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich at the University of Luxembourg ● Memory- and CPU-hard: scrypt on steroids ● Multiple variants: Argon2i (timing-attack-resistant), Argon2d (GPU-attack-resistant), and later a combination Argon2id It should be the standard for password authentication...

Slide 10

Slide 10 text

*record scratch*

Slide 11

Slide 11 text

bcrypt Who has heard of it?

Slide 12

Slide 12 text

bcrypt Who has used of it?

Slide 13

Slide 13 text

bcrypt ● Paper published in 1999 by Niels Provos and David Mazières ● Posited “Hey, this Blowfish cipher Bruce Schneier made costs 4KB of memory to set up -- we can use that negative as a good thing” (sound familiar?) ● You may know David Mazières as the author of the Stellar Consensus Protocol

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

If Argon2 is better, why aren’t people using it?

Slide 16

Slide 16 text

The Specifications Argon2 ( password (P) salt (S) parallelism (p) tagLength (T) memorySizeKB (m) iterations (t) version (v) key (K) associatedData (X) hashType (y): (0=Argon2d, 1=Argon2i, 2=Argon2id) ) -> tag: Bytes (tagLength) “Argon2 has two types of inputs: primary inputs and secondary inputs, or parameters. Primary inputs are message P and nonce S, which are password and salt, ..." bcrypt ( cost salt password ) -> “$2a$cost$salt.passwordDigest” Argon2 Paper bcrypt paper

Slide 17

Slide 17 text

The Libraries // Argon2 // Totally unnecessary, very common mistake salt := []byte("secure salt!") // Initial generation // TODO: What are all these numbers? hashed := argon2.IDKey([]byte("some password"), salt, 1, 64*1024, 4, 32) fmt.Println(string(hashed)) // -> M���p�E'��ʿ��r��#ϷJb�x��ȕ�g (wat.jpg) // Comparison ohashed := argon2.IDKey([]byte("some password"), salt, 1, 64*1024, 4, 32) // Here I should probably use a constant time comparison // function even though the output is supposed to be a random // oracle -- but why would I know that? if bytes.Compare(hashed, ohashed) != 0 { return errors.New("It doesn't match!") } // It's up to me to implement a scheme that saves the settings // (all those numbers above and the salt) so that I can even // do a comparison in the future, and that scheme won't work // with any other Argon2 library! return nil // bcrypt // Initial generation hashed, err := bcrypt.GenerateFromPassword([]byte("some password"), bcrypt.DefaultCost) if err != nil { return err } fmt.Println(string(hashed)) // -> $2a$10$ZwRml0Qx2TKwN2AKW3HQ1eB6dpFRe.RlUcuyG0WA91dVbCmlDbqNC // The output includes bcrypt's settings and salt: // $2a$ = "this is bcrypt" // 10 = "the cost is 10" (bcrypt.DefaultCost) // ZwRml0Qx2TKwN2AKW3HQ1eB6dpFRe = auto-generated salt // RlUcuyG0WA91dVbCmlDbqNC = the digest // // This scheme is uniform across all bcrypt implementations // Comparison err = bcrypt.CompareHashAndPassword(hashed, []byte("some password")) if err != nil { return errors.New("It doesn't match!") } return nil

Slide 18

Slide 18 text

Argon2 is “better” but it’s impossible to say “Use Argon2”

Slide 19

Slide 19 text

Argon2 is “better” because only bcrypt is portable and usable by design but it’s impossible to say “Use Argon2”

Slide 20

Slide 20 text

Argon2 is “better” because only bcrypt is portable and usable by design but it’s impossible to say “Use Argon2” ...so really only bcrypt matters.

Slide 21

Slide 21 text

Cloud-yelling interlude Date: Tue, 19 Feb 2013 01:42:42 +0100 From: Patrick Mylund Nielsen To: "[email protected]" Subject: Re: [PHC] Any "large verifiers" on the panel? … At the end of the day, I think the point I'm trying to get across is: Developers want libraries like py-bcrypt that they can import, run phc(pwd) and save the result. If it uses another secret, they will put it in a config file or hard-code it in the application without any special ACL/privilege separation. Also, there is a good chance that vulnerabilities on the machine or the network provides a way to access the files on the machine, or at least the database containing the digests. If we make other assumptions then we risk developers not using the construction over bcrypt because it is too much work (a major contributor to why bcrypt is fairly popular today vs. PBKDF2/scrypt for password authentication, IMHO), or worse, hurting the end users more than they would have been if their provider had used bcrypt. (Yeah, you could argue that "the developers should have known better, and spent more time on it", or "The users should have chosen stronger and unique passwords." Of course, that's not the world we live in...)

Slide 22

Slide 22 text

● Protocol designers decide how people implement libraries based on their work ● The distance between interfaces is remarkably small ● Presenting Argon2 in the same way as bcrypt would have required less than one day of work This is the work that decides if your research will matter. “Usability work is trivial and boring, not interesting like research.” STOCK PHOTO STOCK PHOTO

Slide 23

Slide 23 text

2 User experience matters

Slide 24

Slide 24 text

Convergence ● Designed by Moxie Marlinspike ● Based on the Perspectives project from Carnegie Mellon ● Instead of trusting 600+ companies to issue certs for any domain, we choose who we trust ● Users individually choose to trust only a handful of validators ● The user’s trusted validators attest to the validity of certificates on the sites they visit ● The user can avoid fully trusting one validator by requiring a quorum (sound familiar?) ● I remember sitting in the audience thinking, “I’m watching history” Let’s decentralize the PKI CA system!

Slide 25

Slide 25 text

*record scratch*

Slide 26

Slide 26 text

Why not Convergence? (07 Sep 2011), Adam Langley, Google/Chrome Security: In light of recent events, I've had several requests to implement Convergence in Chrome. ... Moxie, having actually thought about the issue and coded something up, has already done a thousand times more to address the problem than almost anyone else. But I don't think that Convergence is something we would add in Chrome: Although the idea of trust agility is great, 99.99% of Chrome users would never change the default settings. (The percentage is not an exaggeration.) Indeed, I don't believe that an option for setting custom notaries would even meet the standards for inclusion in the preferences UI. Given that essentially the whole population of Chrome users would use the default notary settings, those notaries will get a large amount of traffic. Also, we have a very strong interest for the notaries to function, otherwise Chrome stops working. Combined, that means that Google would end up running the notaries. So the design boils down to Chrome phoning home for certificate validation. That has both unacceptable privacy implications and very high uptime requirements for the notary service. So why aren’t we using it? user impact commercial impact

Slide 27

Slide 27 text

● Started by Eric Rescorla and Josh Aas at Mozilla and Peter Eckersley at EFF ● Set out to improve the CA system from within ● “Hey, the barrier to entry to getting a certificate is way too high. It’s costly and complicated.” ● (IETF TLS WG) “We want the default to be resistance to dragnet surveillance” ● Uses Certificate Transparency to publish an immutable audit log of all certificates signed (sound familiar?) ● Developer story: If you can listen publicly on port 80, you can do HTTPS for free ● This allowed others to provide their own amazing dev stories Let’s Encrypt GA release

Slide 28

Slide 28 text

If the caddy binary has permission to bind to low ports and your domain name's DNS records point to the machine you're on: caddy -host example.com This command serves static files from the current directory over HTTPS. Certificates are automatically obtained and renewed for you! Caddy is also automatically configuring ports 80 and 443 for you, and redirecting HTTP to HTTPS. Cool, huh? With CertMagic, you can add one line to your Go application to serve securely over TLS, without ever having to touch certificates. Instead of: http.ListenAndServe(":80", mux) Use CertMagic: certmagic.HTTPS("example.com", mux)

Slide 29

Slide 29 text

Go for background wins ● The user simply does not care about the things you care about ● They don’t change defaults ● They don’t come for decentralization ● They don’t come for privacy ● They don’t come for anything but the experience, the content, and the other users ● LetsEncrypt succeeded mostly with relationships (to become a CA), and a great developer story ● At no point did a user behind a browser need to do anything at all ● People benefited because the choices were made for them ● Great developer stories have a multiplier effect

Slide 30

Slide 30 text

Signal Instant messaging apps ● Designed by Moxie Marlinspike and Trevor Perrin ● A very secure instant messaging application ● The Noise Protocol Framework lets developers build similar applications ● Uses a phone number for authentication ● Large group chats aren’t well-supported ● No in-line gifs Telegram ● Founded by VKontakte’s Pavel Durov ● Technically a mess; invented its own crypto ● Shunned by virtually all cryptographers and infosec people ● Doesn’t use a phone number for authentication ● Group chats scale very well because they’re not encrypted ● In-line gifs inline gifs added Nov 2018

Slide 31

Slide 31 text

“[Telegram’s] general security model [is] of permanently storing all contacts, messages and media together with their decryption keys on its servers by default and by not enabling end-to-end encryption for messages by default. Pavel Durov has argued that this is because it helps to avoid third-party insecure backups, and to allow users to access messages and files from any device. Cryptography experts have furthermore criticized Telegram's use of a custom-designed encryption protocol that has not been proven reliable and secure.”

Slide 32

Slide 32 text

WhatsApp Instant messaging apps ● Designed by Brian Acton and Jan Koum ● As of February 2018, the most popular messaging application in the world ● Worked with Moxie Marlinspike and Trevor Perrin to integrate some of Signal>1.5B people use parts of Signal without knowing it ● Brian Acton later invested $50M USD in the Signal Foundation ● In-line gifs 5M 100M 1.5B Signal Telegram WhatsApp

Slide 33

Slide 33 text

● WhatsApp isn’t as good as Signal, but it’s good for a lot more people ● Signal is better than Telegram in virtually every respect, technically ● Telegram “won” simply by not using phone numbers and having (large) group chats and gifs ● Telegram is extremely popular in the blockchain/cryptocurrency community ● Convenience trumps security, even in security-conscious circles ● If we don’t practice what we preach, how can we expect others to? The world is full of irony

Slide 34

Slide 34 text

Know what your users care about Regular people Power users Developers Businesses Simplicity, stability, price Implementation details, customizability Approachability, utility, ops overhead Tech risk, cost to adopt, business impact

Slide 35

Slide 35 text

An “internet of value” or a “global world computer” needs to be all of these, to everyone, at the same time.

Slide 36

Slide 36 text

In summary... ● Sweat the boring stuff if you want your worthwhile work to have been worth it ● One day of stupid work could be what decides the fate of years of hard work ● Don’t assume somebody else will do it for you ● Practice simplicity at every opportunity; do as much as you can in the background ● Avoid asking the user questions at all costs unless they actively seek out options ● Improving things that are broken from within may have a much bigger impact ● If you aren’t using it yourself, don’t expect others to ● Building privacy preserving, decentralized systems is hard. But if we can’t ALSO make it usable, it doesn’t matter if we solve it.

Slide 37

Slide 37 text

Decentralized networks, growing together. clovyr.io GrowClovyr AmberBaldet pmylund (Patrick Nielsen) Q&A