Keeping Passwords Safe in 2018

Introduction My name is Emil Bay. Online I use the handle emilbayes, I’m very active on twitter and Github where I create a lot of open source software especially in the space of security and applied cryptography. I also built a password security module that I maintain using the best practice as at now for developers to use especially on the web where secure authentication is required. I also speak about security topics at conferences. I’m also an independent contractor who works on different software projects. I love reading, traveling, and cross country running when I’m not coding. But I do a lot of coding. What is a password? This is a topic that’s pretty dear to me; I spend a lot of time thinking about this, and working with password in different ways. Basically, everyone has a password. If you look at it from a cryptographic point of view, a password is like a key that people get to choose themselves and can usually remember, which is not very good from a security point of view; making password security very tricky. That’s why a lot of research has gone into protecting the passwords that people get to choose themselves. Because people choose things that are easy to remember, and may have a personal connection to the passwords they choose. Which makes it sometimes easier for an adversary or sometimes an attacker to guess what password a specific person used if they who the person they are trying to attack is. In more simple terms a password is like a symmetric key you use when you sign up for a service and each time you want to authenticate yourself, you prove that you still have that key with you. Normally in cryptography, when people talk about keys, you have a much stronger notion of its randomness or predictability. If a password represents my identity, why not use the same password everywhere? That’s also the issue I mentioned earlier; when people get to chose their passwords themselves, they tend to pick one or very few passwords that they keep with them for a long period of time, and they reuse these passwords over and over again on different services (computer systems) online. The problem is that these different computer systems often have different security properties. To say that in a nice way, some of them don’t use best practices for storing these passwords safely. If one or the weakest link (service) where your password is stored gets compromised and your password is stolen, it doesn’t matter how good the other services are at keeping your password safe. The way that passwords work today is that they prove you as a single person. If you go to a service online, they cannot see your face or verify who you are physically. That means if an adversary gains access to your password, they can easily impersonate you everywhere. Solution? From a user’s perspective, you always want to have a unique password for every single service that you use online so that if one service gets compromised, the adversary won’t be able to impersonate you everywhere. But not many people use unique passwords. I keep an encrypted blob on my computer where I store all my passwords. In order to gain access to that you will need to hack my computer and hack the encrypted blob to find out what my password is. From a service provider’s point of view, you need to protect your users as much as you can. It is your moral obligation. You can either eliminate all bugs and security holes from your whole service which includes software that you write and software that other people have written that you depend on which I think think is realistic because we still haven’t figured out as a field how to write bug free software. Instead what you could do is figure out a safer way to store passwords. That is also one of my motivations to write software. For node.js there is this module called secure-password that I wrote. It’s like a high level wrapper that’s more familiar to developers but employs the most cutting edge cryptography underneath. Safe Storage is where we can do something as developers. What do these companies have in common? Adobe Bell Comcast Dropbox LinkedIn Sony Tumblr The issue is that none of these companies really knew how to store passwords in a safe way, and also they got compromised which is the worst that can happen to you as a service provider. Proper ways to store passwords? The first thing I did when I started out and wanted to mimic what I saw online when I started out was to store it in your database as plaintext. When you talk about security, always think about a threat model. There isn’t anything being done to secure your password in this threat model. A random person on your site won’t be able to glance through your database and see the passwords. But if an adversary should try, or if your database should leak online, then you’re exposing your users. And since most people use the same passwords everywhere, you will have them compromised across multiple service; that’s really bad for you and really bad for your user too. The first thing that you can do is to hide what your password actually is. I’m not talking about encryption because to encrypt, you will need to have something to decrypt with, you could do something like that but cryptography has come up with a better technique called a hash function. You give a hash function input and it will scramble it up and give out a fixed piece of data that is guaranteed to be very very unique and cannot be reversed. The good thing here is that even system administrators will not be able to take these hashes and figure out what the actual input was. Making hash functions also requires a lot of extremely complicated math. We are talking about a set of specific hash functions called cryptographically secure hash functions. You can also have non-cryptographic hash functions which people use when they want something to be very very fast but often non-cryptographic hash functions are somewhat easy to reverse. It’s possible to find what different values will give a possible hash. So it is very important to talk about cryptographically secure hash functions when you want to obscure passwords. You mentioned cryptographic hash functions are irreversible, how then did md5 and the others get broken and what's the best method developers should use? Cryptography is also a field that is getting easier to understand what’s going on, but for a very long time, I feel that cryptography has been such that you had to be part of a ‘Holy Group’ else you were not allowed to touch it. You had to understand all the math and analyze all the algorithms. That’s something that I’m actively working against because you end up with all these developers who are the one building the systems but don’t know how to handle the cryptography so they do whatever is most convenient like storing passwords in plain text or read blog posts where people still recommend using md5 which was broken about 20 years ago. I am working on a lot security focused modules where you don’t really need to understand any of the math, you just need a contract or guarantee that they are one way and that there is no shortcut. You have to spend a lot of computation time. [Play audio from 19:00 to learn more]. In 2013, a bunch of cryptographers gathered for the Password Hashing Competition. The winner was an algorithm called Argon 2, which secure-password is also using. Which is resistant against GPU attacks and resistant against Large Scale Computing attacks. That’s what all cryptographers recommend now as the most secure algorithm. How does Argon 2 resist GPU attacks given how fast GPUs can run? Normally when you lay out a threat model, perfect security from a mathematical point of view is almost never practical. (In cryptography, can be referred to as perfect secrecy which means, even if you have an enormous computer the size of the universe, it doesn’t matter how big it is, you can never break the security, but that’s not really practical in the real world.) Instead you go for something called computational secrecy. Which means you can break this, but it will cost you too much money and take too much time. The goal of these hash functions is to make it so expensive to brute force these algorithms that there would be no point in trying. In a threat model, you know that you are not going to get perfect security but can you make it so expensive for your adversary to attack you. Argon 2 has two parameters that make it immune to GPUs. You can control how much memory the function is allowed to use, and you can control how much computation time taken to make a hash. A CPU usually has a lot of memory but a few cores. A GPU has very little memory but thousands of cores. Argon 2 dials up a lot of memory that you can only do about 4 or 8 simultaneous Argon 2 hashes on a single GPU which makes it too expensive to try and crack. In secure-password, I’ve taken the values that Frank Denise who made sodium which it’s built on figured out. It’s within the bounds of an interactive service like a website can afford to create reasonable security without slowing down. To hash a password, you need about 16 or 32 Mb of memory and those parameters can be controlled in Argon 2. Would you store your password in a browser? I don’t think the Save Password feature in a browser is a bad thing, but I use a password safe to store my passwords and I’m more comfortable with because it uses a master key that I only know. I can also be fairly sure that the password safe is reviewed. It’s a different thread model with the save password functionality you get from a web browser than it is with something like storing it with service provider… What are salts? I don’t think the Save Password feature in a browser is a bad thing, but I use a password safe to store my passwords and I’m more comfortable with because it uses a master key that I only know. I can also be fairly sure that the password safe is reviewed. It’s a different thread model with the save password functionality you get from a web browser than it is with something like storing it with service provider… Play the audio to get access to exclusive content