FIDObituary: The Death Of Passwords

awesome and so this is my first bid talk I'm very happy to share it with you all today I think it's going to be great uh this is f obituary the Das passwords uh so who am I my name is Brandon Burke everyone just calls me B I work as a stock analyst for us custodian Bank State Street uh I'm a big fan of Linux BSD anything open source or Libra related and I dabble in cryptography um our agenda is pretty simple I'm going to talk for about 30 35 minutes and try not to bore you there will be time for Q&A at the end so if you have questions please ask them there let's get right

into it authentication so we have three main types of factors and you likely already know them we have knowledge factors this is something that you know these include your usernames your IDs your passwords your pins pretty basic stuff we have possession factors this is something that you have think of your otps your Microsoft authenticator your key f to get into a building this is something a user must have in their possession to be able to authenticate and then we have inherence factors this is something that you have a retina or an IR scan fingerprint scans face and voice recognition any biological traits the user has that we can use to authenticate with and so we're going to talk about

some authentication history just to set the scene and so once upon a time we just had Dum Terminals and these would connect to an actual computer this would either be in the next room or you will use a teletype to talk to something miles and miles and miles away and our cryptography at the time wasn't superb often non-existent uh because cryptography calls clock cycles and those really really valuable so we used to just store passwords as plain text and there's some obvious issues here students could work out what was on the upcoming test see each other's homework all that good stuff so we got some marer most of the time and crypt was invented for Unix

systems in in 1973 by Robert moris Senor working for the NSA uh you might know a son Robert Morris Jr from the moris world uh crypto was great for authenticating locally but then we went and we invented the internet and we started authenticating users remotely so we're now sharing Secrets cross the wire to authenticate what could possibly go

wrong [Music] I apologize for the lack of HDMI audio but hopefully you got the message and so it turns out lot can go wrong when you start sharing secrets to authenticate over the Internet uh let's have a quick look and see where it can break down uh so this is a fairly standard I'm stand back this is a fairly standard uh login flow it's not right there there okay this is a fairly standard login flow that you're probably all familiar with or I'm going to assume some familiarity user registers they create an account and then at some point uh they log into that account and we hope this connection between the user and the server is over

https we hope the users has created a good password we have to remember that even if the connection is end to end encrypted at some point the server will need that password in plain text in order to Salt it hash it Etc and that's why we call it a shared secret we hope that the server is taking the password salting it and hashing it appropriately with something like Aron to bcrypt or script uh we hope they're using a secret Sol to Pepper that all the private information is properly encrypted and if we use something like Shad did they at least key stretch to make it more difficult if those passwords are breached and there's just not try and

jugle cryptography is hard uh and users are a lot harder let's do it that

way there we go uh cryptography is hard and users are a lot harder and so you're probably all aware of most of what I covered and even if you aren't you use password yourself all day every day and so I want you all to think about the worst thing about passord passwords uh the next slide's a little bit busy and I'll read it out for the people at the back so they know and but think about the worst thing about passwords and then if I got it or I'm in the right ballpark give me a little bit of wiggle room I want you to raise your hands uh we password managers are hard just use sticky notes put them in

Excel password reuse credential stuffing weak or bad passwords the rocky text file bad complexity rules Max password length why do we have Max password length for it expiry they just add one or an exclamation mark every single time or like 23 to F MFA badly implemented we s swapping we've MFA fatigue attacks and then everything that can and does go wrong server side so if you thought any one of those are as I said in the right enough ballpark you're completely wrong and now don't misunderstand all of these things are bad but they are not the worst about passwords they are failings of our shared secret system but they are not the absolute worst thing the worst

thing about passwords and authentication is that Security Professionals keep getting it wrong and bit of a bold statement what exactly do I mean by that I fundamentally believe that every single good idea can be broken down into a comic strip and if your good idea can't be boiled down to a comic strip you need to break it up into smaller better ideas for those of you who haven't seen this this is uh X case CD 936 or more commonly known as correct forse battery staple XKCD makes points that through 20 years of effort we've successfully trained everyone to use passwords that are hard for humans to remember but easy for computers to guess and we have two things going on

here we have the computer aspect and we have the human aspect our password policies have ignored the human aspect and led to people using passwords that are easy to guess uh if you search for this you will find a sack overflow question and the top rated ansers by a user called Avid uh he has a maxim avid's rule of usability security at the expense of usability comes at the expense of security I want you to note that the pass race correct horse battery staple while having greater entropy than the password trador would fail most modern password creation uh due to complexity rules these rules led to more insecure user behaviors and so much so that n

updated their recommendations earlier this year on passor complexity and they've stated complexity requirements like requiring special characters numbers or uppercase letters should not be used so it makes a password good is not that it is complex or that it is long but that it has high entropy and very few of those creation things are measuring entropy so is there an answer to all this is there a solution is there you know did anyone sit down and think about this problem and the answer is yes otherwise it would be a very short talk um so what is f pH stands for fast identity online Pho Alliance is publicly launched in 2013 they are an open industry association with the goal of

creating an open Global authentication standard based on public key cryptography one of the main driving goals behind Pho is to replace passwords and this means competing with passwords across three main Dimensions we have speed they should be faster than creating or using a password there is convenience they should be at least equally as conven convenient if not more convenient than using a password and very finally we have security they should be fishing resistant and should be guaranteed to be unique per app website or service so in December 14 they managed to launch their first two specifications u2f and uaf u2f stands for Universal second factor and uaf stands for Universal authentication framework uh uaf enables passwordless

authentication via Med local to user's device via gesture a voice or a pin and u2f enables the use of a hardware token or another device but only as a second Factor so we still need that primary factor like a password to be able to log in and these are two interesting protocols but there was a lot of room for improvement uh UF only worked as a second Factor as I said and uaf uh is a passwordless protocol uh but for mobile devices only so that was another limiting thing so they went back to drawing board and in April 2018 PH2 specifications were launched and these included web offn and cab 2 and we're mainly going to focus on these for the

talk and we're not going to worry about the older ones um webn is a worldwide Web Consortium recommendation for defining an API and enabling the creation and use strong attested scoped public key based credentials for web applications for the purpose of strongly authenticating users I'll cover all those terms shortly so don't worry if it's hiled over your head web is now built into practically every modern web browser uh so from a developer point of view authentication becomes a whole lot simpler there's numerous libraries for communicating with the web n AI um and then we have cab for actually talking to the authenticator ctop 2 is exactly as the name suggests client to authenticator protocol that's what it

says and u2f was retroactively called ctap one since it features a lot of similarities so that can be a little confusing but as I said we're not going to worry about the older ones uh ctop is implemented by the OS so yet again this is for Windows Apple Android Linux devs and anyone on the web server side we don't have to worry about it and so that was a lot of slides a lot of information uh time to do a live

Dem here we go

I'm going to try do

this so uh for this uh demo I'm going to use off hand. me it's a really great site to mess around with f.2 authentication and register a user and and I'm going to use my pho2 key here I know you can't see it but light is green working there we

go no

please this is awward so it's asking me for a pin and to be able to interact with my authenticator uh so I'm going to give it that

pin yeah the dangers are doing live demos no internet

connection uh I'll try another one all right let's off all right let on connection this one 878 hey this is Cooper sorry for the interruption here but on the day we were unable to make a recording of Brandon's laptop so as a result this live demo could not be recorded however Brandon had made a recording of the things he has done during this live demo and I will be including that here along with the audio for that recording because try as he might the recording was not identical to what he was doing on stage so expect the audio to sound a bit different at this stage once the demo is over we will cut back to the

original video and resume the talk so for this demo I'm going to use uh web a.me which is a really great site for playing around with 52 Authentication um I'm going to start with registering a user so we are going to be B sides Belfast 23 and I'm going to

register and now I get a uh Challenge on my authenticator and before we can access the authenticator we're going to input a pin so there's my six-digit pin and now have to touch the authenticator the light has gone uh from green to Orange so I press the button and just like that we've registered a uh a new credential so what actually happened there let's dive in if we go to this information page uh we can see a bunch of uh really great diagrams uh I've opened those up here uh um in kind of a higher um uh Zoom so um we have kind of three main parties we have the uh the client and user agent this is us and our

our browser we have the relying party which is phos speak for you know Amazon Google GitHub um whatever web server it is that we're trying to authenticate with and then we have our authenticator and this can be either a platform or a crossplatform authenticator uh I'm obviously using a a crossplatform the USB key but this could just as easily be a platform authenticator such as the fingerprint reader in your smartphone and then we have this interaction here which is when I uh I interacted I had to press the button to confirm that uh I was there but this is not always necessary so when we talk about PH2 we have two main uh ceremonies we have

registration and we have authentication or the login so for registration uh we go to the relying party and they give us you know the option to register so when we uh we click that button uh we ask them for a challenge and they will send us a challenge um now this challenge is just a really long random string uh that is used to prevent replay attacks now at this point before we talk to the authenticator the web auen API in the browser will check if the origin in the browser matches the relying party ID that was sent to us so let's imagine that you know we were fished and we were actually at a Google with two zeros

instead of Google the uh the genuine domain um at this point we would reject the challenge and the user isn't registered so any type of man in the middle or similar attacks those uh those are not a possibility here um assuming that that is valid uh we send it to the authenticator so we get the relying party ID the origin the user ID a bunch of various options and then that challenge string so the web auen API in the browser talks to the authenticator over ctap 2 and it sends all this stuff over now we create a brand new public private key pair and we create a credential it ID we stored a private key with the relying party ID

and credential ID and this private key never leaves the authenticator we build and sign a response but we do not sign it with the private key that we just generated the relying party doesn't know anything about the key pair we just generated so it's no good just yet so we use the attestation private key um attestation private keys are burned into the device and they're not unique to the device the ter terms attestation and assertion are very frequently confused attestation occures during registration which is this ceremony here an assertion occurs uh when authenticating so we signed the challenge uh with the Burnin attestation key and then we send the challenge back to the relying party uh when this

challenge reaches the relying party they can verify the origin so they do the same check that we did you know who does the browser think they are talking to who is the actual domain of the relying party they can verify the challenge they're going to make sure that no replay attacks have taken place and that it is the same challenge that they sent us they can verify the attestation signature if they want to and if they uh want to verify that they can um uh use the fal metadata service to check which Authenticator signed this and uh is it a is it a known model and they can also verify this the whole way up to the root

trust the same way that we would verify an x509 uh certificate with our standard um uh search in a browser assuming that all of those things pass and the relying party is Happy uh they will store the user ID the credential ID and the public key that we sent over and then you know we're registered we're done now we can register multiple authenticators on an account uh for recovery so for example if we lost our uh platform authenticator our USB key uh we could get back in with our phone or with our second authenticator and this is of course recommended uh just in case the work should happen so we've completed the first uh ceremony we've

completed the registration now we're going to perform the second ceremony which is authentication so for authentication this is uh really really simple I'm going to click log in and the browser talks to relying party relying party talks to the browser browser talks to my authenticator again before the web auen API can talk to my authenticator over ctap I have to give it a pin uh this can be uh reasonably long as well you could have like a password style pin I'm going to press enter I'm going to to again uh get a time down press the button on my authenticator and just like that I've successfully logged in so just as convenient and fast uh if not uh

definitely more so than than a password um so what actually happened there let's let's dive into it um much like the registrations party we uh registration ceremony excuse me we talk to the relying party um and they will send us a challenge that we have to sign um this message will also have the relying party ID and the credential ID we created uh assuming we're going with a username and we're not doing username less uh authentication um if we have resident Keys what we will do is we will use the relying party ID to identify the public key on the authenticator and we will have a passwordless uh usern nameless login um we again at this this point

check that the relying party ID uh that they sent us and the origin that the browser is seeing is one the same no man in the middle no proxying traffic nothing like that is allowed um if that passes we then send that over uh to the authenticator and again this uh kind of authorization this is optional we have uh user PR presence or user verification us presence is just a gesture uh pressing a button or or similar and user verification is uh like the pin it's verifying that the user is actually authorized to use that authenticator so we have multiactor in the one um we retrieve the private key um that is associated with the

credential ID and we verify it was created for that ring party ID we build and we sign response and we send that back to the relying party so when this challenge reaches the relying party they once again do the same check they verify the origin uh in the browser and their domain the relying party ID is one and the same they verified that the challenge is the challenge that they sent remember no replay attacks they verified the credential ID that we sent along that they they know who that uh uh user is they can identify them by the ID and then they verify the signature with the public key that they have stored and assuming that those four verifications

pass the relying party will say yep the user is authenticated and they will allow us to log in when all of that is taking place we retrieve the private key uh associated with the credential we verify that it was created by the riing party that we're speaking to we build sign a response send us riing party so sign send it back and when this reaches the ring party they do the same thing we do verify origin verify the challenge there's been no replay attack verify the credential ID verify the signature with public key and this time we've signed it with the on device PR key not the anation private key and if all of those pass we're happy

use her as

authenticators never do life devs again thanks Bill so what problems have we solved here and why are people so excited about this new tech and uh getting rid of kind of legacy authentication systems and we're authenticating with very secure battle tested well-known public ecography and what about that looming Quantum crypto apocalypse that's going to happen well just last month and Google announc the world's first Quantum resilient PH2 secur key implementation as par of opk um likely you'll have a lot of other companies following the sush and developers uh the same kind of thing so um we're not too worried we're getting ahead before uh before it kind of uh all kicks off and we have unique public keys

and private key pairs for for every login and those private keys are typically massive 256 and the public ones are 4096 so you're you're talking reasonable reasonable uh key size um this whole system means we have no fishing right because how does a user give away something that they don't know you call someone up and say hey what's your password I don't know just guess a um all of that stuff goes away one time passes uh go away and preaching the relying party on the server side would only leave you with the public keys and this is not enough to form an authentication um because the user is the one who initiates the login right

and they must have the authenticator in their possession and so no fishing no credit stuffing no man in the middle all of that is done do we get any privacy and that depends we can use the photo metadata service if we want to um but we don't have to you can as a relying party say hey I don't actually care what you're using for your authenticator I don't care if it's made by ubo I don't care if you're using a smartphone I don't it's not a problem to me and so that's definitely an option and then we have this question of do we really need to know who the user is with pH 2 it's possible to do usern nameless

logins sounds really really strange so you don't even need to attach any kind of username you can just use that credential ID which is a 64 bit number so 2 to the 64 if you're expecting more than 2 to the 64 users on your website you know good for you super popular um so read it'll depend on what you're trying to do maybe you've cases like banking where you've a kyc you know your customer AML anti munding laundering you will need to strongly verify who that user is you will need to know who they are you can't go usern nameless and so this is really interesting about pH cuz it's like the framework can be as

restrictive or as permissive as you choose and what other problems did we solve um I spent a lot of time searching for for the amount of times user spent typing passwords found numerous figures the low ball was 16 and the high ball was 27 hours a year and personally love to have 27 hours in my life back every year uh those stck and I'm not getting any younger um in terms of MFA codes there was even less data but time fell to around half that so you're talking 8 to 13 and 1 half hours every single year add those up and you have 24 to 40 1/2 hours for every employee every year and then you have all the

time of cyber security and health desk teams either investigating MFA failures password sprays resetting passwords yada yada yada y y we're all sick of this and we have to remember that time is money none of these teames are working for free and according to the pH Alliance your average health desk labor cost for single password is about $70 passwords are the root cause of over 80% of data breaches more than 50% of passwords are are reused um and so making the shortterm the change the password list it's really it's not cheap in the short term um but if you consider it against kind of the budget savings or just cost of the data breach God forbid um it doesn't sound

like such a poor investment so where do we go from here um well you can learn more and get up speed with all this uh fight of stuff and it kind of it depends on what kind of field you're in I suppose if you're management or strategic leader and you go to the pH Alliance um uh website they've a bunch of blog posts about people who have already made the move the pitfalls that they've hit the things that they've gotten wrong um so really really valuable there um if you're a assist adman and you're using Azure ad today you're just all in Cloud congratulations you can go full password list it's really really easy on

Microsoft have a bunch of documentation on that and if you have on creme and the latest KC connector there is a kind of hack way around where you can send the request to Azure ad first and then back into your own on Prem H so that is a possibility too um if you're a Dev or software developer uh Google have loads of fantastic documentation they have a build your first FAL app uh playground so in about uh 20 minutes 30 minutes you can have a web offend uh app SP up and and running it's a lot of fun and ubo have lots of great de docks they also provide the main Linux Library 52 and

Li and then if you're in cyber security You Can level up your skills and uh start being more secure it's a really really worthed um the webn website when you do have a Wi-Fi connection and you're not under mad pressure it's great a lot of f to and so do I actually think that passwords are dead and I think we're going to see another two decades of bad passwords and if you search for the stream you know de with passwords you find um stuff from 2004 where likes of Bill Gates and some senior Google engineers said oh the password is dead the data passwords and we're here in 2024 20 years later and it has taken a while for us to get

the technology off the ground and let's remember that F2 read only launched in 2018 and it's one thing to have standards it's quite in order to get them implemented get the libraries get them widely adopted accepted and ultimately trusted by people and maybe a bit anti- tractica that passwords are not dead and not going anywhere and but yeah they're bit like be Undead they won't stay [Music] Dead uh but we do have the tools to survive the night and hopefully we get to see a bright of Dawn and 10 points to everyone who got my Romero zombie references I'm very sorry for making those jokes uh he's been an absolutely wonderful audience thank you uh I'm very

happy to take some questions

any know there's a there's prize for best question I should say yes D question but you work in a sort of Bank have they moved over to using CL yet um I'm not going to make any comments though L sorry not Liberty to say nice try any other questions yes sir so if you are using a pH device yes the private say onto the device the assist station private key is yes um where are those stored and is there a risk of the vendor being compromised will compromise the Integrity of youry and yeah good question actually so what we have that asso station key is kind of burned in and so there's there's a couple different parts that question

and most of these chips are kind of secure tamperproof chips they're designed for you to not be able to get keys off them or not be able to do it easily there has been one case of such where a bunch of researchers in the Netherlands hacked a uh Key by uh Titan the actual jip by was by nxp semiconductors and they managed to retrieve the keys after three 4 weeks of slamming it with a couple Nvidia gpus was not a cheap attack when they succeeded they got you know one public private key pair for one account so Is it feasible now probably not those chips have been fixed by nxp and because you have the private

keys on the device and they never leave the device if you breach the relyant party on the other side you get the public key but that's all that you have you can't go and do a password spray you can't do any credential stuffing you can't use that public key in any meaningful way you need the user to initiate the log on it's from the user site and so answer your question yeah close off awesome yeah so what happens when you lose the key and also the backup and yeah good question um we you know you want to have two keys or tree keys if you log into the accounts you can set up um multiple keys I said that the private

keys never leave the device and that's a little bit of a lie so if you have um Google you're on Google you're on Apple or you're on Microsoft there is a way to back up your keys they get kind of like an encrypted blob each company does a little bit differently Apple have their secure keychain so your stuff gets backed up there and then if you want to access those in your MacBook or let's say you lose every Apple device provided you can get into your Apple account you can get those keys now is that a single point of failure yeah it is but for the average user is it still better than using passwords

absolutely it is and and that convenience I would say make the tradeoff uh this is you saw me it's just press a button you know this is something your grandmother can use maybe set it up for her and but yeah yeah if you if you lose your recovery key you are bumed in the same way of like can you get a reset um probably not the specification doesn't allow for it so we can't just send you reset s your question no problem from a d perspective is there any like additional or considerations you have to make want as yeah yeah good question and so in terms of how you sort in the database H not really you just you sort of public

key sort of credential ID but in in like your database columns everything is just it's it's the same you're soring it that way in the how you communicate with web 10 uh API that is in the browser and there's a bunch of different libraries depending on whether you're Ruby un rails raw PHP whatever you're you're working with and there's I think more than 15 very very good very well tested libraries for that and so that's pretty much all you have to implement as a Dev right you now don't have to worry about hashing salting none of the of you sort a public key you let the browser deal with it you let the OS deal with the SE

toop and talking to the authenticator there's less work for you to do what with the um I forgot the name like middle server the the replying part the relying party yes can is that something you said yourself is that like open standard sorry yeah no I should have made it clear so the riing party is the server you're authenticating against so like in this case Facebook Google whoever it is and they are ring party that yeah covers awesome any other questions yes [Music]

sir yes um it's a bit like our modern ssds like yes it's going to expire but 5 10 years you're you reasonable length time it's not like it's not anything that I'd be serious worried about and how many times have you had a USB key go pop yeah it's less than

that and again if you're if you're on Apple Microsoft Google any of those you have those backups there and that is that is an option and you're trading a certain amount of security for usability for convenience um I would say most used cases it's probably worth it uh not in every account some stuff you you just want two Hardware keys and you want to be really secure you want to be really safe um for other stuff you're probably not as concerned so yeah it's probably work back up the key answer your question yes sir so you talk a lot about the kind businesses that adopted using for St purposes um it took me a week to convin my parents

do you see any sort of public push on like maybe like I and such being used but a push for the public to use or in general together um as I said I I I don't think the passwords are dead I think it's going to be another 20 years of passwords and they're going to be a bit like tell or windows8 servers just going to pop up in lots of weird places where we don't want to see them they're just a nuisance um but they're going to be there and people are going to be using knowledge based strings for authentication for a long time yet um should you you know buy your folks a pH key for Christmas Maybe not

immediately but it starts with having the conversation or just showing them hey look I got this cool new thing and press button I can log in and so yeah yeah it um I I I do think it will go that way I think we've seen enough um hacks particular even like the MGM or these other things where our MFA Solutions have not worked they are not sustainable long term um the idea of you know using a timebase code is just fundamentally flawed uh if you're using HP and you're using like a a hash Bas it's a little bit better if your IV and you've a certain youve more Randomness than what you're taking from a clock uh

But ultimately MFA is just we've seen it fall flat enough I think today it speaks for itself so your question the rambling anyone else yes sir [Music] than you have anyone to is the only option if you have 15 individually every single one yeah yeah there's no this is it the private keys are in mutable they don't leave the device you're going to have to go in and create a new public private key pair for every single one they're non transferable and that's that's the beauty of that whole notion of scope right even if somebody got one private key public key PA and they can get it off the device it's for one account you're locked into that one relying

party thing um which is great you get an individual secure log for everything but there is certain amount of yeah tradeoff now you don't have any expiry they never expire you don't need to renew them you don't need to you know plug it in press button so all those costs of like password renewals every single you know three months whatever that's gone so you do only have to set it up once I guess you never have to worry about [Music] expiring am I over we're just on time okay cool just on time awesome and whoever asked me the question about the uh pH Keys being a good Christmas present yes sir congratulations want come on

up