Simple is hard: Making your awesome security thing usable

If the security assumptions of blockchain systems fail even a little, they provide very little value. They also have a high barrier to entry and are hard to use. But wait, people already don’t use security tools — how isn’t this the worst of all possible worlds? We’ll talk about some precedents from infosec history and how we might be able to avoid “Your elections are fine as long as you use The New PGP on The Blockchain” in favor of helping people build cool things that really do solve longstanding problems in novel ways.

Patrick Nielsen and Amber Baldet are founders of Clovyr.

Transcript

1. Simple is Hard: Making your awesome [security] thing usable GrowClovyr AmberBaldet pmylund (Patrick Nielsen)
2. 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.
3. 1 Developer experience matters
4. Argon2 Who has heard of it?
5. Argon2 Who has used of it?
6. 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
7. 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
8. 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!
9. 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...
10. *record scratch*
11. bcrypt Who has heard of it?
12. bcrypt Who has used of it?
13. 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
15. If Argon2 is better, why aren’t people using it?
16. 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
17. 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
18. Argon2 is “better” but it’s impossible to say “Use Argon2”
19. Argon2 is “better” because only bcrypt is portable and usable by design but it’s impossible to say “Use Argon2”
20. 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.
21. Cloud-yelling interlude Date: Tue, 19 Feb 2013 01:42:42 +0100 From: Patrick Mylund Nielsen <patrick@...rickmylund.com> To: "discussions@password-hashing.net" <discussions@password-hashing.net> 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...)
22. • 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
23. 2 User experience matters
24. 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!
25. *record scratch*
26. 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
27. • 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
28. 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)
29. 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
30. 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
31. “[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.”
32. 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
33. • 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
34. 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
35. An “internet of value” or a “global world computer” needs to be all of these, to everyone, at the same time.
36. 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.
37. Decentralized networks, growing together. clovyr.io GrowClovyr AmberBaldet pmylund (Patrick Nielsen) Q&A