 Welcome everybody to Passwordless, a story of risk protection and excellent UX by Kelsey VanHasta. We are glad Kelsey can join us today. So without further delay over to you Kelsey. Wonderful. Thank you very much and thank you for coming everybody. I'm delighted to work to see you here and it's a privilege to be able to present this afternoon. I'll share my screen if I can work the technology. Okay. So yes, just so you know. It actually doesn't matter how many times I present at conferences and present particularly this session which I've presented a couple of times this year. I'm still nervous. I will admit that right up front. Anyway, let's get started. So, I'm going to talk today about the security holy grail, a way to reduce risk, protect high value accounts and deliver an excellent user experience. It's pretty rare you get all three of those in one go. And to provide you with some context about my role I work with ThoughtWorks. I am the product owner for global identity at ThoughtWorks. My role is primarily internally facing and I lead a remote first globally distributed team. Quite a few of my team members are in India, maybe some of them are here today. So the sun basically to deliver acts identity and access management services to about 10,000 also ThoughtWorkers across the globe these days. That's me. Okay, so this is how I hope it's going to go. Well, I'm going to talk briefly about passwords in general, why they're awful. And then I'm going to talk more broadly about password less modern authentication and how it promises a much, much better alternative. And then finally I'm going to share with you our experience our experiment at ThoughtWorks with password less what worked what didn't work so well. I'm going to share some of what my customers so other ThoughtWorkers thought about the experience. So let's start with passwords. And before we do, here's a little reminder about the joy of passwords. What fun it is. Research from October 2020 reveals that the average individual has more than 100 individual passwords to remember. I wish I had only 100. That number is only growing and that is unmanageable. In the ideal world, every single one of those are unique. But we know that that is not true. And the bad folks know that it's not true as well. People just want to get things done. So they're always going to take the path of least resistance. And often that means using the same password for multiple logins or developing a probably predictable pattern for their passwords. And people also share passwords. Hello, Netflix. So I'm an IT administrator. How can I stop you reusing your Pinterest password for work? Obviously, I care about security and I care a lot about the security and the corporate assets that I'm responsible for. And I would really, really like you not to use your password that you've used for your social media, favorite social media or shopping site, etc. for work. So I'm going to insist that your corporate credentials have some rules around them. Probably just like your employer. I'm going to set a minimum length. I'm going to require that you include some uppercase characters, some lowercase characters, maybe an alphanumeric character as well, maybe a special character. Oh yeah. And I'm also going to make you change it for something completely different every 90 days or so. So I've just made your life hard. And I've probably annoyed you too. Despite all of that, databases are dumb, people are smart, and my password 123 probably meets the requirements. Also, nothing stops you from using this new secure password in multiple places, writing it on a sticky note, sticking it on your desk, or sharing it with your housemates so they can watch Netflix too. I'm not even going to discuss how the bad folks respond to these kinds of rules other than to say that they're really not worried about them at all. So what about password managers? Well, a ThoughtWorks, one of the benefits we provide to every ThoughtWorker is a family subscription to a really well known password manager product. As well as access to a corporate password manager so that they can manage their work related credentials. Uptake of the benefit is very, very good. Most people avail themselves of it, but still not everybody. Sadly, the people who are least likely to champion the use of the product are the users that we have for whom technology is not a speciality. These people have a different speciality, they're finance specialists, they're HR specialists, they're non technical leaders. And arguably these are often the people with access to the most critical data. And they're really busy, they have the least amount of time and attention to take care of this stuff. And on a personal note, I don't know if you've ever tried to teach someone to use a password manager from Absolute Scratch, particularly someone whose expertise is in something other than tech. I have, and it's really not easy. In fact, it's really very easy to get yourself into a mess. And some people legitimately do have concerns about the security of having all their credentials stored in a single password manager, or about losing access to their passwords. So a password manager is great, but it's not a silver bullet. And a weak, easily guessed password stored in a password manager is still a weak and easily guessed password. So let's talk about the best password at all. No password. So what is passwordless? Much like it says on the tin. It's a way to access the system without using a memorized password. Passwordless uses a public private cryptographic cryptographic. That's a hard word to say key pair. The public key is registered with the authenticating service, in our case, your identity provider, your IDP, and the private key is either kept on the user's device or is a hardware token. The really nice thing about passwordless is when you're talking to your customers or your users, words like cryptographic key pair and authenticating service, which makes folks eyes glaze over are actually really transparent to the end user. They don't need to know about any of this stuff. They just need to know how easy it is to to use. Here's a little diagram because in a previous life, I was a business analyst so flowcharts and everything. About how it works. So the first step, the user provides some kind of identifier or username or an email. The system prompts you for some kind of pre registered identifier that's a security key or often we're very much a Mac shop so very much the touch ID on your Mac is acceptable. The system then evaluates behavior and goes okay here's Kelsey is she logging in from Melbourne like she always does on the device that she always does. If the answer is yes. Signs me straight in. If the answer is no, and in a non COVID world I've traveled to the US or the UK or even India to see my team that I'm considered no risk low risk or not low risk. The system will then challenge me for a second factor that could be something like in our case a verification app. And we support quite a number of those provided my second fact my other factor is also valid. My identity is then verified and my access is provided. If I can't provide this additional step up, then access is denied. But generally speaking, for most end users the process is seamless. It's fast. It feels like magic. And for systems admins and infosec teams. It means that you've now got really strong adaptive intelligent authentication. It's a piece of mind and heaps less failure demand because if people don't have passwords, you don't have to do password resets. It also gets you a fair few steps forward towards operating in a zero trust environment but that's a whole other talk for another day. Lots of people say to me password list is just like MFA. Oh I'm just logging in with MFA. MFA is important. You should turn it on wherever it's available. But like password list, it has weaknesses. Lots and lots of systems only offer MFA via SMS, which is very insecure in itself. There are many places in the world where stealing someone's phone number is pretty trivial and certain types of MFA are vulnerable to man in the middle attacks depending on what network you're working with. Experiences and admin tells me that phones are lost and stolen all the time and people still don't secure their mobile phones with passwords or biometrics or they use weak pass codes like 0000. And then there are further challenges. People travel. They don't have access to their mobile number. They drop their phone in the sink, for example. Lots of things can go wrong. But password list is actually much because of the way that it uses the key pair is a step up from MFA. So for an organisation, what are the benefits of password list? If you want to introduce this to your organisation, there are some pluses. There's significantly reduced failure demand from lost or forgotten passwords. You don't need to write password policies around length or complexity or cycle time. I don't know how many hours of my life I'll never get back writing policies. It makes the onboarding process for new employees quick and simple and super easy. And this is the one I love the most as a systems admin. It completely prevents credential sharing can't share my Netflix password with my housemates anymore. So adopting password list actually means that from the corporate perspective there's a whole lot of things that you actually don't need to do anymore. You have complete confidence that authentication is really strong and credentials are not being shared. And what are the benefits for end users? Not much to say here, better security and a much, much, much better end user experience. So there's a catch. There's always a catch, right? There is an adoption curve for internal IT and for end users. Potentially there can be costs but not necessarily. As I mentioned earlier, we primarily provide max to our employees. Those max have a touch bar and you can use the touch ID as a web. Web end authenticator. So we use what we had. There was no cost for us. Potential for a single point of failure depending on your implementation. If you choose to issue you be keys or some of the form of security key, there might be some management overhead there. And of course moving to password list is a change and will probably require some conversations, not least with your information security team. And just to start with, there could be costs. Telling a busy non tech focused end user that you want to completely change the way they access your systems may not be met with great enthusiasm. So yeah, there are always issues. But not many. So we tried it. And this is what happened. Bit of context. We're a consultancy. We work with clients solving their most difficult technical problems. Most of our employees don't work from our officers. We have very little corporate on premise infrastructure. That's not true in every region, but in most regions, there's very little. We do not have an internal network or local file shares. We don't have rows of PCs sitting on desks attached to the network. That's not a thing. All of our internal applications are SAS based, including our IDP. And we do things a little bit differently. We work very hard to make sure that corporate it does not get in the way. We do manage our it assets, but with a pretty light touch we are not our mission is to be not creepy. We do support BYOD for primary non primary devices. So yeah, you can BYOD your phone or your tablet. And we don't and didn't want to adopt the overhead of issuing and managing security keys or hardware tokens. So initially when we were first looking at password lists, it looked like it might be quite hard for us to do because it was dependent on paper things that we just didn't have. But then a couple of years ago, there was an absolute game change game changer or two, actually. Broad support for FIDO 2 and web or then and for the technical people among you FIDO 2 is a set of standards that specify how users can securely authenticate to Internet device Internet services without relying on a password and web or then is the WC 3 standard for authenticating devices so hardware or biometric tokens. Web what how it works is web or then enables online services to use FIDO authentication through some kind through a standard web API that can be built into browsers and related web platform infrastructure. For us this was magic because it meant, as I mentioned, every single laptop that we issued had some kind of biometric identifier built in touch ID face ID. Now has they now have a built in web or then I didn't authenticate the problem of issuing physical securities keys to people went away, we didn't need to. And secondly, our IDP release some functionality that allowed us to generate adaptable sign on policies supporting credential chaining. And that's the process that I talked about earlier where if I'm my behavior indicates a non low risk login. Our IDP will step up the security and ask me for another credential in the chain so those two things made a huge difference for us adaptable sign on sign in policies here have been particularly important. Because they mean that we can look at user behavior and make judgments about whether that user behavior is unusual or whether it's within a set of normal ranges. We can also set up different policies for different groups of users, depending on risk, for example. So how did we do it well we applied hypothesis driven design. As systems admins. We spend a lot of time verifying people's identity and resetting passwords to set a user's part reset a user's password requires on average four to five back and forth interactions between it support and end users. It's slow. It's painful. And on top of all the problems that we've already talked about in regard to passwords. It's a lot of failure demand. So our hypothesis was basically focused on reducing this failure demand. And this was our hypothesis. We believe that using password list to sign into thought work systems and services will result in a faster and more convenient and secure end user experience. We designed a test for our hypotheses. We used a credential chain combined with babe behavior detection which I've already talked about a little bit. We called out for volunteers who met our requirements. In other words, they had a touch ID. They had the required verification app installed on their phone. And they were willing to try it out with some caveats. It may go wrong, but we're here to support you if it does. We required people to register their own web authentication token and that could either be a physical key or a biometric. It was up to you or both. That was fine. Plus we wanted them. We had to ask them to enroll into our verification application. We ended up with initially about 120 volunteers in a range of roles and based across all regions. We also directly targeted some high value accounts and by high value accounts I mean users who have access to the most sensitive and complex data and invited them to join the trial. And then we sat back and we learned and we gathered some feedback. And we found a few things weren't quite as seamless as we expected. One of the things we did discover was you still need to set an updated compliant password in our IDP. Even though you never used it because we did still have some systems that required you to have a password. We also found that some browsers didn't support web or then and people are pretty keen on their favorite browser. Particularly Firefox was a challenge here. The use of web or then and touch ID is not supported in Firefox currently and we had a number of people who really liked using Firefox. And we also found that there was some odd bits and pieces of command line interface technology that still required a password that we couldn't use passwordless with those so that excluded a couple of people. Since then we've actually solved a number of those problems so this was much earlier this year. Gathering feedback. This is the kind of thing that people who are using passwordless say to me. They loved it. It is so rare that I get somebody who doesn't like it or for whom it doesn't work. People absolutely love it. I would have to rest it from their cold dead hands to take it away. These are some of the people that some of the things that people say. It's a very low friction. I used to curse octa credential challenges. Now I barely register when I have to log in again. Not having to go through one password every time I wanted to access something in octa has integrated well with into my workflow. Secure authentication without security compromise doesn't rely on passwords which may or may not be strong enough. Safe and secure easy way to log in. I don't have to depend on other tools or machines. And the most common bit of feedback I got was people I can't imagine going back to the old way of doing this. So that's pretty good. I'm pretty happy with that. From an IT perspective because these things matter. No access issues from the trial group. Really very, very few problems apart from the ones that I highlighted earlier have come up at all. Most people just touch and log in and carry on with their day. A small number of people found new and creative ways to paint themselves into a corner. For example, registering a biometric on a phone and then finding it doesn't give access on the laptop. That's was an interesting one. Some of the terminology that we used web or then cryptographic key scared some people off. They thought, oh, this is too complicated for me. And for us, you do still need to remind people that they need to update their password when password cycle time comes around because you do still need it for some odd things depending on what you do. From an organizational perspective, what value did this deliver to my organization? The cost implications for us. We used what we already had. So it was great. Not complicated at all. No mass organizational change project required small change and security policies. Lots more confidence much improved confidence around securing access, and really significantly reduces exposure to potential attacks on the organization. So wrapping things up. What's not to like. This was straightforward to implement. It's an excellent user experience. It's low effort, low cost, reduces value demand and IT support costs, provides a much better security, and it makes security teams and auditors happy. And that's important. What's next. And again, because this was earlier in the year. Passwordless is now available to anybody who wants to try it. We're still experimenting with making some more use of the behavior detection technology available to us. In both directions, for example, making it even easier to log in for highly trusted users or people who are on a trusted device. Additional technology shortly to be made available via our ID via our IDP is likely to move as yet another step forward to the goal of zero trust where the device itself really does become the organizational perimeter. And finally, we'd love to encourage you to try it. Consider a trial of your own. We are fairly sure that you won't regret it. And that's my talk. I have a couple of minutes for questions if anybody has any. Thank you so much, Kelsey. Just a reminder to everybody in the Q&A, you can enter in your questions or raise your hands. And we'll try and take some questions before Kelsey needs to drop. I have about 10 minutes. My questions are quite audience today. It was either incomprehensible or completely clear. Or not what anybody expected. Oh, here we go. We have a question. Right. Okay, this is a great question. So the question is in the situation where a person were to lose a hardware security key. How would the passwordless ecosystem handle that? Okay, so you actually can remove or change your own security key because we require that you have two options to authenticate. You can use your second option to authenticate and remove the security key that you've lost. If you've used your laptop touch ID and you've lost that, then you've probably got bigger problems and you're probably calling it support. But generally speaking, the security key that you use to log in is your responsibility. Pretty much like your password is your responsibility, but you can resolve that problem yourself. So for us, the question from Yogesh, what are the applications for which passwordless is implemented? So we have all single sign-on software as a service applications that are all accessed via our identity provider. I've already given it away. That's a octa. So if you can access octa, which is protected by passwordless, you can then access all of our applications via octa. Oh, here we got another one. For the banking environment, I would love to see this implemented in the banking environment. One of the greatest frustrations to be is that the banking industry tends to use SMS and passwords as a form of multi-factor authentication. And generally, their password requirements are really weak and SMS is the least secure method. So implementing something like passwordless, allowing people to use a security key or a token would be a huge improvement in security. There's a little question that's come up in the chats. Is there a library for passwordless? Yes. Head over to WC3 and all of the libraries and the protocols, they're available, they're open source. So, yep. For existing registered customers is the question. Well, for us, it was all existing customers and we used some of the smarts behind our IDP to put people into a group where this particular password policy was available to them. And it was really as simple as that. We moved them from one policy group to another policy group. Very straightforward. Well, Kelsey, thank you so much for a fascinating session. It was my pleasure and thank you everybody for your time.