PW - Could Passwordless be Worse than Passwords?

everyone um I want to get started a little bit early because I want to make sure that I don't cut into any of the time uh for Aldo here because I'm really looking forward to this talk uh so I just want to go ahead and as behalf of the password con staff and bsides welcome everyone here to Vegas you know this is a really cool thing to be doing this again here okay um so um just to take the the the energy down a notch here I just got a few announcements just to to start off things here uh so first of all um I guess we're contractually uh you know um I really want to thank our

sponsors because we wouldn't have this here you know uh if it wasn't for them so thank you Adobe you know our gold or our Diamond sponsor here as well as Toyota uh srep and blue cat uh so thank you we really appreciate this I love doing this here you make this possible so I really appreciate this a lot also for cell phones uh these talks are being streamed on live here so please you know uh don't have any side conversations on your cell phones or anything like that there you know this is a passwords contract so I'm sure we can go ahead and figure some way to be able to deal with that if it happens here uh so also kind

of really real quick here you know we've been doing passord con for a long time you know haven't we solved this problem or something like that there um and the answer is obviously no but uh one thing I kind of want to you know get a little bit of an audience Q&A POS start start off here but who here has had their password stolen I certainly have you know I've almost gting bored of this now you know I like oh my password got stolen again I guess it's a Tuesday um so let me go ahead and tell you probably the the worst data breach I've ever been a part of so when I first graduated

college I loaded up literally everything I own into my uh car and I was going you know job searching and stuff like that and one day I woke up you know came down from my hotel room and the back window of my car was broken and I found out I owned significantly less stuff so like some of it was really kind of annoying like I had disassembled all my furniture so they stole the bag of all the bolts which is just mean um but you know they also stole all my important documents because I left that in my car so they got my bir certificate they got my social security card they got my passport they got blank checks

like literally if you can think of something that's physical uh that you don't want to get stolen that got stolen from me so you know I might not actually be you know Matt Weir I might not be you know I might be the person who broke into the car as far as you know um but you know I was able to recover from that I was able to go ahead and get new credit cards I was able to get new checks I was able get new IDs and I think that really speaks to kind of the resiliency of this authentication of the fact that I can suffer the worst possible breach that you can even

imagine and I was able to still be able to recover from that and that's where I think you know passwords are really a big part role of this too because we have so many different PRS with passwords you know we get them stolen all the time yet we can still book plane tickets we can still show up at Vegas we can still you know have the hotel you know accept our credit cards and I think that really speaks to you know the value of all the hard work that everyone here has been putting into this type of field so you know an obvious question though is you know why are we still using passwords they get stolen all the

time you know can't we move to more of a password list type of an option here and that's why I'm really excited to go ahead and introduce Aldo here uh because he's going to tell us about some of the challenges that occur when we go ahead and move to this here as well so can we all go ahead and give a hands here to Aldo all right thank you uh thanks for that introduction uh well my name is Aldo and I'm here today to talk about passwordless and uh passwordless security uh so it's actually an honor to be here in password conon and you know uh I was a little bit nervous to be the

first one to be speaking today uh but actually uh quite the opposite because that actually takes the pressure off because if this stock sucks uh then the bar is going to be so low for everybody else so uh if if anybody here is a speaker uh you're welcome so let's let's try to make this talk uh suck a lot for for all of you all right so so uh yeah who am I right so I've been doing ab for about 15 years a little bit more uh you know from doing pentest to cult review to everything in between I am also an OAS chapter leader in my city and right now I am running the application security program for

hyper which it is a passwordless startup uh it's kind of ironic that I'm talking about passwordless vulnerabilities but it's going to make sense trust me uh so before I begin uh can you just let me know how many people here are uh developers all right uh what about pentesters nice and is anybody here already using passwordless either at work or in your personal devices awesome cool thank you all right so let's get started so uh let's begin by answering this question uh does anybody here think that using uh a password solution is actually worse or is actually less secure than having a password can anybody think that right a few of you all right well the answer to that

question uh actually no is not less secure uh yeah sorry about that uh yeah well and actually that is that is my whole talk uh thanks for coming here today uh thank you no no no uh sorry that was a terrible joke I'm sorry about that uh no this is the agenda that we're gonna be talking about today uh first of all some uh background on why am I giving this talk uh what is passwordless for those of you who are not familiar with this Paradigm and then we're going to deep uh dive into what are the actual issues with passws implementations and at the end we're going to have some recommendations for all of you uh

developers P testers and Enterprises uh so to set up the expectations uh this talk is about uh you know this is a brief introduction into passw lless uh this is not a full talk on passwordless uh we're going to be talking about vulnerabilities in a passwordless implementation uh specifically a web application uh you know passwordless can be used in other types of applications but these vulnerabilities are related to passwordless in web applications uh and this these issues were identified in a particular passwordless product uh that shall remain nameless uh but now it's actually my employer so uh so but these vulnerabilities apply to any application that is using uh passwordless so uh this is not specific

to a product it applies to any application that is using passwordless so what this talk is not about uh we're not going to be disclosing any new attacks I'm not dropping any OD days today uh I'm not doing a new a full talk on pass rless here uh we're not going to be talking about how to break cryptography uh you know pass rless one of the implementations uses uh public key cryptography so we're not going to be talking about that today and uh yeah why am I doing this today right so basically uh I see that nobody's talking about pass ress vulnerabilities uh you know the vendors right now and the whole industry is moving away from passwords

slowly but it's moving away from passwords to the uh passwordless Paradigm but uh nobody's actually talking about it and you know uh a lot of big players such as Microsoft Google Apple they all are pushing for passwordless but they are not talking about their their issues right uh I actually went to bdb.com and searched for passwordless and I get zero results none none of it uh some of the stuff that I'm going to be talking about today is already public and they are not there uh out of curiosity not to throw shade to any of the competitors but I went ahead and I went to their websites looking for some advisory page some something related to vulnerabilities and

I didn't find anything so in in short uh nobody's talking about this uh just a couple weeks ago when I was getting ready for this talk I went ahead and looked for uh pasis on Google and as you can see here uh we have many examples of companies already implementing B relist we have well they're implementing pasis which is uh a way of doing passwordless and we're GNA be talking about that so uh we have one password we have Tik Tok that is now using pasis we have GitHub we have PayPal we have Apple ID and this was just a couple weeks ago and if you go right now and search for pasis you're probably going to find more examples

like this so a lot of companies are going passwordless and uh but how secure are they that is the question so what is passwordless for those of you who are not familiar with this paradig and Paradigm or are not really sure what I'm talking about password Le essentially means uh not using a password in short that's that's that's that's it basically uh and no that's really not a joke that is actually what it means uh one of the most traditional implementations uh is using public key cryptography but there are more uh and essentially well if you're not familiar with public key cryptography essentially it creates a keeper one public key and one private key the public key stays in the serice

the private key stays with you or your device and then uh the application sends a challenge that you have to sign with your private key and only you can uh sign the challenge it's very secure uh a lot of cryptography works that way nowadays so uh this is how uh the most common ways of implementing passwordless nowadays uh a couple of quick mentions uh when you're are using a password manager that is not passwordless and I mentioned this because I saw a post the other day about somebody telling oh go passwordless use a password manager and uh that is obviously not passwordless they're just well you're storing your password somewhere else so that is not

passwordless when you have two Factor authentication that is also not passwordless because uh you are providing your username and password and then you are providing an additional Factor uh and lastly when you have onetime password where obviously the name suggests you have a password that is valid only once but it's still a password so uh in short passwordless means using no passwords and uh these are some of the ways that you can actually implement passwordless uh let's let's talk about them real quick uh one of the simplest ways to implement passwordless is using a magic link uh for those of you who are not familiar with magic links essentially a website sends you a link

to your email you click it and you authenticate to that website that's it and uh I think that's why it's called Magic link because it looks like magic you don't have to provide a username you don't have to provide a password you simply click on a link and you're in uh that is actually pretty practical but uh it has some disadvantages such as if the attacker knows your uh well if the attacker has access to your email well they own your accounts right uh these magic links can be delivered using email SMS and basically uh any way that you can reach your user the second part of the uh way to implement uh passwords is using security Keys uh such as these

ones so these are U Keys these are physical security Keys uh anybody here already uses ju keys or security Keys oh perfect it's amazing so the uh this is actually my preferred way to implement passwordless uh but as you know this is this can be quite expensive especially if you are a big uh company uh for instance let's say that you are Facebook and you want to deploy password list to all of your users uh I don't know how many users they have probably a billion I don't know so can you imagine just trying to purchase juie keys for your million users uh that's not going to scale and lastly we have Biometrics which uh work in the same way uh well

very similar to security keys they create a public key pair and you have your own uh private key and that is unlocked using your Biometrics so this is a very good alternative to uh security Keys uh everybody has a smartphone nowadays and they can use that smartphone as a way to provide passwordless access using your Biometrics this is just an example of how slack uh does passwordless essentially you go to the login you provide your email and they are going to send you an an email with a code and you provide that code and you don't have to provide any passwords at all that is another way to implement passwordless all right but now we have

Pho I mean uh we we see that we have several ways to implement password list but we really didn't have a standard uh until recently so uh everybody was doing it uh on their own way so this is why the pho Alli Pho Alliance exists the phto alliance basically is an organization that uh is in charge of maintaining an specification for the phto protocol uh phto means fast identity online so essentially has two main components uh one of them is web aent which is uh short for web authentication it's a set of apis that browsers can use to communicate between uh these authenticators and web applications and the other component is the client to Authentication Protocol

which we're not going to be talking about today uh we're going to be talking heavily about web aent today so again this is a set of apis that the browser use to communicate between uh the authenticators which can be uh security keys or fingerprint and web applications also uh I wanted to mention P keys uh when I say pass Keys when I say security Keys when I say uh passwordless and I when I say Biometrics I am referring to the same thing uh they are not the same thing I am simplifying things but for the purposes of this stock uh it's all the same and uh all these vulnerabilities are going to apply to pass Keys security

Keys uh Biometrics and any other authenticator and just to double down on web again uh this is a set of apis JavaScript apis that allow your browser to communicate with authenticators and um web application or Reliant party authenticators can be anything such as a physical security key uh Touch ID on your Mac Windows hello in your Windows computer and Biometrics on your mobile devices uh so this is an example of uh what using web aent looks like uh on the left you have a juu key uh in the middle you you have fingerprint in Chrome and lastly a fingerprint in uh on an iPhone so if you previously have seen something like this uh you are already using well

not passwordless but web aent all right so why why going passwordless uh I found this find G online which uh probably hates passwords as much as we do uh so well we are at password con right uh probably a lot of you know that everything about password suck so uh you know storing them protecting them hashing them uh yeah you have to use an algorithm that is slow enough to stop attackers but not slow enough to bother users uh well it is a it is a problem right when you go passwordless you don't have any more passwords to remember you don't have any more passwords to protect uh you don't have to worry about ineffective complexity factors and you

don't have to worry about people don't knowing their own passwords uh you know the last time that I got my wife a phone I was helping her trying to set up her phone right and I asked her hey can you log to your Gmail account so we can set up your phone and she was like uh I don't know my password like what do you mean you don't know your password and she doesn't uh you know she log into the Gman account once and she forgot about it and the same thing happened with my parents when I got them new phones they did know their passwords so uh well they were all able to reset them but I mean this is an

issue nobody well a lot of people don't know their own passwords uh passwordless is traditional than uh is faster than traditional MFA uh it protects against uh for those of you who are not familiar with this essentially when you register a security key that security key is registered to a specific uh website so if somebody was trying to fish me and they send me a fake link for my Microsoft account even if I were able to uh fold for that trick and I plug in my ju key is not going to work because that security key or that phto credential is only linked to a specific website so uh that is not going to work and lastly we don't have any more

password resets we don't have any dictionary attacks etc etc so all good things when not using passwords so ah thanks thanks for uh going through that uh I needed to provide some background for those of you who were not familiar with passwordless now let's talk about this so passwordless has a few misconceptions uh like we just saw a lot of people may think that passwordless is less secure um basically you don't have a password right so what is protecting my account if I don't have a password uh no password means no security uh that is not the case uh we're going to see it and uh for instance we also I have heard from people who think that somebody else

can unlock their phone using uh a photo or maybe their twin for people who have twins uh and also people thinking that fingerprint can be clone uh those are General misconceptions that I have heard from people uh really not working intact and also we have stalling or loss device issues so basically uh if you lose your device and attack is going to be able to authenticate to a website using your device I think that if an attacker seals your your phone and they are able to bypass your biometric authentication uh you probably have bigger things to worry about than they being able to log into your Facebook account for instance and lastly uh this one is actually true um if you lose your

device you're going to lose access to your account so that this is why you must have uh either a backup account a backup device or a way to uh recover account so that's is actually a valid concern all right so now let's talk about real vulnerabilities in passwordless implementations finally all right so uh this is the first issue and I on purpose didn't provide the title because I didn't want to give away the all the fun in the beginning so uh this is uh directly from the web auton documentation so if you go to that website you're going to see that uh basically you need uh you need to provide a user object uh essentially

that user object has a name a display name and an ID this is required for any uh whenever you're trying to authenticate or whenever you're are trying to add a new authenticator to an account uh just give me one second oops sorry oops excuse me just give me one second there we go sorry about that all right so yeah so uh I was saying that you need to provide a user object when you are adding a new uh device this is expected because you need to map that specific uh device to a user right so this is all in the uh documentation for web autant and then I went ahead and look for some examples of those specific

uh implementations uh the first one is from uh our friends at juico essentially no I mean dual security uh and and uh you can find the same they are saying that you need to provide a user object and that user object contains an ID a name and a display name uh this is directly from the documentation again this is expected uh this is the way the web aut Works uh one more example uh this we can find the same thing uh you need to provide a user object it has an ID a name and a display name uh this is Javascript code by the way this is a web aent API uh lastly I went for for uh the juo

documentation in order to add a new uh jubi key you have to do the same because jubi keys are also a F2 credential and are also using web uton so you need to provide a name a display name and an ID all right so that's part of the of the expected data that web Buton is is expecting right uh also for pasis uh as I mentioned pasis are also a pH to credential fasis are also uh using web aent so you also have have to provide an ID a name and a display name with all that being said uh this is a real implementation of a password resolution um for you uh for those of

you who are doing pentest you know that this is burp this is basically uh an HTTP intercepting proxy is allowing us to tamper with all of the data that is the browser is sending to the server uh if you take a closer look uh you can see that the application is sending a username and a display name as part of the specification uh quick question here for my pentester friends what do you think it could happen if we try to Tamper uh that username to another email let's say the CEO's email any guesses no well uh the specification doesn't actually say it but uh in this particular specification if I tamper with that value instead of uh adding a

new device to my account I was able to add a device to a different account so essentially by doing this uh you could essentially take over any account in the company that you wanted just by adding a new device you could impersonate any user in the system and remember that we are doing passwords here so we don't have any other way to authenticate uh simply by sending this request uh you can actually take over any account that you like this actually has CBE uh you can go ahead and look for more details uh let's talk about it all right so this was you know was following the specification to the letter it was doing everything that the documentation says

uh there wasn't any anything wrong with it uh one thing I want to mention is that the documentation doesn't say that you don't have to trust this data uh it may sound obvious to our security people but this this is not obvious to the people who are implementing web aent uh or at least if it's documented I couldn't find it so uh that actually makes me think I mean how many other applications are there that are just following the web button documentation and they are not providing that additional check um essentially uh if you wanted actually if you like to remove that data from the request it's not going to work because web Aon is

expecting that data so uh yeah so it's look it's leaving the developers to know I mean they it's they are on their own to implement this additional check because nobody's telling them that they have to do this right so um this actually is for me I I should reach out to the pho Alliance and ask them hey why are you not uh pointing this out why are you not documenting this or if you are where is it because it's not obvious and nobody I mean at least this implementation was not doing it all right uh moving on to magic links if you remember magic links are simply just a way to users to authenticate right uh they receive a link they click

it they are in this is a way to implement passwordless uh but one thing I like to mention is that web applications are usually uh just as vulnerable as they are flexible and what I mean by that is that you can do pretty much anything that you want with the web applications if you want to read a username from the headers you can do that if you want to read a username from the cookies you can do it I'm not saying that you should but you could uh so this is a problem with uh because you're letting your developers do whatever they want right so this is an simplified example uh this application had a a way to authenticate users uh

using a link something like this essentially they the application was providing a token the user click it and they are in however this particular application had two different user roles one for users what for admins they were both able to authenticate using uh a magic link uh however uh we can do some Force browsing uh and for instance if we try this is an example of course but if we add the word admin the token for the user was good for the admin and uh let's say that you got a token as a user you simply change the link to an add the word admin and you become an admin just like that this also has a CBE uh you can

go ahead and look for it if you want more details so let's talk about this the token that the application was using was actually quite secure I mean uh it was using uh good cryptography it was really long I mean uh it was being created using secure functions uh the token was expiring as soon as you click it and even if you didn't click it the token uh was being expired after some time so the magically implementation was didn't have any flaws apparently but uh as you know the developers need to be sure to uh protect every single endpoint they need to be able to uh verify every single input field and attackers only need to

find one uh endpoint that you missed and uh this is what happened here all right moving on to number three uh this is actually another take account takeover uh using parameter tampering it's very similar to the previous one and again uh web applications are very flexible uh when we're dealing with uh passwordless authentication is not one single request for instance when you are talking about username and password usually the username and the password are sent in a single request right so and that's it but this is not the case when we're talking about passwordless uh usually needs several requests uh you need to sign a challenge then you need to sign it then the application needs to verify

it really uh it needs a lot of requests and in this particular case uh the application was doing a lot of validations but again they missed just one so the attacker was able to provide a valid authentication for the user but authenticated as a different user instead uh this also has a CB and you can go ahead and look it if you need more details all right um let's let's talk about one more uh this one is about account creation uh again web applications are very flexible you can do pretty much what you want with them uh and this time we were talking about a demo application um you know companies sometimes provide demo applications so they can uh teach

their customers how to implement passwordless or how to implement anything else right uh in this case this particular vendor was using a demo application but uh in the user creation flow uh the application was not checking whether the user existed or not so essentially what happened is that you went to the login page uh you try to register uh you provide a username and uh the application wasn't checking if it existed or not and essentially since we're doing a f authentication you were adding a device to an account so from a passwordless standpoint it is the same as adding a an authenticator to an existing account or to a new account because you are simply adding a new

device right so what happened is what you were able to add new devices to any existing accounts and uh you were able to take cover those accounts uh again this is a demo application but still I think it's pretty uh pretty good to know that we should be doing all of these validations and uh lastly the a top 10 uh we have to remember that we are talking about web applications here so we don't have to we we must not forget about doing the basic validations uh that any other web application needs to happen right we have to do input validation we need to do security checks in every single endpoint and so forth and so on

all right uh so now let's talk about some recommendations uh for developers if you already have a secure sdlc uh I think it's a it's really good that you you have it if you don't uh you should Implement one what I mean by that is that you should do you should have some form of security testing in place um maybe some code scanning uh some dependency check and all of those things that are very good to increase the security of your your application also you should do some testing and then more testing and then more testing uh yeah I I I mentioned this because all of the issues that we talk about they were found by humans uh there is simply no

way that a tool can find this issues and if there is uh please let me know because I don't know of any tool that can do this uh probably not even AI so the best way to find the security vulnerabilities is by having testing done by humans also uh Embrace testing from customers uh a lot of times companies don't want to be uh allow their customers to do pentest because they think they're going to find issues and you're going to have to fix them that sometimes is true but I mean uh I think that's best because you can find those issues before an adversary does or before more customers do or before you have a leak so uh while

it's true that this is going to mean more work if you have issues I think it's best to do it because otherwise uh it's best to fix it before uh everybody knows and uh that way you're going to prevent breaches and security incidents for Enterprises uh if you're thinking of implementing passwordless uh in you are thinking about doing it uh in-house versus a vendor if you're thinking about using a vendor uh I think it's really important to hold those vendors accountable uh you know it's important to realize I mean how many times are they getting testing I mean are they just doing one pen test a year for compliance are they doing uh multiple rounds of testing uh you know

do they have a bug Bing program do they uh are they testing new features do they have a public CB program so I think this these questions can actually uh make it apparent if that company is actually uh doing something about security or even maybe they don't even have a security program so uh yeah this is for all the Enterprises for pentesters uh yeah actually when I was first uh testing uh password solution I I was kind of intimidated by it I was thinking well this is using public key cryptography right I'm not a cryptography I'm not going to be able to find any issues here right well no the truth is that uh at the end of the day

these are just web applications uh they have the same issues as any other web application uh my personal recommendation for any pen tester uh is going to be just go for parameter tempering this is where you're going to find the most issues uh and also unauthenticated apis so yeah all of the issues that we talked about before uh they related to web applications so basically all the same things that you're doing um are going to work in a passwordless application and my recommendation would be not to spend too much time on trying to break the cryptography I mean if you can go for it but uh it's probably going to be uh a lot of time and you're not going to get

any results there for users uh actually embrace the future I mean uh I talk about how passwords can be uh can have issues but uh actually it's way more secure uh whenever you are presented with the option to use passwordless uh you should do it I mean I think uh I think that passwords have way more issues than passwordless and uh as you can see here uh whenever an issue is found It's Quickly fixed so you know passwordless is a it's a very secure option all right so I think I went really really fast because uh that's it uh so that means we have a lot of time for questions if you have them uh if not

uh thanks a lot for being here and thanks a lot for your

time Alo in the example you gave of adding a device is there a way that we as the user can protect it what do we do uh not really uh the question was if uh you as users can protect yourselves against somebody else adding a device uh really there is no way you can do that uh the application is the one that has to be providing that additional check uh to make sure that the user who is adding that uh the device is the one that owns that account so really as users we don't have any

defense yeah do you have any recommended P oh there you go do you have any recommended patter for account recovery uh what we find I guess when we see most of the implementations we see leave old school methods in place for account recovery so it'll be like you still have a password if you need to recover your account or use top or something like that or use a phone number and we find that most vendors aren't fully disabling Legacy Security in favor of password list so I'm wondering if you have any fully passwordless uh account recovery mechanisms sure uh well this is not a Blog I mean this is well we do have a in my vendor we do

have a way to do that so essentially what it does is that we are providing a way to verify the identity of the user essentially uh we have a specific website that you can go you type your username and then we do an identity verification uh right now we're using it by using uh essentially it's like a meeting I mean I I can I can describe it better uh by showing a demo but essentially we do have a way to do this uh it verifies your identity it connects you with your manager and uh basically it can do face verification or phone verification that's up to the to the manager and once they have verified that

you are the person who owns that account they send you a a magic link and you can add a new device okay any more questions no right all right well thanks for being here uh feel free to uh I didn't have a Twitter but feel free to add me on LinkedIn if you like uh feel free to uh reach out to me if you have any more questions and thanks again for being here thank you