 My talk is going to be about more secure ways to authenticate an insecure environment. So addressing, from a user interface perspective, some of the problems with passwords and pins. And there are two names there, and anyone that came here expecting that there would be a hot girl accompanying me giving this talk, a doubly disappointed, because Andrea is not a girl, he's Italian, so it's an Italian name, and he couldn't make it. A lot of this talk is Andrea's PhD work at KAIST. I'm a visiting professor occasionally at KAIST in South Korea, and I thought that DEFCON would be very interested in Andrea's work, and I was hoping that he would be able to come too, but he has to finish his PhD at the end of this summer, and he's taking four hours a day of Korean classes because he's a masochist, and so he just couldn't make it. But he joins us in spirit, and he'll be very excited to get feedback from the DEFCON and the security communities about this work. So an overview of the whole hour-long talk, first of all, some key features of password and pin authentication and the nature of the observation threat, then three categories of threat and response. And our concern here is primarily interface design, so not the idea that we can make this thing perfectly secure because we know that we can't. But first of all, but it's gonna be about how we design interfaces that mitigate these threats in an environment where we can't completely control what's going on. So first of all, being observed from outside, so physical and key entry at an insecure terminal, and some mechanical and electromechanical observation resistant solutions to that problem. Secondly, observation from within a compromised terminal, so being watched from the inside and protecting your key between your insecure input device and the network and the bank and whatever way you can secure it, or you can do a better job of securing it. So version of recorders and loggers, and then rethinking the way that we treat passwords and enter them. So it's not just the thing that we remember that we have to physically type in somewhere. So remote entry and secure transmission to the terminal, and can we use some of these digital tools that now everyone carries? So here are some basic authentication methods, and this is what passwords are competing against, right? So password is something that you remember versus something that you have. So a key or RFID card or a security card, or something that you have because it's part of you, a biometric statistic of some sort. And why should you use one over the other? Everyone has advantages and disadvantages. So with passwords, the big advantages are that the information is invisible, so no one knows if you have it or not, and it can be delegated. So that means you can give it to someone else. If someone needs to get in something, you can give them your password. And delegation also includes replacement. If someone gets it, you can change it, and you can maintain security. The drawback, the big drawbacks, that there's a cognitive load. You have to remember them, and they're susceptible to observation. If you know what it is, it's already copied. Tokens are also cheap like passwords, and they're commonly available, and you can delegate them. You can give someone your key, but it is a physical thing. They can be stolen, they can be copied, they can be lost, and they can deteriorate, they can stop working. The biometrics have no cognitive load at all. You don't have to remember it, it's just something you have. And people seem to kind of dig them in a certain way, like non-security people, especially are really into them. But they're also a physical property. They can also be copied. They're a unique thing, but they're not secret. People can record your fingerprints or whatever you're using as a biometric, and they deteriorate. They change even as you get older. Things like the shape of your face and so on change. Also, a lot of people have severe philosophical issues against them, and you can't delegate them. You can't give your finger to someone to log in on a fingerprint thing, and you certainly wouldn't want to. So we like passwords because they're invisible and delegatable, but the cognitive load has always been a big problem for them. And you see that so many massive breaches don't depend on individual problems with implementation of security at the different places. They depend on the fact that people reuse multiple passwords, and they get someone's Gmail password, and then suddenly they've broken into all of the critical systems that they also have access to. We tell people not to do that, but they do it anyway. So even though they're still valuable and they're going to be with us, the big weakness is the fact that that cognitive load causes people to reuse them and they're now even more weak against observation. You need to have many of them, and you need to change them frequently because they can be lost so easily. And observation is a classic attack. It's not just in passwords and so on. So cheating at poker, for example, this item that's on the screen is a fake pipe with a mirror in it for a card dealer to cheat at poker so they can see the cards that they pass across it. So a classic observation attack for a crooked individual in the system. And these observation attacks are everywhere in computing. So they're in the human interface, external, for example, shoulder surfing or mirrors and cameras, quick show of hands. Who's ever shoulder surfed someone's password or pin? I hope it would be most people in this room, right, because it's so easy. You can also dust the keypad and you can essentially shoulder surf when someone's not there, when they've already left and used the thing. There's stuff that's internal to the computer interface. So ATM skimmers are a really great example of that that have been cropping up everywhere. Key lagers. Hands up anyone that's ever used the key lager on someone else's computer or their own. Not quite as many people because you have to be really going after someone to do it but it's still really common. And then, of course, the stuff that we normally really think about, the attacks in the network, so packets sniffing, man in the middle and so on. Grabbing information once it's already in the system. And that's, because that's so common, there's a lot of work that's been done to mitigate that, so a lot of encryption and so on. And, of course, we can secure the external and internal human interface, the stuff that faces the human, if we keep the interface private. But what about when we have to use public terminals? So public terminals are everywhere. We see ATMs, airport kiosks, door locks, public computers, and access control for facilities. You probably use one pretty much every day. So let's take a closer look at one of the most common public terminals from a human interface perspective, the ATM. Where did it come from and why was it designed the way that it is? Well, before there were ATMs, they were just the human bank teller. You went to the bank, you dealt with a human, it was a reasonably private interaction. And so, when designers say, we're gonna replace the bank teller for whatever reason, well, you get a machine that acts like a teller. So that's the first cash dispenser in 1967. And the early ATM concepts really replaced the interaction with the human. They had a human on a video screen. This is 1973 Future Teller, and you can see these television tellers. They had a person somewhere else remotely doing a virtual shared interaction, just like the real teller. So why would you do that? Why would you replace a human teller in person with a human teller on a video screen? Even if you look 2010, we're still doing that same thing as in 1973 with a teller on a video screen for these certain tellers. Well, you wanna replicate the experience, but add 24-hour availability and remote access. But yeah, in 40 years, even though things became more automated, you didn't necessarily need a remote human staff. The basic terminal model and the interaction style didn't change. Like the teller, the terminal is a physical thing that you need to go and use, and people can watch you doing that. I mean, think about what other things are we doing the same way 40 years on? Now, there are lots of ATMs everywhere, but the number of manufacturers is not super great and the interaction style is practically identical. You've got a digital decimal pin number that you type in. Interfaced-wise, it's like a monoculture. Everyone's basically the same. There's a place to input a token, a place to receive cash, and an interface to input control information, including that secret information. And even when a company like Ideo, which I think is the world's biggest design firm, tries to reinvent the ATM, it ends up looking slick. To me, it kinda looks like a urinal, but it still has essentially the same interface elements. It's still got that screen and that pin code pad. So their ATM of the future, as envisaged in the last couple of years, is still not too different from the concept from nearly 40 years ago. From a security perspective, what's really important about this interaction design that's had remarkable staying power is that it's physically situated, and therefore easily attackable with physical methods such as shoulder surfing and mechanized observation like ATM skimming. Hopefully, everyone here has been keeping up to some extent with the effect that low-cost hardware is having on ATM attacks and the proliferation of sophisticated skimming operations. There was even a fake ATM installed at DEFCON here a couple of years back, well, not here at the Rift, but someone set up a fake ATM and waited to see what people would try to use it. We got MagStrike readers, wireless transmitters, cameras. They're also cheap now that you can make something like this that's essentially disposable. When it gets found, you're gonna lose it, but it'll pay for itself in just a couple of skimming operations. Criminal organizations, manufacture, injection molded, keypad and card reader overlays and so on for common ATMs, like a lot of the most common national cash register models, and you can buy them on sketchy crime sites for like $1,000. And every time I go to an ATM now, like I really look for a skimmer, not just to make sure I don't use it because I really wanna find one in the wild and I wanna get it and take it apart. I haven't been lucky enough to do that yet, but hopefully one day I will. And they use methods of observation like cameras to see people typing their PIN codes, also wireless transmission from the PIN pad overlays and so on. And then down there in the lower right is an electronic door lock, which they love in Korea. Like they're basically every door, but they're super susceptible to observation because you can see the fingerprints on the commonly used buttons, or you can add something else that gets wiped off when people use it, you can tamper with it. So there's definitely a threat to using a public terminal. And all of these attacks work because the attacker knows in advance how the PIN is gonna be entered. So quite a few researchers in the human interface community have suggested alternative methods of PIN entry. So for example, PIN pads that move around and you have to play like kind of a game, so the interaction is not so easy to replay. Spy-resistant keyboards, so you can't tell which of the keys someone's selecting because there's multiple different colored keys, characters on a key. Gaze-based password entry. So the idea is if you're not looking directly at the person, you can't see how they're moving their eyes around to log in. And then haptic password entry, which is some stuff that Andrea has been working on. So this is things that you feel, haptic is using the modality of touch. But despite all this, keypads are still the norm. So here's the basic considerations of the stuff that we've been looking at. We accept the need to use public terminals. It's not gonna go away. But it doesn't mean that we have to all do it the same. So we wanna be able to mix up password entry mechanisms to make the system less of a monoculture and less easy for one attack to get everything. Doesn't mean we have to use the interface we're given. So we wanna give users the power to improve their own interface security, not just be dependent on whatever the organization offers. And we wanna revisit the assumption that all interaction has to happen at the terminal. Even if it's a physical terminal that you've gotta use, all of that interaction doesn't have to happen there. So we wanna move from a mode where everything is done one way at the terminal subject to observation and replace it with a way that things can be done lots of different ways. The input is mediated at the terminal in an observation resistant fashion. So in other words, to decouple the interaction, to separate the input method from the communication to the terminal. So part one, observation, new alternatives for physical key entry to avoid observation at the terminal physically. And the basic idea, which will present various methods here, is a haptic password. Or the basic idea really is a side channel that's not visual and is less easily observable. And one of these is haptics. So first off, a haptic keypad. And haptics are observation resistant because the sensory modality is less leaky. People have a harder time feeling what you feel than seeing what you see. And so in this work, there's a series of tactile cues or tactons that you feel at the fingertips and they're inherently invisible to someone that's watching you use them. So in this system, we have three possible tactons. A continuous buzz or continuous vibration, a one hertz pulsing and a two hertz pulsing. And these different modes are pretty easily distinguishable with the fingers. And so you can make a password out of a sequence of these tactons. And here's a prototype of a haptic keypad that uses them, quite simple hardware. There's an Arduino that does all the work. And then the haptic keys each have a vibrotactile element and a sensing element. So here's what the keys look like closer. There's a force sensing resistor for adjusting the output of the vibrotactile element. And there's a switch for registering a key press and then the actual vibrotactile motor that makes the vibration. And there's visual feedback in the interface of how far along that you are in the password, but nothing that indicates what was entered, just how many things were pressed. So how it works is the three tactons are always assigned to the three keys with a one-to-one correspondence, but in a random order. So even if someone sees the way your fingers move, they can't do a replay attack. You fill all three keys and you select the one that corresponds to the right tacton in your password and then click the key. Repeat for as long as the password goes. So press down. So it won't do it if your fingers aren't on the keys, so you're obscuring the vibrational elements. Fill the three tactons, select the right one, and then they get randomly reassigned and you go along through the stages of the password. Now there's three separate tactons, so that means that the password essentially forms a trinary code, like binary, but with three possibilities. And the probability of a guessing attack on any password is one over the number of possibilities to the power of the unknown digits in the pin. So if we have a standard numerical password for decimal digits, that's a one in 10,000 probability of a brute force success per attempt. So it's clear that with a haptic pin, with three tactons, then our pin is gonna need to be longer than a decimal pin. So this is maybe gonna be a little weird for the DEF CON audience. In the human interface community, we do user studies to see if things would work or not, which basically means you round up anyone that's near the lab and give them $10 or an ice cream voucher to come and play with your device for a while. And I'm gonna skip through these pretty quick, but if you're interested, then links to the papers and more details are on the set of slides that's on the DEF CON DVD. So we did a pilot study, or Andrea did a pilot study to first evaluate whether the tactons are perceptually distinct or not. So can people recognize them? And then the second study, if the hardware works, then can it be used effectively for authentication? So the result of the pilot study was people could recognize them very easily. There were no errors. And then so that led to the user study in which there were three experimental conditions to evaluate different versions of the software and different pin lengths. So the first two conditions, first of all, a six-digit pin, which is not secure to the standard of a four-digit decimal pin, but it's relatively memorable. And then a nine-digit one, which does conform to that brute force attack security level. It's worth noting that 729 is not considered secure by the standards of the four-digit pin, but it's not that much fewer than a simplex lock, which has been used all over the place. So a trade-off between password length and performance. Then if we assume that brute force attacks are not a problem because it's electronic and the device won't let you make hundreds of attempts, at least in a reasonable time, then we can resist observation and not worry so much about brute force by doubling the number of trials for each pin digit. If instead of pressing the right tact on, you press both wrong ones. So it makes it harder to observe what someone's doing because there's more presses going on, but the brute force resistance is the same, but that gives you a higher observation resistance. That's a trade-off of complexity versus performance. So this user study showed, first of all, that the different methods did take different amounts of time, as you would expect the longer pin takes longer to enter, but the hybrid mode entering the incorrect ones, even though it's a six-digit one, took even longer, but there are 12 entries instead of six. The number of errors was not significant, but possibly due to the high amount of variability of the study. And then there was also a NASA TLX workload measurement done to see what the mental workload was and it showed that the hybrid mode was much more difficult to keep track of mentally. So using the six-digit tactile pin as a reference, the nine-digit one was not more challenging for users in a workload sense. Remembering a nine-digit tactile pin was easy enough to remember and didn't provide significantly more error, whereas the hybrid mode, there's a lot to think about, there was a higher overhead and it did take longer. And that was compared with a different haptic password entry method that I mentioned earlier and it performed better. So that's a method that can be used when you have a physical keypad. But what about unlocking these new interactive devices that we have? There's been a shift in the way that we compute over the last 40 years from private user to these public collaborative interfaces like surfaces and to mobile devices. And we still need to log into them. So we've got large screens, we've got public spaces, so shoulder surfing is as useful, if not more so, for pin theft than it ever was. It's almost hard not to shoulder surf people's mobile phone pins, especially when people use that Android swipe thing, like you can't see someone log in and not remember it. It just drives you nuts. So it just remains one of the most common ways to steal one. So it would be great if we had an invisible pin entry method that could use an alternate sensory modality, just like the haptic keypad. But should it be audio or touch? And we can write off smell and taste, I think, for the moment. So previously, Andrea had done a interface with a rotary wheel, where you searched for a tacton by spinning this wheel and then selected it. So kind of like a knob interface to the tactile keypad. So this is the same kind of tactons and a 3D printed knob with a vibrotactile element and you just kind of spin it and search for the one that's the right one, press the button to enter and move on to the next one. Now with mobile phones, we have vibration motors in them. We can do the tactons and we also have audio output. So for a numeric pin, we could use text to speech to actually speak out those numbers. So we have a sequence of cues, either auditory or tactile, that can be invisible to everyone if headphones are used for the audio. But if we want to compare haptic and auditory cues for a decimal pin, then we need more tactons. So we made up more haptic vibration patterns to correspond to the 10 things and they ordered in a way that seems reasonable, right? So single pulses going to double pulses to triple pulses to continuous. So here's the touchscreen version of the rotary wheel interface. 10 slots for 10 digits. They're assigned to slots with a one-to-one correspondence, preserving order but randomizing the start points for observation resistance. So you start somewhere, move around, looking for the correct number, and then select by selecting the center of the wheel to lock in that digit. Move on to the next one. And then the order is re-randomized on each trial so that you can't learn anything from the previous entry. So here's a video showing. Seven, eight, nine, zero, one, two, three, four, five, six, seven, eight, nine, zero, one, six, five, four, nine, six. So you can't tell by looking at it what the digits are that are being entered and if you use the headphones, only the user can see what is being entered and with the vibrotactile method, if the environment is quiet, is not too quiet, then you can get away without using the headphones at all. So in a public space where there's some cover noise. So two user studies were done for this one as well. Again, a test for perceptual distinction and then a full study to compare two things. First, auditory versus haptic modality. Second, large alphabet versus small alphabet. How big of a number of digits should be involved? Assuming that there's enough for acceptable brute force resistance. The pilot study showed some difficulties with tact on recognition with the large alphabet. So the more complex alphabet was harder to recognize, the error rate was higher. In the full study, two trade-offs were analyzed. So maintaining the same security level, looking at, first of all, the two modalities and then four digits from 10 alphabet and then a six digits from five. Both of them have acceptable security and the six digits one allows us to compare to the tactile keypad. So the results of that showed, first of all, audio is much quicker than haptics regardless of pin length and there's, again, a lot of variance in the error such that we didn't get a statistically significant result from error rate. So overall, the audio was better than the haptics, perhaps because it's more familiar, but you have to use headphones to make it non-observable. The error rate dropped from the main study from the pilot because it was the same subjects we used and it seems like subjects become more experienced with the interface. So it doesn't mean that it's completely out of the question if people are gonna quickly become twice as good at it. So overall, slightly better performing than the haptic keypad. But as we saw in these interfaces, there are basic problems from a usability standpoint. So even with the wheel style lock, a wheel or knob should be really simple, should be very intuitive. Everyone knows to spin it to go one way or the other. But with the tactons, we have to remember and recognize all these weird vibration sensations. So what about an interface that only uses a single queue that would completely eliminate the recognition problem? So instead of recognizing and distinguishing between these multiple tactons, you just have to count. So the next one is called the spin lock, which is loosely modeled on a safe dial. So instead of digits, the pin consists of movement offsets to the left or the right. So here it is using the auditory version. Again, observation protected when using headphones. And the thing is here, your password has to be kind of stored in a way that's not your normal, just sequence of digits, because you have to remember if it's left or right. But it alternates one way or the other. You set up a password. And the clicks here are just progress indicators and the beeps are the counts. Someone who's observing can't tell how many you've gone because the distances are randomized and the start point is wherever. Once again, silent with the headphones on. So use a study for this one. Andrea ran them as well. Looking at three questions. Do we think it's gonna be faster to count than to recognize? Do we think it's gonna be more accurate to count than to recognize? And the third hypothesis that counting will be a lower workload than recognition. So once again, haptic and audio compared. And this time pins made from either five or 10 possible digits, so possible movements to the left or the right. Each user got instructed, got to play with the interface, then do four tests, and this TLX mental workload test. So as you'd expect, longer pins took longer to enter. And the haptics took a little bit longer to do than the audio, but not a lot. A little bit more error prone for haptics and audio as well, also not a lot, but statistically significant. The workload one was interesting. Once again, the haptic interface was more cognitively demanding than the audio. So people still had to kind of think about it a lot. But nevertheless, in post-test questioning, people preferred the haptic modality because they felt that it was more private. They didn't have to switch to the headphones. So a couple of possible explanations there. First of all, system latency can be a problem for haptics because that motor has to spin up. And so if people are spinning the wheel fast, then they can miss the cues as they go over them. So that could be a contributor to the higher error rate. Secondly, more complex pins took longer to enter, but they didn't result in worse errors. So it doesn't feel like there's an error rate per entry of the pin. There's some kind of just overall error rate. And I think that that's because a large number of error trials involved a mistake in only one item. And the majority of those errors involve people entering a very close number of digits and then becoming aware of that and resetting the system. So just missing that correct count and they knew to reset and start over. So it's not the same as having an authentication failure and getting frustrated and then, of course, potentially wiping your device if you have it set to wipe after a certain number of authentication fails. It came out slightly better on average than that rotary lock that came before. So we feel that simplifying the pin to a count instead of digit recognition is faster, less error prone, has a lower mental workload. So that's some new ideas for physical key entry at the terminal in the presence of physical observation threats like cameras and shoulder surfing. But what about when you have to use a terminal that you don't trust, like a web browser, that has the default computer key entry mechanism, which is a keyboard? Can we use software to help make us less defenseless against observation from within? Here's the problem with untrusted computers. As a user, you can keep your password secret. You can do everything properly, never tell anyone, never write it down. And once it's in the system, it can be salted and hashed and it can be used for authentication in ways that make it difficult to recover the original password. But when it comes to actually entering that password, you have to do it in the clear. You have to type in the real thing. So keystroke loggers are a major method of password observation and compromise. Last year I gave a talk about recovering my stolen computer and one of the tools that I used to do it was a keystroke logger. They can be in software and they can also be in hardware. You can get on sites like ThinkGeek, these little hardware keyloggers that read the keyboard, send it out wirelessly and just grab whatever someone types. Now of course, malware is one of the most well-known ways that people get their activities logged and compromised. But I don't want people to focus on malware entirely because there's lots of other ways you can come into contact with a logger. We're varying levels of quote-unquote legitimacy, meaning whether it's been installed by someone that owns the computer or not. Some people install loggers to keep track of someone, like to see if their boyfriend has been sending, did their email password, to see if they've been emailing other women and stuff like that. You've got jealous partners. You've got employers that do a lot of keystroke logging, governments and so on. So for the paranoid, there are lots of other ways you can get logged. Some people even install loggers on their own machine as a matter of course, so that they can go back and see if anyone else has been using it and what they've been doing and maybe reverse-own them if they need to. So any part of the user interface can be logged. It's not just the keyboard, but it is that any keystrokes, mouse clicks, screenshot shots of what's on the screen and mouse movements and so on. These are kind of in decreasing order of whether they're usually in a logger if you find a software logger. So that's why it's interesting for user interface designers to see if we can make things a bit more difficult for the attacker while not making it too much more difficult for the legitimate user. Now at the start I mentioned that a problem with passwords is this load of having to remember lots of them and this leads to bad practices like reuse. So browsers and computers now often feature these password keychain features. And this has the side benefit that it reduces, I mean, first of all, it means you can keep track of them all. That's the main reason, the side benefit is that it reduces the frequency that you have to use those UI elements to actually enter a password. A lot of times you can just click okay. So less stuff gets logged. And I noticed that when I was stalking back my own computer. But these things are no use at all on a public terminal because you don't want it to remember your password. And I personally, as a somewhat paranoid person, hate even using a friend's browser because I don't know how they have password saving configured. It might just be remembering all passwords and mine's gonna get stuck in there with that. And then sooner or later, you're gonna be on the road and you're just gonna have to use a sketchy internet cafe somewhere. It's really easy to say, I'm just never gonna do it, right? I'm always gonna use my own computer. But once in a while, you have to. So authentication for accounts on the web is currently completely under the control of whoever's running the service. The mail provider, the bank, whatever, facial book, Google, whoever. Some of them are more responsible than others and have varying degrees of protection against password theft. So the most basic that you see is forcing you to change your password every so often. And that's essentially damage control. It limits the amount of time that a compromised password is actually useful for. Some of them have a small kind of second factor where you have to say, recognize an image before you enter a password or these image-based keyboards instead of your actual keyboard. But those are susceptible, well, get that done in a sec. Sometimes they have changing security questions that are asked to you every time, but there's only so many of them you set up for an account. So those are logable too. And you actually see that a lot with the banking information stealing malware. There's an interesting one, sites like Hotmail do this. You can get a one-time password which will text message you to your mobile phone. Which, yeah, is pretty useful for resisting loggers, but it has an unintended consequence that anyone who steals your phone now has access to your email. You have these one-time tokens, physical tokens that generate a code that you use at the same time as you use your password. And what that basically does is reduces the value of the password to be stolen. You can't just use the password. So it's a good method. But how many of those things do you want to carry around? How many versus how many websites do you use and log into? There's some interesting stuff that's been done especially in countries where people are very poor and don't have a lot of technical literacy, such as India. And there are things like these things they call them nonces, which are disposable one-time password modifiers. So this is one from India that some Microsoft researchers helped design. And so every time you want to use your phone to bank, you've got to do this transaction in the presence of someone. So you tear off the first paper thing and you modify your PIN with this tear-off thing that you never show anyone and then you dispose of it afterwards. So you have this physical thing. But again, it's a physical thing, even though you could use it online and so on as well. But if you prefer one method over another, you're out of luck because few sites support more than one method and in many cases, none at all. You just enter your password and you take your damn chances. So the ideal outcome would be if we as the users could choose our own software-based interface that would make it harder for attackers to observe our passwords and do replay attacks and that could be used on any website at all without the participation of the website operators. And most people in this room, I'm sure, already keep their own machines locked down and have various ways of protecting themselves. But we don't have so many options on a public terminal. In particular, forgetting about malware, just in terms of a unscrupulous operator, we have no way of telling if the operator of the machine is running a logger of some sort. And we usually don't have permissions to install or run our own software. But if we're using these terminals to access the web, we usually have the full web and we can usually access pretty much any basic web content. So the goal here is to obfuscate data entry in terms of the physical user interface elements using simple web mechanics that aren't too tedious for the user. And if you look at forums like Slash. And so on about people talking about these things, or if you've used a lot of online banks, then you'll see that people have thought about this and they've done various sort of hokey methods to do it. For example, copying and pasting characters into a password field instead of typing them on the keyboard, which is fine against the hardware key logger. But if you were gonna write a key logger, you'd log the clipboard too, right? Um... Banks have used this one, a on-screen keyboard, or selecting characters and dragging and dropping, so it's all mouse-based. But there are also loggers out there that log the area around each mouse click. A little bit of the image doesn't take the whole screen. Alternatively, you can accept that your password is gonna make it into the logs. And you can shaft the logs by putting a lot of extraneous keys in there as well. And I feel like anyone who's really enterprising and analyzing the logs and is really writing a kick-ass logger could time-stamp the keystrokes and could pull it out pretty easily. But more importantly, this is a total pain in the ass. And users are just not gonna want to use this. It takes a long time and it's very error-prone. Now, I know that you're all thinking, well, who cares about this interface stuff anyway? This is all bullshit-zars because there are form-grabbing malware out there. It's a man-in-the-browser attack and there's nothing you can do about it. These types of malware hook the browser and they grab the contents of all web forms pre-encryption before it's sent off to the site and they mail it off to Russia. Examples are online banking theft trojans like Zeus and Spiii. And this software is very effective. It now represents the majority of passwords stealing trojans. But I said trojans and not password thefts in general. I'm not so sure about how it compares to password theft in general and I suspect it's not as great as it is in just in terms of being limited to malware. And there are some limitations. For example, they're not multi-platform. They don't support every browser. You can see from that screenshot there that Spiii just in the last two months released support for Opera and Chrome under Windows. So people who use esoteric browsers and so on may or may not be vulnerable depending on how these software developers are progressing. And there's no UI mechanism that can mitigate this tactic anyway. So for UI people, it's sort of not an interesting problem in the sense that we can do anything about it. I think there's lots of things that the browser people can do about it. But this is interface design stuff. So I think that just because this is out there, we don't just have to throw up our hands and give up and say, well, we can't protect against this anyway. There are still plenty of threats that we can mitigate. And I really wanted to mention this because if any people here don't know about these browser compromises, they should. So you should be even more careful than normal accessing from an untrusted terminal or a machine that may have been compromised, anything that involves you losing all your money because assuming you have any left with the economic collapse, you can lose all your money with this stuff. So here's what we wanna do. We wanna give the user control of that authentication interface. We wanna keep any sensitive text out of the log. Minimize the amount of other data leakage that could be done by other UI logging mechanisms, right? So we don't wanna even make it any easier for people to do brute force attacks. We want the logger's job to be as hard or harder than someone who's in the room with you shoulder surfing you or camera recording you as you log in. And we want that choice to be available but still focus on usability and support a lot of different ways to log in that people can feel comfortable with so that a single attack method doesn't work on everything but that people will still use it. So getting this sort of ecosystem that forces attackers to do the work, make them support everything. And there's a way that we can essentially hack any website right now which is to inject JavaScript directly into the site. And that's something that's normally associated more with attacking than defense. If you visit a malicious site, they can inject JavaScript into your browser that logs all your keystrokes even though nothing's been compromised on your computer. But we can also intercept keystrokes and we can obfuscate it by injecting a known trusted script into the current web page. So we can do all kinds of neat tricks drawing over the active page and so on which can help us if we wanna use our powers for good instead of evil. The big difference interface-wise here is now we have 95 printable characters to support instead of 10 digits or something like that. So we have to do things a little bit differently. So here's the simplest approach. It's a visual keypad that you can bring up over any website that intercepts keystroke events and instead of clicking on it with a mouse, you type the keys and it automatically performs a one-time pad substitution that automatically remaps any key that you type. So you look for the, the metaphor is for people who sort of type like I do by looking at the keyboard. You can regenerate it on a per keystroke basis which is useful because this is a method that's susceptible to screen capture but if you regenerate it on a per keystroke basis, you have to capture the entire screen on every single keystroke. Because it's a one-to-one mapping, it will reveal your password length so it does potentially make brute force attacks slightly more easily, more easy. But the password itself is not gonna be recoverable from the text log and you can also remap the username as well as the password if you feel like you need extra obfuscation. It's quick to use, it's just visual search for each key. But we sort of don't like the fact that it's easy to screen cap. So here's another custom interface designed to make the screen capture problem more difficult for the attacker. It's sort of based on the idea of a code wheel, a combination style code wheel log. Because you have a huge alphabet, it's gotta be a big filthy thing that covers half of the webpage but it's see-through. So you can drag it to wherever you need it and not obscure what you need to see on the webpage. It uses the mouse but no clicks are involved. So it won't trigger click-based screen capture. How you use it is you mouse over a red reference key which is the point that is gonna correspond to the key that you're gonna want. Then drag the mouse around to rotate the desired output key into place and then hit any key to lock in whatever key it is that you wanna type. Basically, what you're gonna see in the log is a string of whatever keys that you typed. It could just be all spaces, whatever. And it intercepts additional keystrokes so if you wanna chaff the logs to conceal your password length, you can do that too. Time cost, you've got your visual search and you have this kind of animation. So here it is in action. You can see watching it that it's essentially replacing that key press information with visual information. So it's possible to shoulder-surf this method without seeing the keyboard. Although it's difficult because it's a little complex. You can try and see what password I'm entering here on this video. But it's a trade-off. But you can essentially choose each method here. So you could use this one when you know someone's not watching you over your shoulder if you're reasonably sure that the entire video session isn't being logged, for example. But what we really want is a method that's resistant to shoulder-surfing and screen capture as well as being resistant to keystroke logging. So I haven't personally ever seen a logger that logs the audio output and you can use headphones to reduce the observability of the audio signal. So here's my version of Andrea's spin lock. It uses auditory stimulus based on counting just like the phone lock. But it's got to support a full keyboard. So instead of a circle that you might have to spin around an average of around 50 keys, I figured you could look at the keyboard and then drag a handle down to select the row and then across to select the key. So here's an example. There's only a few little UI elements that you drag into place. And you just count those clicks as you go across down and across the keyboard. You can look down at the real keyboard as you do it. Because each row of keys is shiftable, there's actually two clicks per row and the top is the shifted key and the next one down is the unshifted key. The relative of the positions of the clicks are randomized so even if you can see the screen, you can't tell from how far the handles move what's being selected and there are no key presses at all. It's all that audio side channel. Medium time cost, two sets of counts per key press. So in summary of this section, the important thing about this is not those three example methods that I showed. What's important is giving people a choice of how they authenticate or even tools to roll their own method if they don't like what's out there and they want to use what's best for them instead of just forcing them to live with the service that they're offered. And ultimately, these are just seeds for what should in an ideal system be an ecosystem of methods that are easy to implement, they're easy to choose from, they're available for users that want to write their own in a secure, trusted fashion. Because ecosystems are more resistant to generic attacks. We want to offer modalities that are not traditionally logged like audio. Because we want to make attacks harder not because it's impossible to log audio, but because if people use it, then it has to be done and it makes the attackers job harder. And these methods are just examples from a very, very large potential space of methods that could be used. So it's like a spy needing to be fluent in every single language in order to do his job properly. Makes it harder. Imagine if everyone logged in by a different method, then generic attacks would have to concentrate on the infrastructure like the browser. And then we can concentrate our defense on those points too. We haven't done user studies on this stuff. We might, but again, the point is not to pick one or two methods and say, this is the best method, you should use that because then it's not customizable when we've gone back to a generic system. It's to say, you have the power to choose what works for you. And that leads me to the idea of desituating the interaction. Especially back at the start when we were talking about ATMs, the problem with those terminals is that the interaction needs to be done at a predictable physical place with predictable hardware. And a common criticism that people level validly against the haptic keypads and so on is that there's a reason why ATMs all use a pin pad. Everyone needs to know that the interface is gonna be the same and that they're gonna be able to log in, even if it's in a foreign country or wherever. So we need to look at ways that hardware can be used to desituate that interaction. We wanna use different pin entry schemes like the web example, but we can't expect ATM manufacturers to include every weird interface device that people in universities come up with. But lots of people carry around these private digital devices like a phone. And we can install whatever the hell we want on that, you know, unless we follow Apple's rules. And we wanna make the interaction less physically situated. And the private device does this too because we can authenticate to the device wherever the hell we want. And then we can use the device to authenticate to the terminal. So it moves the problem from one of authentication to one of communication. And there are still some constraints on this. We don't know in advance what terminals we're gonna use. So we can't prepare. You can't pair your phone in advance to every terminal you might possibly wanna use in the future. And we don't wanna use something that radiates information in all directions and has the risk of a man in the middle attack. And finally, it's gotta be fast and easy or people won't use it and it's gotta be cheap or manufacturers won't use it. So here's a graphic of the interaction. You authenticate privately. You use your private device with physical proximity to communicate an encrypted credential to the terminal. From the terminal's point of view, it looks like piece four. It's just like you entered your PIN right at the terminal. So here's a prototype of a system that performs this communication using light. You enter the password by whatever means necessary on the phone and then place it on the receiver where the thing is transmitted with light. And you can see a lot of flashing leaking out from that. That's because there are specifically LEDs in there to introduce visual chaff so that to prevent any recording and replay attack. We don't have a user study for this yet. It's been done, but it's under submission to a journal. So we didn't wanna pre-release it here, but suffice it to say that users were happy with it. Here's another graphic of how it works. And the important thing to note with this is that the password is not transmitted in the clear. So even though there's some observation resistant stuff with those spoofing LEDs, it's salted and hashed. So it's of less use to an attacker than a clear transmitted password. And the hardware here, which is very, very simple, a microcontroller, some LEDs and a light sensor, very, very cheap and reliable, less than 1% error rate. The next version uses the color screen so that more data can be encoded within the same transmission time. So it can be a longer hash by still being usable. Andrea also did a version that looked into using a variable magnetic field because the field strength or the observability of the magnetic field falls off much, much faster than it does for light. So it's more difficult to observe. But this method and any further work on this method is currently on hold because it's actually really similar to near field communications, which is gonna become commercially available, probably in every phone very soon, maybe even as soon as iPhone 5 this year. So no plans to do more work on this yet until we look into that and play around with that some. So in conclusion, we're gonna have to live with passwords and pins for a long time. We know that they fail in lots of ways and they suck in various ways, but they're not going away. We still need to authenticate on public terminals. We're not in this fully connected world where we can do everything on our private thing quite yet. But generally simple methods can result in security improvements in scenarios where there's a potential observation risk. There are things that we can do not to achieve perfect security. There's no such thing as a perfect defense. But no matter who you are, if you're a manufacturer or an end user, it's not about defending against everything. It's especially not about defending against everything for the service providers because they care a lot more about minimizing losses to themselves after the fact than they do about protecting your credentials. In particular, they don't give a shit about protecting your credentials used on other sites even though you may be reusing it for their site. They just, there's nothing they can do about it. They're just gonna work on loss mitigation instead. So we wanna diversify the ecosystem of entry methods on our own bad. That's kind of the hack of spirit. Like don't worry about these guys, let's do it ourselves and do this mediated obfuscation of the data that we do have to enter. So we showed some novel key entry systems for terminals and private devices and some software and hardware mediation systems for observation resistance when you do have to use these public terminals. And I know, I hope that you guys are all thinking about potential attacks on these things because that's how we do it. We take the armor to the bullet guys and say make a bullet that goes through this armor then we take the bullet, take the, you know what I'm saying. Armour to the bullet guys, to throw the armor, bullet to the armor guys, make armor this doesn't go through, that's how it works. But at least it forces attackers to work harder and maybe they'll go and bother someone else. Thanks.