 Okay. Thank you. So I don't think that anyone can overstate the central role that passwords have in securing our lives and privacy. Anything that is valuable and can be written in bits is protected somehow with passwords. At the same time, it's undeniable that the state of security of passwords is catastrophically bad. But before I go into that, let me just tell you about the names of my co-authors. The top touches on several works with subsets with authors Tashiaretsky, Jiaushu, Agilos Kiyayas, Litesh Taksina, and Malie Shirvanyan. So again, we are very dependent of passwords, but passwords like to abandon us. They are regularly lost on stolen in thousands of millions, hundreds of millions lately than one billion in a single event. You can go to leaksource.com and see if you are lucky enough to have some of your accounts on passwords listed among the three billion passwords they have. It's about one password per internet user. So this is definitely a bad situation and an acceptable state of affairs. And the question is, do we have to live with these or we have better ways? So getting rid of passwords all together is unrealistic. They are too convenient. They are too massively deployed. Asking users to choose strong, high-entropy, independent passwords is equally unrealistic. And the question that we ask here is whether cryptography can help. And let me run the surprise. The answer is yes. Definitely, there are techniques in cryptography that can help improving the state of insecurity of passwords. And we will show some examples of different solutions to different problems in different settings. The nice thing about what I'm going to present is that all these solutions use very simple techniques, very well-established, essentially blind the Diffie-Hellman that originates with David Schaum. Ford Kaliski was first to use this technique in the setting of passwords. And our work has similarities with work done by Boyan. We will cast this in the more modern terminology of oblivious PRF, but when we implement stuff, we implement it with blind Diffie-Hellman. This is matured technology, even if it's not used, it's ready for deployment in the real world. And I'll go over these solutions very briefly, and I will be very happy to talk to any of you that is interested in the subject, and particularly if people think that they can help transferring some of these things into practice. So the main source of password leakage are offline dictionary attacks. They are the product of the deadly combination of low entropy passwords, which come out of the inherent limitations of human memory and of server compromise. An attacker that compromises a server gets what we call the password file, which contains hashed versions of the user passwords, and with the hash of the password, an attacker with a dictionary, a list of potential passwords can check which of the passwords in the list is actually a particular user's password. If a user chose the password in the dictionary, then it will be found. What makes this very effective is that there is special software and hardware, dedicated hardware to do these exhaustive searches of our dictionaries, and they can do many, many millions of these things per second, so this is a very practical way of breaking these passwords. At the same time, maybe the worst news is that offline dictionary attacks are unavoidable upon server compromise, whatever the... It doesn't matter what your protocol does and what your algorithm does. If there is a way for the server to check that the user's password is the user password, then the same thing can be done by the attacker with guest passwords. So we have to live with this thing, yet the hope is to be able to make these unavoidable and exhaustive attacks ineffective, and for that we either need to use high-entropy passwords or add more elements to the protocol, devices, servers. So in the first part of the talk, I will be talking about a way of taking the burden of choosing and memorizing passwords away from humans, because as long as we have to do that, then low-entropy passwords is the only option. And for this, we know the solution. There is the password store or password managers that keep a list of passwords that the user can take in a device or access or retrieve online, and it keeps it encrypted under a master password so that the user only needs to remember that master password. In that sense, this removes the need to remember many complicated passwords, and you can have only one, hopefully non-trivial master password. Now, this is a good type of solution in practice, the way these things are implemented is not always great. If you have a list of passwords which is encrypted under a master password, an attacker that finds the list can do an offline dictionary attack on the master password, and if he finds that master password, he finds also all the passwords of the user. Also, if passwords are in a device or in a server, and the attacker is inside that device, then when the user enters the master password, it can be learned that way, and again, all the passwords are compromised. Also, there are problems sometimes in the communication between the user and the device. And in addition to all of that, many of these password managers actually store user-chosen passwords, which means, again, somewhat low entropy and repeated among different servers, which is one of the bad things that happen with passwords. So can we do better? The answer is yes, we can, at least for the next 15 days. Yes? I had it that I took it because I didn't want to spend time there, so now I spend even more saying that I had, let's make passwords great again. So here is a dream password store. All passwords are kept in the user's device or online. The user memorizes a single master password as in any password store, but now all passwords are going to be random and independent of each other, which is the way they should be. But in addition, an attacker that gets hold of the device of the store or even has full control of the device learns nothing. Nothing about the individual store passwords. Nothing about the master password. Okay? So how does that work? First of all, when I say nothing, I mean in an information-theoretic nothing. I mean, it's a dream password store, so we can dream with information-theoretic security. The information stored in the device is going to be independent of the master password and independent of the individual passwords. Okay? So you see that storage and you see nothing about the master password or the individual passwords. The master password is never entered in clear text way into the device or the server, so that an if-dropper that is in the line between user and device doesn't learn anything. Even an attacker that is inside the device at the time that the user is entering or interacting with the device learns nothing. Okay? So it's... We call these sphinx for a master store that perfectly hides from itself. You can see this SPHI. What about NX? NX stands for No Exaggeration. Okay, so let me show you how this works. So we have a user. User. We have a remote server, client machine, and a device. The user starts by inputting the master password. PWD will be the master password, which is sent to the device. The device has a PRF key. Okay, so this is a scheme based on a PRF. PRF can be HMAC, CBCMAC, or something like that. The password is sent to the device. The device has this key case of D. It computes the PRF using the key case of D on the password. This is sent to the terminal, to the client machine. The client machine gets that value of PRF and call it RWD. And RWD is actually the password which is specific to that server. And now between the client and the server, they run whatever protocol there is there with RWD. So RWD is a pseudo-random password that basically the user had to register initially with the server. Think Google, Facebook, your bank, whatever. So each one, each server, or each account that the user has will have a different RWD and the way you compute it is you add to the PRF computation, the URL, some identifier of that service or the account. And we are not making any assumption on the password protocol. We just say RWD will be the password protocol. Whatever you use with that server will be used with RWD. So this solution already gives you part of what I wanted. One is because RWD is a pseudo-random, then offline attacks are invisible. The dictionary will be too big to run an exhaustive attack on it. Also, the storage here on the device is K sub D, which was chosen independently of the master password and the individual passwords. So the storage, if you find the storage, you learn K sub D. You don't learn anything about the master password. The problem with this solution is that the master password RWD is being sent in the clear to the device, so anyone on the link here or inside the device can read the master password. To avoid that, we move to an oblivious PRF. An oblivious PRF is exactly the same idea, except that now, after getting the password from the user, the client machine chooses a one-time key with which it encrypts the password. So now the password goes encrypted to the device. The device does something with that and outputs an encryption under that same key of the PRF value. Now, for doing that, the device does not need to decrypt the password. It does not decrypt the password and it does not learn the PRF value either because the PRF value is generated already in encrypted form. These were the magic of cryptography. It comes into play. And if we have that, then we are OK because now the encrypted PRF is only learned by the client machine that has that one-time key that decrypts the PRF, gets RWD, and it's being used as before. So as before, because RWD is to the random, then offline attacks are invisible, because the storage in the device is still independent of the passwords, but now we also have the master password hidden over the wire and from the device. So this is nice. The only question is, how do we implement something like this? So if you know about fully homomorphic encryption, that's one implementation. This is not what I would have called mature and efficient technology. So instead, we'll do something simpler than that. Here is the implementation. User enters the password. The client chooses a one-time value R. Oh, sorry. Let me say first that how do we define this particular RPRF? The particular RPRF takes the PWD, the password, hashes into an element in some predefined group and the key KD is an exponent on that group and the RPRF on PWD is hash the PWD, raise it to the power of KD. That's the RPRF. So now we go back to our client machine. We choose this random exponent R. And what it does, it takes the hash of the password, it got the password from the user and raises to the power of R. We call that value A. All that the device has to do is to take A and just raise it to the power of KD. When the client machine gets the value B, it raises it to the power of R, which basically cancels the R in step two. And what it gets is HPWD to the KD, which is how we define the RPRF. Okay? And now we can use RWD with the server. As before, RWD is to the random, then there is offline attacks. KD is independent of PWD and of RWD. But now we have that the master password is perfectly hidden on the wire and from the device. And I say perfect in the sense of Shannon security because the use of this exponent R essentially works as a one-time pad here, and nothing, information theoretically, is leaked on the password. So essentially, this is the dream. Password store that I was talking about, and that's it. That's all you need. Now, so this can work with any client server. Password protocol, it's server transparent. And not only secure, the performance between client and the communication between client and device is just a single round. Send the hash of PWD to the R, gets back this value to the KD, and that's it. It's one explanation for the device, two explanations for the client and one hash into the group. Any Diffie-Hellman group, we need something called the one more Diffie-Hellman assumption, but basically any Diffie-Hellman group, we believe this holds there. So you can choose a Diffie-Hellman group that is best for this type of operations. So we've taken these ideas and built actually a password manager that we call Sphinx. We show an implementation as an Android app, a usability study. I will not be giving references to papers during the talk. At the end, I have a URL with a page where you will find an annotated references for the talk because I'm touching on quite a few works. It's server transparent, so it's Facebook or Google or your employer does not need to know that you are using this store because, again, the password protocol can be anything. There is no need to have any means of protecting the channel between the client and device. You don't need physical security, you don't need extra keys, and you can use any form of communication, Wi-Fi, Bluetooth, Internet, whatever. And what is very nice is that this allows for an implementation where the device is implemented online, which you can use instead of the device as a backup to the device or both of them together, and you get all these properties on this online solution. To summarize the security, upon device compromise, you get unconditional security. Another thing after the attacker does have the key from the device, then basically this reduces to an online attack but on the RWD value, okay? Network attacks are unconditionally secure because the communication has this one-time pathing. No PKI has been assumed. By the way, none of the works I'm showing now are in another way. None of the works that I'm showing do not need PKI, which after many talks that showed us how bad PKI is, is a good thing. Offline dictionaries attacks are infeasible because of the randomness of the RWD. The only offline dictionary attack that is possible here is if the attacker gets the device and also the server, then it can run an offline attack, and that is basically unavoidable. Online dictionary attacks are infeasible because of the randomness and independent RWDs. Even there is some defense against password leakage. For example, if you find an RWD for one server, doesn't mean say anything about other RWDs. Even if you find a master password, you still need the device to authenticate. And there are some defenses also against phishing by adding the URL into the PRF. Full security against password leakage or client compromise requires two-factor authentication, and we also have some recent work doing some hopefully interesting stuff about two-factor authentication. I also list that in the list of...in the references. Okay, the second part of the talk is about how to protect valuable secrets when all you remember is a password, and here protect, I mean, both secrecy and availability, and valuable secrets. We have many examples from Bitcoin wallets, user-controlled cloud backup, like, you know, like Motty was doing. Secure messaging keys. How do you do things so that the user must be there to decrypt stuff. Private keys for public credentials. Many, many, many examples. Now, since we want to protect both secrecy and availability, in this case, just a single server is not enough. We need a multi-server solution. A single server would be a single point of failure for secrecy. If the server is compromised and there is an offline dictionary attack against it, that can compromise the secrecy. And availability, of course, if you have a single server, a single server is unavailable. The secret is unavailable, too. So we want a multi-server solution, and, of course, any cryptographer will tell you that the solution is to use a secret sharing scheme. And really, we want to share among end servers and be able to retrieve from T-plus-one servers. Even if your secret is, let's say, a Bitcoin wallet, it doesn't mean that you need to do this to the Bitcoin wallet. You encrypt and authenticate and put it wherever you want. You do the secret sharing to the key. And you retrieve from T-plus-one servers. Availability is protected as long as T-plus-one servers are available, and the secret is protected as long as no more than T of the servers is corrupted. Now we have a problem, because now the user will come to a server and say, give me back my shell. Now how does the server know who he should give this share? If anyone that comes and gets the shares, then anyone gets the secret. So, of course, the server will have to authenticate the user, of course, using a password. What is the user going to do? He's going to choose the same password for all the servers. So now, instead of one point of failure, we have end point of failures. Any server that is compromised, you find the password, and now you can access all the servers. So, of course, if you ask the user to choose a random independent password for the different servers, that is certainly unrealistic. So we have a problem with this approach. What we really want is this primitive called a password-protected secret sharing, a notion that was introduced by Bagger Zandy et al. It has two stages, the initialization stage, in which the user shares the secret among the end servers, after which the user forgets the secret completely, only remembers the password. At retrieval time, the user contacts T plus one server. The only thing that he remembers is the password, and that's enough for him to reconstruct the secret. And the security has to be that an attacker that breaks into T servers learns nothing about the secret or the password. Both of them are secure. And when I say that an attacker breaks into the servers, I mean it finds everything, it finds the shares, it finds the password file, any long-term keys. I'm not assuming anything that remains secure on the server. The only attack avenue after that is for the attacker to try to get your password and go to the servers, and if he guesses the password, then it can impersonate, otherwise it has nothing that it can do. Off-line attacks are impossible as long as there are at most T corrupted servers. I'll skip this one. And what we do is we give a very surprisingly efficient scheme. It requires just... Really? That's really bad. Let me see my situation. Wow. Okay. So it's a single explanation for each server. The client does two explanations in total, independent of T and N, just two explanations. And each one, the server and the client do also T multiplications or additions in the elliptical implementation, which are inexpensive operations. The communication is a single message from the user to T plus one servers, and one message is sent back from the server to the users. There is no communication between the servers. Now, there is no PKI's needed, no secure channels other than for initialization, in which case the user wants to identify and authenticate the servers. It is sharing the secret with, but not after that. And by the way, Morty mentioned that maybe secret sharing like this may not be practical enough or something like that. The cost of the thing is less than the cost of a TLS interaction with the server. So this is really, really inexpensive. And I will not talk about how this looks. See the papers. What I'm going to do is very fast. Tell you about this XPEG protocol, which is a protocol for this. If you have a single server situation, what is the best protocol that you can run? And this is a protocol with very nice properties. By the way, this is the protocol that is our PPSS scheme, but for the case N equals one, T equals one. And the very similar protocol was already proposed by Boy and Simeral years ago. And I mean, I have slides to show an idea of how this works. I will not be able to do that, but let me tell you what the properties of this thing are. So in any single server peak, what is called an asymmetrical augmented peak, you want that the security is such that if the attacker breaks into a server, it still needs to run an offline dictionary attack. For example, if you put the user password in the clear inside the server, this is not a good solution. You want to force the attacker to do a dictionary attack. So that's something we always want in this kind of servers. We want that no pre-computation prior to the time in which the attacker breaks the server will help the attacker. This is what we use a secret salt for. We would like that the server will never see the password in plain text, no reliance on PKI. And if possible, to be able to offload the hash iterations that you do for key stretching on the user side, I mean, any balancing that you want to do. And the regular thing that we do now, password over TLS, has the first two properties, but it doesn't give you 345, in particular the server when it decrypts the TLS. It sees the password in the plain text. Of course, it's very dependent on PKI. Without PKI, TLS breaks completely. And you cannot do this offloading if you don't want to reveal the salt. Other protocols in this type of protocols in the literature gets 1, 3, and 4, but the combination of 2 and 5 is actually unique, or at least from the protocols I know, it's unique to this protocol, which actually has all the properties. So it's a very strong protocol. I'll show you only one thing. To understand that protocol, you take Sphinx, as I showed before, and you just move the server to the side of the device, and that's it. And now you run the same protocol that you run with the device before you run it with the server, and this is all you need to do. And even if you want to do a full AKE, authenticated key exchange, for example, with HMQV, you still get a two-message protocol. If you want to do explicit client authentication, you need to add one more. Okay, let me... Two minutes for conclusions. One minute? One minute. So, summer password. Okay, so we all agree that password vulnerability is a big problem. Our goal was to show that password insecurity is not inevitable. Cryptography has some interesting solutions in these different settings. All schemes that I present are based on security, formal security models and proofs of security. Anyway, mature, efficient, simple technology is just waiting to be deployed, and here you have the references. This is the long one. If you want to write down, it's in FALTURLAAXCV. Thank you. Okay, thanks. In your first protocol, really elegant, I really liked it. You said you can use it with your Google or your employer or whatever. What if your employer is one of these evil employers that forces you to change your passwords every 30 days? I hate that. Yeah, I hate that. But what do you do? Could you just encrypt a password on this? Don't confuse us with engineering problems. Yeah, yeah. Very good question. So the solution, basically, is that... I mean, the best solution I can think about is that you will keep a counter. You can... If you're willing to store your accounts on the device, then it's easy because the account will store the counter and it will be added to the PRF. If you do that, then it's simple. If you don't want to do that, then there is a problem. Either the user will have to remember the counter or write it down or something like that. Also, if the site you're trying to log into requires you to have a symbol and a number and a... That's your question. Oh, sorry. Anyway, there is another engineering question. What happens if the password cannot be a random password? It has to be three symbols like this and this and that. I mean, these are all solvable in one way or another, but yeah, so... But I don't think any of these things really kills the solution. Can't go. We'll go again.