The Hacker Mind Podcast: Going Passwordless

Passwords are everywhere, but they probably weren't intended to be used as much as they are today. Is there something more secure? Something better? Yes.

Simon Moffatt from CyberHut joins The Hacker Mind to discuss how identity and access management (IAM) is fundamental to everything we do online today, and why even multi-factor access, while an improvement, needs to yield to more effortless and more secure passwordless technology that’s coming soon.

The Hacker Mind is available on all podcast platforms.

[Heads Up: This transcription was autogenerated, so there may be errors.]

‍

Passwords.  Either they’re too weak -- and therefore trivial to guess--, or we reuse them, which means an attacker can use them to gain access to multiple sites. Maybe you are at an organization that requires you to change your passwords every 90 days or so, and so you have password fatigue -- there are only so many variations you can do every 90 days or so.

One of the eight required domains in the current CISSP certification process is Identity and Access Management, or IAM. You might not think of it as a major aspect of security and yet, stolen credentials are really the key to data breaches today. Why pop a zero-day when you can just unlock the front door with someone else's username and password, especially if no one bothered to change it from ADMIN or better yet, only used one password across multiple different systems. So we need passwords, but passwords just aren’t perfect.

Okay, how exactly did we get on this treadmill with computers? Fact is, we’ve long had passwords as a credential. For example, here’s Jerry Lewis in a scene from a 1950s film, where he’s trying to break into a Nazi German military base.

Lewis:  Good. Good. 

Other: Wait. I must have the password. 

Lewis: Oh, well, if you must have it, that’s wonderful. I’m glad you have that.

Other: What, please, is the password?

Lewis: You said you have the password.

Other. Yeah, but how do I know that you have the password?

Lewis: You didn’t say you knew I has the password. That password. You know that password?

Other:  You must have the password.

Lewis: Well, if you have it, then protect it. Stay with it. Don’t loose it. Keep it forever.

Other: What is the password?

Lewis: How do I know you have that password?

Other: I have the password.

Lewis: Well, then, why do you need it again?

The first use of passwords with computing systems dates back to around 1960 when Fernado Corbato at MIT first introduced the concept. Back then, these were dumb terminals on a smart mainframe so computing time was shared among many people. Everything was stored on a single hard drive disk so in order to keep individual files private, a password was needed for individual access, granting the user access only to specific files. 

So why do we still use passwords today? In part it’s because it’s part of the larger identity problem -- how do we know who’s on the other side of a connection? To use a service, we enter our user name and a password. But this method of authentication is flawed; either hashed or hashed and salted, usernames and passwords can still be stolen and reused. And credential stuffing attacks are on the rise, and behind some of the biggest breaches we see today.

So there must be a better way. And there is. In a moment, I’ll introduce you to someone who’s been working in the Identity and Access management space for nearly two decades. 

{music]

Welcome to The Hacker Mind, an original podcast from ForAllSecure. It's about challenging our expectations about the people who hack for a living. I'm Robert Vamosi and in this episode, I'm going to be talking about identity from the perspective of a computing system, how all those online service and consumer devices we have in our home know who were are, whether it is through passwords or MFA or even the brave new world of passwordless identification. 

[Music]

Vamosi: Consider this, a quick Crunchbase query reveals that since January 2018 there have been at least 159 funding rounds related to authentication technology – resulting in a staggering $3 billion of investment in IAM-related startups overall. And, as I produce this episode, there’s a startup in the IAM space that has recently secured $50 million in Series B funding. So there’s something there within IAM. So I reached out to an expert in this field. 

Moffatt: I'm Simon Moffatt and I'm a founder analyst at a company called Cyber Hut. I've been either lucky or fortunate to spend just over 20 years in the identity and access management space just through luck and chance and, and booked with industry in different software vendors and such and it's been really fascinating to see things change in the identity space. Really, it's you know, when I started off over 20 years ago, it was things where you did everything by hand, you manually set up accounts within target systems, you manually reset people when they were in a helpdesk, and people didn't use MFA. They didn't use mobile phones. It didn't use biometrics and stuff. So the things were very, very manual and it was a very much IT security thing, whereas you sort of spin forward 20 years and identity is so pervasive. We use it every day sometimes without even realizing and I feel quite privileged I guess to witness all of those changes for good and bad. Of course, there were some guesses and backward steps there too, as well. 

Vamosi: Simon and I used to work together at an Identity and access management company.   

Moffatt: And now I work as an independent analyst so I have a job that we're speaking with different vendors speaking with end-users and customers and understanding really what's happening in the identity space, what technologies are emerging and what problems exist and it's quite as quite nice job

Vamosi: Identity -- I’m talking specifically about authentication and to some degree its follow-on authorization -- is one of the most important, yet least talked about aspects of security.

Moffatt:  You've hit a really interesting point people, the hacker community, the dev community, they don't associate identity, right, being useful being part of the security problem, which I think is actually part of the problem because what we're seeing now is identity is hugely front and center of workforce and distributed consumer identity. everything online. But the dev aspect is very much on building the application and then testing the application. And this security stuff is like it's got to go somewhere. It's like all the security guys. They'll fix that where it's actually identity now. It's hugely important for ministration login, subsequent visit like the whole host of use cases and it's like, who's gonna do that stuff, who will own that who will manage it, maintain it developer etc. So um, yeah, is up sometimes risk of falling into a black hole of, of doom, know that there's a lack of ownership

Vamosi: So let’s define some terms.  What is identity?

Moffatt: So it's interesting, I think, traditionally, identity was very much employee-based. It was focused within the workforce. Number one, because typically that was a problem which needed to be fixed. You were very much concerned around, making sure staff were created and set up appropriately to do their job. So the identity inverted commas aspect was basically you try to digitally describe a person that you had employed that you were paying somebody to go and do a particular role or function within the business. 

Vamosi: So identity is used to onboard employees for their jobs, to sign them into systems, and conversely lock them out when they leave.

Moffatt: So weirdly, the identity was a set of attributes, which probably came from some sort of trusted source, which is typically the Human Resources system and you provide your attributes, your first name, your last name, maybe I'll dress perhaps maybe your driving license number and other things into this secure source and that will be used to describe the identity in the confines of an employee or is somebody working for an organization now? That's quite a narrow definition. 

Vamosi: And it’s not just in the work environment. If you look at Shakespeare, a majority of the plots revolve around mistaken identity -- people pretending someone they are not. 

Moffatt: Really, we all have the concept of identity outside of the working environment. When we travel, for example, to a different country, we have this thing called a passport, you know, this physical thing that we hold in our hands. We use this physical thing to represent ourselves to the border control guide. And I think that probably the one which most people resonate with is this physical document, which again, has some attributes and fields, some pieces of information in there, which somehow represents this physical person to somebody else. 

Vamosi: So these scraps of paper or digital records, they combine to somehow prove you are who you say you are.

Moffatt: So there's a set of attributes. There's some information there, and somehow it's trusted. And that's a really weird subtle thing we take for granted that you trust a driver's license, you trust the passport you trust, the credit card, something that some attributes information on there, and you present that to somebody else and they look at these weird fields, first name, last name, date of birth, etc. And they trust this, these pieces of information somehow, this automagic link between this list of fields and a physical person sort of automatically happens. And yeah, it's a very strange thing. Identity. It's quite difficult to define, I think. 

Vamosi: So what then is access management, the AM of IAM

Moffatt: The next piece of many jigsaw puzzle components, I think of the identity thing as trying to ascribe something that's a physical entity, a person or maybe sometimes it's a thing in the modern world, and this access management stuff is really about identifying what a person can do. So in the identity world you have the identity that gets defined, you have authentication to try and work out who this person or thing is in that sort of repeatable manner. And once you've done that, you have the access management stuff, which is the next piece which is okay, I know it's Simon or Joe Bloggs or whoever, what can they do, what can they do within a system? What can they do within an application? What can they do within the workforce, although this sort of job and sort of landscape we try and work out what they can do, which is the definition of authorization, essentially, this is Simon, what can he do today? What is he allowed to do in a particular system and that's another very complex and it's certainly detailed world.

Vamosi: Is it interchangeable to say access management and authorization or are they distinct? 

Moffatt:  Um, I think access management is probably the more overarching term, it's the general umbrella which contains things like authentication, authorization, rule, set policies and all the sort of nuances within that. So I think access management is becoming this broader umbrella term, if you like, which decides what people can do within systems, how long they can do it for as well as things like sessions and context and adaptive controls all start to sort of fall into this umbrella of access management. So I think authorization is probably more specific or focused. Access Management is probably a sort of generic umbrella term, I think

Vamosi: The problem, then, is that our modern identities, our sophisticated access management systems, are still tied to something archaic like passwords. I mean everything should have its own unique password, right, but to do that, you need some sort of management system. When I wrote the book The Art of Invisibility with Kevin Mitnick, he and I went around and around on the subject of a digital password manager. He loves password managers. I do not, preferring old-school mnemonics to create and store strong passwords. 

Moffatt: Oh, it's a really good one and you can ask 10 people and you'll easily get five different answers and you definitely get the two counts. I use a password manager. I use one every day. We were actually frowning at my password manager this morning. I don't want to name which one I use, which I pay for as well. It did make me incredibly frustrated this morning. So I couldn't log back in at night to reboot my laptop and I had to log back into my password vault and key. I was in this cyclical leap of not being able to log in. I had an MFA enabled device. I couldn't log into that and it then sent me an email to verify my login but I couldn't log into my email. I didn't want my password manager. So I could pass the password into my email. So that was a frustration but in general, I think they help.

There's a caveat to this of course because they essentially elongate the use of passwords still. It's in the sticking plaster you know it allows us to continue using passwords and yeah, they're really good at generating secure passwords you can generate a 20 character unique password with the you know the special character alphanumeric uppercase, lowercase letters, etc. They can do that. That's great. They can make unique passwords. That's great. They can audit your passwords across multiple sites, if you're reusing things or perhaps if there's been a breach they can set things automatically. That's a great use case. But the flipside, of course, is it allows this ecosystem to have usernames and passwords to still exist essentially and proliferate. So it's against this sticking plaster style process and it's allowing passwords just to exist. Unfortunately, it's like an overlay, an overlay sticking plaster on top and I think at some point we are going to have to accept that passwords should be consigned to the legacy technology scrapheap and we should try to move to something new. 

[Music]

Vamosi: So passwords are everywhere, and they probably weren't intended to be used as such.  So where are we with Identity and access managment 

Moffatt: Um, I think identity has really emerged as such a foundational technology. I think it's always been important for intervention early on for the entire country in the sort of use cases of passports and driver's licenses that's been around for quite a while. And then the employee spirit in managing employees and contractors has been around really since since computer age. 

Vamosi: So we talked about different forms of identification, how you might not just need to have one, like a driver’s licence, but two, a passport as well. It seems to me that that's where we get into multi factor authentication, that the composite if different forms of ID tells someone who we are. Yet for the moment, we seem to be stuck on just using username and password … for everything.

Moffatt: Yeah, that's right. That's exactly right. An authentication workcamp is typically used to be this username and password combination, something we're familiar with. All day every day I would log into six or seven applications and websites today with usernames and passwords, which are everywhere, unfortunately, and the weaknesses of that are pretty well known.  I think usernames and passwords are, there's no cost to build an application and put a username and password in there. So by that, I mean, if your developer libraries are available, it's easy to do. It's easy just to apply usernames and passwords within a particular setting. Unfortunately, there's a whole host of different security failures with that approach, thinking quick Google search. Last time I did it was why our passwords were bad. I think it came out at about 24 million hits on Google. 

Vamosi: Okay, I’ve probably written a fair number of those articles on why passwords are weak or just plain bad. I know I’ve written about how criminal hackers can smash and grab hashed passwords then using HAshCat or John the Ripper work out their clear text equivalents, and then use those credentials elsewhere. 

Moffatt: using usernames and passwords is known, essentially to be not great user experience and be the numerous ways that that can be a vulnerability attacking method. So we started to see this introduction of the multi factor authentication aspect. 

Vamosi: There are three factors to authentication. One is something you know, like a password. Another is something you are, like a biometric. And yet another is something you have, like a chip or a dongle. Having two is 2 Factor Authentication. And having more of these is multi factor authentication.

Moffatt: So it isn't just something you know, like a username and a password or PIN. But it's more about perhaps something you are so it's like a biometric that's tied to your physical entity or maybe even something you have like a mobile device or a physical token that wishes to belong to you and you put it in your wallet. If you make sure you don't lose those things. So authentication then becomes this multifaceted aspect. So it's typically something you know, which the username and password and then probably something you have as well and maybe something you are and you try to select two of those three, and it's the concept being there's, there's multiple channels that adversary needs to essentially breach or attack for, for them to be successful. And there are multiple different ways of doing that the MFA aspect, some of which are, I guess, more popular than others, but I think all of them tried to satisfy this security and usability conundrum, the security and usability almost always collide. They're always in conflict. I think MFA is really at the forefront of that collision, I think. 

Vamosi:  So now you type in a password and your phone buzzes with a limited time password sent via text. That’s two factor authentication, and it’s certainly much more security that just user name and password alone. So does the use of other ways of authenticating a user start to get us to passwordless? 

Moffatt: Yes, that's a great question. It's a great question. So we then have this MFA aspect, which is really the sort of sticking plaster if you like to try and fix the vulnerabilities with usernames and passwords. So classic bond is something like sending one time passwords, perhaps to a mobile device via text message or perhaps sending a one time password via an email. Neither of which are particularly great from a usability perspective, and honestly neither of which are particularly secure either from a sort of adversarial prevention perspective. So some of the MFA starts to get more advanced. We start talking about push authentication where something gets pushed to your device, maybe a notification and maybe swipe to accept it or click a button to tickets, and they know that it's improved security. 

Vamosi: Changing people’s behavior is hard, you have to incentivize them to do something differently. Adding more friction to a login or purchase -- while it is great for security -- is not great for the user. They will resist. Fortunately, there are simple steps to make the increased security more on the backend, to make the usability better.

Moffatt: Usability is becoming more improved with each passing six months, these abilities get better and better. But typically, most MFAs still rely on some sort of shared secret, something shared between me as an identity and the service that you're engaging with. It'd be a seed or some sort of component which can generate one time passwords or perhaps a key which is shared between the device and in the service itself. So we're still in this realm of something you know, is the law, a password based concept, something which has to exist on the server side and on the mobile device side on the client side. 

Vamosi: So there’s a move toward passwordless access. Which is weird because we’ve built up this trust around self-generated attributes. Now we’re looking at something else.

Moffatt: Passwordless really is trying to move us into a new era. So we're not relying on something that the person has generated like a pen or a secret or password. It's entirely reliant on something different, which is typically a cryptographic best challenge response style process. So there's nothing there's no secrets is the keys that can be sort of generated or shared, but it's using cryptography which is typically symmetric so as a private key and a public key. And there's a challenge mechanism between the service provider and maybe the mobile device. To identify if you have possession of these private keys. So there's no there's nothing shared there in the sense of pins passwords.

Vamosi: So isn’t this just MFA on steroids?

Moffatt:  I think that that's quite a subtle difference where the MFA world often needs a username and password first and then something else happens like a push notification for example. Whereas in this passwordless world, I said very different flows very much could be reliant on biometrics, it could well be reliance on cryptography, but it's nothing reliant on it on an email address and a password those things not really a prerequisite to make that stuff work. 

Vamosi: So I keep thinking in the back of my mind, there's something around tokens. Is that related to the keys and the seeds that you're talking about? Or is it something totally different? 

Moffatt: I think tokens are typically what I guess happens once somebody has authenticated so once the authentication event is taking place, and you've identified it, yeah, this is some Simon coming back. And we've gone through this authentication process, maybe a biometric on a mobile device, and it's been some sort of clever cryptography going on in the background and it's sort of a challenge response style process. Taking place. Once that has completed successfully. Then we sort of get into the realms of things like access tokens and Id tokens, which then get issued to the device or to the interaction which is taking place and I guess these tokens are really the sort of the output of the authentication process which are objects which can be passed around between different API's and different web services to essentially represent my identity for a limited duration, perhaps one minute or one hour, but a relatively short period of time and these tokens can be presented to lots of different services and they essentially acting as the proxy to my identity for like, I present my ID token to say like this, this is Simon this these are some attributes or claims that represent who this person is. But the ball Nick got has a relatively short lifespan to be when the token expires, because it'll have a sort of expiration date or time associated with it. You have to go through the process again, you have to get a new talk and then get a new representation of yourself or maybe an access to which can represent what you can do to those downstream services. So the tokens are very important and they are really sort of an output of the sort of authentication event.

Vamosi:  So unlike passwords, which can be reused over and over to gain access, having a token to a specific aspect of access that automatically time bombed, it does an attacker no good to seize these tokens. 

Moffatt: Exactly. Yeah, exactly that I think it's like any sort of basic security premise you want to be, you want to be limiting any sort of attack, vector flag or any sort of attack landscape and reducing that through segmentations to sort of limit anything which can be stolen or intercepted or used, limit the impact of that. And you can do that through reducing the scope on those access tokens. So what those tokens can actually do is limit access to these privileged style concepts, they're limited through time, as you mentioned, so if you do issue a session cookie or an access token, make sure those tokens are issued in a very, very short lifespan, seconds minutes, for example. So if they are stolen, the impact is lowered. 

Vamosi: Nothing is fool proof.

Moffatt:  We talked about risk, is it a sort of general concept you talk about the likelihood of something occurring, and the impact of it occurring and sort of two big levers, people pull in this sort of risk management landscape and the likelihood you probably sometimes can't do a great deal with the impact? Of course you can and you want to reduce the impact of adversarial activity and reducing the scope. of something reducing the lifespan of a token or a cookie is something pretty simple levers that service providers and developers can use to stop the impact of a theft. You sort of have to assume you will be breached. Number one, tokens will be stolen passwords have been breached even MFA components could be compromised as well. So you always start, start thinking around bad stuff is going to happen and how can I reduce the impact of that and these privilege, reducing the scope of tokens or what can these tokens do making making sure they are as limited as possible without of course impacting usability and time is a great one, just reduce the exposure for something that don't have tokens, which last hours now is weeks and weeks and months before you have to sort of revalidating because clearly, an adversary could conceal that within the first second, and they may then have a very long window where they could do bad things. 

Vamosi:  So turning that around, then stealing the keys or the seed would be something that an attacker might do. And so the security probably needs to be heaviest around that aspect. 

Moffatt: Yeah, that's really interesting. I think the more you look at authentication in general, as promised, we will miss great strides improving authentication of past three or four or five years and the I guess the bigger the walls the the better will become a formula authentication, the adversaries typically lazy that they're going to they're going to find the the easiest method of AMI data breach or gaining access, which they they shouldn't have. So today, we'll go for the low hanging fruit. So if we move away from usernames and passwords and the ability to steal a password, for example, we leverage MFA. The adversary is probably going to try and find the thing which has the most value which could well be the private key or noise so there's a seed to a one time password generator. So the adversary starts to move their horse pipe and tries to find the the biggest reward the effort that they're going to put into these things and suddenly you start to move on to the next level, which is things like maybe social engineering or perhaps methods of coercing the user out of their authentication capabilities to phishing sites. So maybe, you know, the sort of social engineer the end user believes they're logging into a correct website for example. So absolutely, we can prove protection, certain things, but you sort of left shifting the problem a little bit. And if we rely on things like MFA or okay, you need to then protect the seeds, the private keys, the things which are being used in those sort of challenge response mechanisms as well and you have to protect notes and it's the key it's like the keys to the castle style use case you know, in in soft privilege access management world if, if you have one master password, which perhaps is part of your password vault, for example, well, that's great, but then the adversary may well attack that pinch point. And that becomes the reward for breaching that becomes much, much bigger than that. Is that something we need to be aware of? 

[Music]

Vamosi: So Simon’s been around IAM for a while now. You’d think he has some great stories to share either that he’s experienced or that he knows firsthand through others. Instead he offers a third party site with even more stories and information.

Moffatt:  he is a funny one because breaches, adversarial activity, which is the stuff people interested in but they people like bad news, they like to understand, you know, what's the what's the where's the bad things that happened, whether it's a breach or it's a bad implementation or the gone through a corpus of a breach where the breach notifications occurred? And it's like, well, actually, how did this happen? And there's quite a few good anecdotes is my site in UK the ICO Information Commissioner's Office, which is responsible for data breach management sort of stuff, it's an independent office and they're the guys who give up fines essentially if you have gone through and had a data breach and weren't necessarily doing the things you should have been doing and they issue fines quite regularly actually. 

Vamosi: The ICO is a site in the U.K. is set up to uphold information rights in the public interest. Information rights. As an American, I marvel at this idea that someone might be interested in protecting my right to privacy online, and that if something were to happen, there’s a non-governmental agency set up to help. In most cases, this regards the European Union’s General Data Protection Regulation or GDPR, and in the UK that law continues as the UK GDPR.   

Moffatt: But what they equally do they publish notifications as well. So they publish, essentially the, the analysis of some of these data breach occurrences and what happened, why and why was the fines issued and why was this organization sort of hauled over the coals and then given whatever $50,000 or $10 million fine or whatever, They are quite interesting because you then start to see some of the failings perhaps in design in user management, password management, quite interesting detail there, which obviously, not everybody goes through and reads, but there's lots of valuable information and not just on, ha, look at the bad guys. Look what they've done. Look at the mistakes they've made. It was a good learning experience there as well. And I think it is an exercise, pretty fun to look at those credentials. And those breach reports. If it's a public entity, they typically have to release the information through things like the SEC in the US and companies houses of the UK they have to release information around data breach, how it happened, why it happened, why people are able to, to login with stolen credentials, or perhaps how certain MFA components are bypassed and they are quite interesting stories and I'm not going to go name individual companies, but it's certainly worth it's publicly available information. It's certainly worth a good read. 

Vamosi: In reading those is there something that occurs to Simon more often than not, like, oh, they did that again? Or what?  This other company did that same thing again?

Moffatt: I think just using passwords is a very obvious thing. It's, but it's true. You know, I think many organizations certainly if you look at the consumer facing landscape where you are, you're pulling in identity information from consumers, citizens, customers, you're selling stuff for your government department doing things online. And I think the consistent aspect is, if you're using usernames and passwords, there's some really simple things to do to mitigate the impact of anything bad that can happen. So how are you storing usernames and passwords number one, where are they stored? Are you using a decent hashing algorithm to protect that password? 

Vamosi: In the 1970s, while working for Bell Labs, Robert Morris Sr came up with the idea of a one way algorithm, a means of encryption that can’t easily be decrypted. He called it hashing, and this prevented passwords from being stored in the clear in databases. Instead, systems stored the hash of a given password.

Moffatt: And the subtle difference between encrypting a password and hashing the f1 the cards encrypted, let's just throw cryptography at this problem. Well, actually, well, if you encrypt the password, it can be decrypted. Which key then is another sort of attack points and the adversary will look to find the method of decryption and data can reverse the password. So leveraging a storage mechanism for passwords, which is irreversible, which is a hashing algorithm, which is all quite well known. It's documented. There are mechanisms to do this and because everybody's using usernames and passwords, how those passwords are being stored is pretty simple. There are some things which you can do to advance the storage, using hashing and maybe using salt and distributing where those things are stored. 

Vamosi: Hashing is supposed to be one-way algorithm, meaning that it’s not possible do decrypt it. In reality, bad actors still do in some cases. What that means is that someone could in parallel generate their own hashes with HashCat or John the Ripper and then compare the results of that to a table of stolen hashes to figure out the clear text credentials. Salt adds additional entropy to the mix. By adding salt to a hash, you’ve just complicated that process by adding additional randomness so the hashes won’t easily match anything you’ve generated on your own. Simon offers additional best practices.

Moffatt: And other basic things as well like disabling accounts, which are not in use, you know? If somebody hasn't logged in for maybe 90 days, disable the account, allow them to re-enable themselves if they wish to come back, but if they're not using something, close down the access, disable things and really small little workflow steps that's quite easy. cheap things to do cheap from a workflow perspective, cheap from a development perspective. Simple, quick, easy things which can really make a big, big difference actually. And if you're then looking to do things like MFA, make sure the MFA is adopted. You're trying to push out adoption to as many users within your community as possible, which can start as a really obvious thing to say, but many MFA projects often have quite low adoption rates, perhaps they aren't aware of it. Perhaps they're not incentivized to leverage multi factor authentication or perhaps it's just too damn complicated. And people don't ever want to sign up and use it. So there's lots and lots of little nudges and little cheap wins, if you like and it's worth going through an interesting quick audit and quick checklist to see what you can do which is cheap, quick, easy, free, essentially,  with a bit of effort to improve security. 

[music]

Vamosi: Simon has mentioned some improvements in authentication in the last three to five years. What does he point to as an example of that?

Moffatt: I think we need to think of authentication in a few different sort of areas. That number one, clearly there's a there's a security side to this whole points of authentication is working who somebody is, but the flip side is that usability conundrum, and I mentioned that earlier that this is conflict between usability how easy something is to use the satisfaction of the end user, the speed in which they can complete a particular task and they do it without help and having to speak to somebody or get assistance from somewhere else. So you have that usability aspect, as well as security. I do think both aspects are important for authentication. And I think honestly, in the last three or five years, both have actually moved forward. pretty substantially. I think the end user would go to commerce. The guy who doesn't really care about this stuff. They want to make a purchase on an e-commerce site. They want to do some online banking, they want to watch a movie on their favorite social media platform. They want to go about doing something they don't want to think about how they've authenticated how they are logging in. 

Vamosi: Right. I kind of don’t want to be interrupted all the time to prove that I am who I am. On the other hand, I don’t want to be a victim of fraud. So how do you walk that thin line between security and convenience?

Moffett: So I think there's been huge improvements in sort of end user awareness and training. And things like push authentication, averaging your mobile device to respond to authentication events, using your mobile device with a fingerprint on the front on the back to log in on the face ideal, sort of equivalent on Android. Most people are quite familiar with that. Now they feel comfortable with, you know, taking their mobile device and putting it onto the face taking a picture, maybe blinking to represent a bit of liveness to make sure they're not a dummy or a picture or something. So those sorts of little usability nudges I think are now quite well ingrained to standard end user who doesn't really know about security and it doesn't mean to care about security, but they just want to go about their day to day job at work doing work related employment related use cases or in the consumer space, making purchases and doing things online think that usability awareness aspect. I think that's improved hugely. And then clearly, the security side is constantly iterating as well with numerous different projects initiatives like web auth, OWASP, and others where they amplify good coding practices around authentication, good best practices in general around how to use authentication capability so it's a quite a long answer to your question, but I think usability and security both incrementally getting better every sort of three or six months, we're seeing improvements.

Vamosi: You mentioned standards such as OAuth, is that making it easier for developers and others to build in better authentication? 

Moffatt: I think it does. I think there's a few different standards, which are really important in this ecosystem. I think. OAuth is really the sort of result of the authentication aspect it's it's all about the authorization parts. And issuing an access token to sort of represent myself and what can Simon do against the ticker service. The sort of associated authentication aspect is thing called Open ID connect and they sort of go hand in hand essentially, where Open ID Connect is very much focused on representing the person so representing me with an ID token identity token. In the issuance of the ID token is typically tied to this authentication event whether it's usernames, passwords, biometrics password list, it doesn't really matter this is quite decoupled in its relationship which I think is very important as well, because developers, they want to develop applications. They typically don't necessarily want to go and mess around with security stuff on SDR, obviously, of course, security developers, but developers want to build stuff, build stuff on value and having standards like OpenID Connect to represent the identity off to to represent the access. And we're also starting to see some sort of new innovative approaches to authentication with the standard called Web auth or web auth n, which has been around a couple years now which is looking to promote this concept of passwordless authentication using using cryptography.

Vamosi: Public key cryptography, which was invented in the 1970s, and is a solution to the problem of shared secrets. Public key cryptography uses the concept of a keypair; a private key that is stored securely with the user, and a public key that can be shared with the server. These "keys" are random numbers that have a mathematical relationship with each other.  We use public key cryptography in https and secures how we use our financial services or order online. Web Authentication API --also known as WebAuthn-- allows servers to register and authenticate users using public key cryptography instead of a password.  Webauthn was written by W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, so it’s automatically baked into Edge, Chrome, and Firefox browsers. Functionally it allows you to instantly log in to a website if you’ve already registered your device with that site 

Moffatt:   I guess one of the backstories with things like WebAuthN what is it trying to achieve? You know, what's it? What are the problems it is trying to fix and a big, big problem you have in the username and password space is user sharing too badly to be used the same password and same email address or user ID across multiple different sites. It's, you sort of work out a good password, and you think it's the best part of the world and typically reuse it because that's what people do. They don't want to have to think of lots of different passwords and clearly what happens is, one website gets breached and because you've used the same password, the adversary will just sort of attack all of the top 10 websites you may have registered with with that reach potential. And there's a huge problem there because it's reused. So you start to be breached across multiple different sites and the web auth and standard really was looking to do a couple of things. One, clearly remove passwords from this whole authentication equation and leverage public key cryptography which has been around since the 1970s. And you have this asymmetric aspect where you have a private key which you should keep private and a public key which is publicly distributed. And these become unique per website or per service you interact with. So even if website a was breached, and they happen to to be risk of losing credentials, it doesn't then impact a second website, but you're using web auth and with because they've got their own separate individual keys, which is that sort of segmentation about the sort of ballast use case you get in ships where you have like, each of the ships cargo is neatly compartmentalized. So if the ship hits a rock and starts to flood it only floods a certain part of the, of the ship and it's similar to what WebAuthN is trying to achieve where each website essentially has a unique set of credentials. So even if they do get breached, it has very, very limited impact, which I think is quite smart, really. 

Vamosi: So, as we said at the top of the show, developers and hackers may not be paying as much attention to identity. Here’s a case where developers can build in passwordless security to their sites -- if they know about it.

Moffatt: So that's something else you have to learn I guess as a developer, but equally, the hard work of design and how it should work and what you should do is done for you. So it's the number of libraries increase the awareness and training and knowledge increases, you start to have these individual building blocks to allow application developers to say, Okay, I need to perform an authentication event I need password lists so I need access control or ever could be, you can start to pick and bolt together bevels to in a bit of web balls of OpenID Connect, and you can start to build these sort of standards in a quite improper way with external doing slightly different things. So I think standards have a huge part to play really.

[music]

Vamosi: So it sounds like we’re making great progress eliminating passwords, and making systems more secure. Wait, what? No, we’re still toiling in this password mess? Where then might the problem be?

Moffatt: I think the barrier which is starting to dominate more is this consumer customer identity spirit. So how we essentially do things online, as is his people, as citizens as customers and consumers, and that's typically focused on things like financial services and to be able to do your online banking be able to move money around digitally without having to use cash or going to a branch to do something to be able to consume content, online, movies, books, TV films, etc, etc. In a digital manner, be able to purchase things online, you will be able to on your mobile device, one click purchase done and next year, something is delivered in your house. So I think in the consumer space financial services, retail ecommerce, that huge area of financial transactions is see huge consumption of identity services over the last sort of three to five years they only see increasing further I think.

Vamosi: Has COVID contributed to that consumer growth? 

Moffatt: I think it has usually I think COVID has accelerated everything. Maybe not necessarily introduced new things, but maybe just accelerated the course of direction for both consumers and that sort of employee and workforce space. I guess in the workforce, we're all working from home, or working from coffee shops in the beach or whatever. And so that's a whole host of different problems. How do we work from home? How do we log into the systems, which traditionally may be stored in data centers and now perhaps they're all in different cloud repositories, into places so how do I log into my work laptop securely? How do I access these systems to do my job? in the consumer space? I'm doing everything online. I can't go to a bank because the banks closed down but even if it doesn't close down, it probably doesn't exist anywhere and I probably couldn't get in there. So from a consumer perspective, we have to do everything online. We have to order food, you have to get deliveries, do your banking, insurance, government services, everything's digital, and then how do you consume those services? How do I register, how to login and how do I represent myself? Digitally to all of these online services? So I think yeah, COVID is a huge impact in moving to doing things online is it's interesting. I was speaking to a guy last week about the use of QR codes as a method of getting information pre-bought. Something happened in the UK and in the US and other places where you go to a restaurant or a pub. There's no physical menu anymore, because it's a COVID carrying, it's a COVID carrying object. So check all the menus in the venues, get a QR code and go into the restaurant and pub you scan the QR code on your device. You get a nice menu on your mobile phone. And then perhaps you mean order from the mobile phone in the Pope's eatery of the Pope or whatever. Click the click press knit into an online transaction or release some money somehow through that website. And then obviously 15 minutes 30 off eat and drink arrive at your table and that's now just the corn standard with interacting, you know, using mobile or doing things digitally, even if it's a physical setting, so that's some hybrid start to new skills such as COVID is definitely amplified. 

Vamosi: So what’s the future hold?  Based on his twenty years of experience, how does Simon see the future of identity and security?

Moffatt: I think the good thing is that identities are here to stay and it's impacting everybody's day to day lives in a positive way. I hasten to add I think yes. COVID is hugely impacting everything we do. It's got huge ramifications, which we will probably see for the next 10 years if not more, I guess in our social interactions and and everything else and the exciting thing I guess for me is my identity specialist and whatever is identity is foundational to that, you know how I behave online as a employee or as a consumer. That's a nice identity . How do I authenticate and present myself? How do I register services? How do I share my personal information to third party services, how to buy, buy and consume things? I need to do this securely. I need to do it in a way which doesn't inhibit me. I wanted to be usable and improve my satisfaction by doing this stuff. And I think we're making some huge strides towards that. I think there's some really cool innovative startups in the space doing really excellent things around sort of machine learning by metrics and being able to represent ourselves digitally in a secure and useful way. But I think for that to work, I think the service providers and companies and businesses and applications, they all appreciate identity is important. It's the oil now which is allowing us all to interact with each other and allow us to do our jobs and do things online. So I think those two things are pretty exciting. Actually. You don't need to go into somewhere and amplify the benefits of identity management or access management or multi factor authentication or password this. People are on board with that because they want to have good identity based experiences. And I think that's been a huge change. 

Vamosi: I’d like to thank my friend Simon Moffatt for sharing his IAM experience and offering a look at the future with passwordless authentication. If we keep focusing on removing the low hanging fruit--weak passwords--hopefully we can add more friction to the attacks, and maybe the bad actors will become fewer.  I know, wishful thinking, but  it is an arms race. And if it will keep my employer from having me change my passwords every 90 days, then why not go for it.

Let's keep this conversation going. DM me at Robert Vamosi on Twitter, or join me on subreddit or Discord. You can find the deets at thehackermind.com 

The Hacker Mind is brought to you every two weeks commercial-free from ForAllSecure. 

For The Hacker Mind, I remain the hard to authenticate Robert Vamosi.

‍