What is WebAuthn

great request for a podcast topic. He linked me to an article on The Verge, which is one of my favorite tech news sites. By the way, Verges is great if you want to catch up on tech news. But the article has the title the Web just took a big step toward a password free future, and it was written by John Porter. The article talks about an authentication standard called web authen that's a W E B A U T h N, which is short for Web authentication.

So in this episode, we're going to explore why we would want to move beyond passwords in the first place. I mean, what's wrong with passwords. We're going to cover that and what web often is and how we might interact with that in the future. So strap in securely, because security is what this is all about. So let's start with passwords. The idea of the password is truly ancient, and I don't just mean it's been around for decades

and computer science. It's truly ancient, and it was a pretty common go to for various societies to protect and authenticate information and messengers. Do you need access to a secure location, better know the password. Chances are it's sword fish. You want to confirm that the information you are delivering is legit. What you got to share the password. But we all know this stuff, right, It's right up there with the history of codes and cryptic rams. I'm not

telling you anything you don't know already. So let's flash forward. Let's say a few dozen centuries, and then we'll arrive at the Massachusetts Institute of Technology, good old m i T. And the year is nineteen sixty. A mathematician and physicist named Dr Fernando Corbato was working in the universities relatively young computation center. Now, back in those days, computers were

monsters of the thing. The practice at the time was to use dumb terminals, meaning you had a keyboard and you had to display but it didn't have any computation power itself. It was connected to a centralized computer along with several other dumb terminals. So you have multiple terminals all connecting back to one centralized computer system. The computer couldn't truly multitask. You couldn't have all of those dumb

terminals communicating simultaneously with that centralized computer. Instead, it would dedicate a certain number of processing cycles to each terminal, and it would rotate through the terminals in turn in a process that was called time sharing. So let's say that you've got ten dumb terminals attached to this central computer. For a certain number of cycles, the computer would say, all right, let me handle the commands from terminal one.

Then I'll go to terminal two, terminal three, etcetera, etcetera, until I get back around to terminal one. This would happen pretty fast, so the delay wasn't always necessarily noticeable. It all depending on how many terminals there were and how many processing cycles were dedicated to each terminal. But you get the idea. So this computation time was precious.

In fact, M I T. S standard practice in nineteen sixty was to limit each computer user to just four hours of computer time every week, so you can see that you need to make really good use of that

computer time. Now people were literally using the same machine and reserving those blocks of time to do work on that computer, and that meant that you had various graduate students, professors, lab employees, and more, all relying on the same hardware and more importantly for this discussion, the same disc file system, and they all had different files that they would work on.

So there need to be some way to protect one person's files so that the respective person could be reasonably sure those files would be there when they would need them next. So Fernando's solution was to create a password system. Each user would have his or her own password that would allow them to access their files while keeping all the other users files off limits. It was sort of a clueg solution to the problem, and Fernando himself didn't necessarily think it was meant to be the go to

methodology for securing data from that point forward. It was really just kind of a stop gap. But sometimes when an idea takes hold, we just run with it, even if it turns out that that idea might not have been the best one. To hitch our wagons too in the long run, and so is the case with passwords. Now.

At first, passwords didn't need to be particularly complicated or disguised in any complex way, because the number of people who had access to the computer in the first place was pretty darned small, and so was a manageable system. You could, and theory even have your passwords completely unencrypted, and as long as no one is digging around for it, it's fine. But you know, you always find troublemakers. And Fernando's approach couldn't scale up to something as immense as

the Internet without some pretty significant enhancements. So we're gonna flash forward again, and now we're in the nineteen seventies, a little more than a decade after the modest solution from Fernando had taken deep hold in the computer labs across various universities. That's when Robert Morris Senior came up with another methodology to use in combination with passwords to make them more secure. This was called hashing. Now, in hashing, you start off with your password, and the password is

made up of a string of characters. Uh so, maybe it's all letters, maybe it's a combination of different things. Maybe it's case sensitive and that means you could have both upper and lower case letters in that particular password. Maybe it includes numerals and symbols in it. But whether it's a strong password or not, you have a series

of characters that make up your password. Then you take that serious series of characters are rather, the system does, and it applies a mathematical operation to that series of characters to transform them into a numerical code that represents

the original password. That numerical code is what would get stored in a database, and that creates that added level of security because of some one else were to get access to this database, they wouldn't find a bunch of raw, unencrypted passwords that they could then use to get unauthorized access to a system. Instead, they would get the numerical

codes that represent passwords but are not themselves passwords. So, in other words, if I got the hash of your password, let's say I get this incredibly long string of numbers that represents your relatively short password, and I were to try and log into an account that you owned, that long string of numbers wouldn't work for me, because that's what you get after the hashing process. It's not your

actual password itself. So if the only thing stored on the database is this hash, it protects the original password. Without knowing what operation was used on that original string of characters, it would be very hard to reverse engineer the process to get those original passwords. So let's say that the mathematical process was a and a very large prime number was used to multiply against the value of

your password. If I don't know the identity of that very large prime number, then I cannot determine what was the original string. That's the idea behind this particular method of of security. Over time, more enhancements were added to make passwords additionally secure. Remember that any security system tends to be involved in a high stakes game against those who would penetrate that system. So you have the hackers

on one side. They want to know how the security works, and in the process they can learn how to exploit the security systems. That might not be to capitalize on that knowledge. They may just want to know how it works. But whether that's the case or not, they do. If they know how it works, they know how to exploit it. That's and that's a danger. I mean, obviously that makes

the system insecure. It's like if someone who probably isn't a thief, but maybe you know they could be persuaded to be a thief if you gave them a copy of the key into the bank vault. That's probably a bad idea. So on the other side of this game are the security system engineers who are trying to shore up defenses and make it harder for outsiders to get

access to a system. So they're trying to identify and patch vulnerabilities before those vulnerabilities can be exploited, or if a vulnerability has been exploited, to address that and fix it so that it's no longer an entry point into the system. So that's why we started seeing other methods being used with passwords, like salting, for example, that became

part of the password systems. Salting is when a system adds a string of random data before the actual password characters and then puts the entire string through the hashing process, and that makes it even more complicated to unravel because not only do you have the starting password, you have the random data of the salt That has further complicated the whole process, and a lot of security depends upon

the people using the system being careful. Hi, there's the rub is an assumption that is frequently unsafe to make. To have a truly secure system, you need the people who create accounts to make strong passwords that are difficult or impossible to guess. Because if I could guess that you are going to use let's say your cat's name as your password, it really doesn't matter how much salting or hashing or other fancy things are going on behind

the scenes with the password. If I can guess what you used as your password, I can just type that in when logging in. As you and I have access, I don't need to do any fancy decoding, d HA shing or anything like that. I don't have to even get access to the hashed passwords in that database. If I could just guess that used Mr. Kiddies as your password,

then I'm going to get in. That's why there's such an emphasis on creating strong passwords, because it makes it very hard for attackers to score a hit by just knowing a few details about you or making some educated guesses. The longer and stronger your password is, the less likely someone is going to get access to your account through a brute force attack, not when a hacker or a cracker or whatever you want to call them, uses a

password generator, for example, that cycles through possible passwords. Typically it will start with common passwords, maybe default passwords for certain systems like routers tend to have default passwords and a lot of people don't change them and that could become a problem, or common passwords that people tend to rely upon, like password, or if you're really clever, password one two three, and seriously, if you use password one two three is a password, please change it? Please? It

would be a great idea. And then after that the password generator might work its way through a list of common words and a big database that hackers tend to develop that where they'll store common passwords in that database. So it's not a true dictionary. It's called a dictionary attack. It's not necessarily a true dictionary where you're just working through all the words of a various of a specific language, but rather you're working through a database of words that

have been flagged as being common passwords. Because we humans tend to pick these sort of things, we tend to rely upon them. Now beyond that, let's say that you haven't used one of these common words, the generator might start going through new guesses and the hopes of landing

on the right one. So if you make your password very strong, lots of upper and lower case letters and numbers and some symbols, and you make it long enough, it makes it very hard for a brute force attack to get through, because it's not likely that it's going to hit upon that specific combination of characters. Of course, the flip side of that is it also makes it very hard for you to remember that password. And that's

the other big weakness of passwords. We have to use them to access our stuff, and convenience is a very important thing to us. Security is important, but so is convenience. If I make the most amazing password and it is not impossible to crack with a conventional computer system, like it would take centuries for a computer to guess the password, and by the time it did, I'd be long dead and wouldn't care anyway. That's fine. But if I can't remember the password, what good does it do me? I

can't access my stuff anyway. So if all of our passwords are unique, which they should be, if we make every password we use on every service a unique password across all of those services, and all of those passwords are really strong, We're probably gonna need some sort of password vault or manager to hold all of them because we're not going to be able to remember all of these unique strings of characters with upper and lower case and numbers and symbols. It's just our brains just don't

tend to work that way. So I use a password manager myself. I use dash Lane, but there are tons of services out there, so I'm not saying dash Lane is the one and only it's the one I use, but there are lots of other really good ones out there, and we might enable other security measures as well. In fact, we should if we have the option, stuff like two factor authentication to improve security and reduce the chance that

some unauthorized person would get access to our stuff. I've talked about this before, but just as a reminder, two factor security is when you combine factors, or you can think of them as sort of like categories of stuff to authenticate that you are who you say you are. So one factor could be a password that falls into the category of something you know, something you the user knows, so that's one factor. Then you would want to use

a different factor, something belonging to a different category. So that might be a token, or it might be a cell phone that you have where you've registered your cell phone number in your profile, right, so when you log in, you do your password, that's something you know, and then the service sends you a message onto your cell phone. Maybe there's a text message with a code at one time, use code associated with it that you are supposed to

enter in order to log into the service. This factor relies on something that you have the phone, so something you know, the password, something you have the phone and become Combining those fact there's you decrease the chance that someone other than yourself can access your stuff. It's still not full proof, there's still ways to work around it if you're really determined, but it reduces the chances of somebody being able to get unauthorized access to your accounts.

So if you use services that offer to factor authentication, I highly recommend you actually activate that. But it's pretty clear that passwords aren't the ideal solution for security. They rely too heavily on the people using the systems to take the steps needed to make those systems truly secure.

And I'm not placing all the blame on users because taking all those steps, if you're really trying to be super secure and you also want to rely on a lot of different services, that's a big pain in the butt, you know, it's it's it's not convenient. And on top of all of that, we're also at the dawn of the age of quantum computing, which could potentially render modern

passwords as obsolete. That's because the peculiar way that quantum computers depend upon phenomena like superposition, in which a quantum particle can inhabit multiple states at once, sort of like a light switch being able to be off and on at the same time, or the quantum phenomena of entanglement, in which two quantum particles had their states tied to one another, no matter how far apart those particles might

be in space. The whole quantum computer discussion gets really complicated, but what it boils down to for the purposes of cryptography is that a quantum computer with sufficient computing power will be very good at certain tasks, and among them could be breaking modern security systems. If you had a hacker who had access to a powerful quantum computer and the right algorithm. Because it's not just that a quantum computer can magically do this. You'd have to actually design

the algorithm to do this. But people have designed such algorithms they could con eviably penetrated secure system in a relatively short amount of time, and so even strong passwords are on borrowed time. That sets the stage for us to talk about web athen although that's not a cure all for the quantum computer problem, but I'll explain more about that in just a second. First, let's take a quick break, all right, So what is web auth in?

So it's a specification that has recently been upgraded to full on standard status by the Worldwide Web Consortium or W three C and the Fido Alliance f I d O. But what the heck does all of that mean? Well, the W three C is quote an international community where member organizations, a full time staff, and the public work together to develop Web standards. Led by Web inventor and director Tim Berners Lee and CEO Jeffrey Jaff. W three c's mission is to lead the Web to its full

potential end quote. So the purpose of the W three C is to standardize stuff for the Web so that there's kind of a unified foundation upon which all web

stuff can be built. Without some sort of organization to oversee this, you could end up with a very fractured experience that would be a nightmare to navigate, because as a user, you might discover that you can't visit some websites or use some web services if you were using a particular browser versus another, or a particular device versus another. Might be that, oh, when I'm on this smartphone, I can't access this thing, or if I'm using Chrome instead

of Firefox, I can't go to this website. That would be awful. So we don't want that to happen. Standards allow us to create that common ground where we know, as long as everything is built on those standards, we should be able to access it through standardized browser or device, or rather a browser device that works on those same standards. Now, in turn, if we did not do that, then we

would have a very fractured approach, right. You would have to have multiple browsers on your computer in order to access different things. You might say, oh, well, I want to go to my bank, but that means I got a quit out of Chrome and I need to open up uh, you know, Firefox or Safari or something like that. That would be a nightmare. On top of that, you might end up having certain types of services where you would have to install lots of different extensions onto an

existing browser, which could introduce security vulnerabilities. So that could be bad. So the W three C seeks to make the web a virtual place where anyone with a browser or a web enabled device can access the stuff on the web in a positive way, meaning way that doesn't like invite malware and security breaches. Now, the final alliance is quote an open end street association with a focused mission authentication standards to help reduce the world's over reliance

on passwords end quote. So this ties directly into the whole purpose of web off in. The goal of FIDO is to use open standards to develop better ways to secure systems that not only protect data but are easy for end users to employ without negatively impacting access to the web. That's a tall order. You want something that's more secure than passwords, you don't want it to be more inconvenient than passwords are, and you want to make sure that the actual practice of using it is no

more negative than a password would be. The organization creates these specifications that makes them free to use globally. Fido is a relatively young organization that grew out of an alliance between PayPal, Lenovo, and several other companies back in two thousand twelve, and that developed out of earlier discussions between PayPal and a company called Validity Sensors that was really focusing on the possibility of using biometrics as a

means of identifying a user rather than passwords. Okay, so those two organizations, Phido n W three C have declared the web Authen specification a standard, so now it's adopted as the official standard. Now we can dive into what web authen is all about now. First, web Authen itself is one part of a larger group of specifications called Phido two, and it's a standard that focuses on the platform or browser level of the Internet ecosystem, So we

could call this sort of a client side standard. Ultimately, what the standard allows for is for web based sites and services to use a Phido security key or biometric data or a personal mobile device to access their various accounts. BioMed tricks could rely on stuff like a fingerprint scan or face scan or retina scan, voiceprint The idea here is that the user would never have to remember a

password again, they would instead depend upon this authentication strategy. Now, in addition, the log in credentials would be unique to each service or site, so in other words, you'd be using the same input on your level, like your experience would always be the same. It might be the fingerprint scan Let's say, so you want to log into your bank, use your fingerprint scanner, but then you want to log into a social media site, use the fingerprint scanner again.

So to you, you're using the exact same thing each time. But on the back end, the actual credentials that are created are unique to the bank or to the social media site or whatever. So you don't have one universal set of credentials for everything, because that would be a very poor security method. So we're going to think about fingerprint scans for much of this episode just as the

purpose of of simplicity. But obviously it could be lots of different stuff, and you might even use something like a security key on a special USB stick that you would plug into a computer when you want to log into services. So it doesn't have to be biometric data connected directly to you. It could be a specific key that you've used when you've registered on some service, and then you just have to keep track of that key for the rest of your life. So here's the thing.

Your fingerprint obviously doesn't change from site to site. That's the point, right Your fingerprint is unique to you, so it's what gives you the authority to access your profiles across these various services. At the same time, you don't want the digital representation of your fingerprint to be the same from service to service, is what I talking about a second ago. You don't want that set of credentials to be universal because that would be a huge security vulnerability.

If hack we're able to get access to the digital representation of your fingerprint, this set of credentials, in other words, then they could presumably use that as a means to access your stuff. They could clone your method of access and then access your things as if they were you,

So that would be a bad thing. Other sequences such as hashing can take the data from the the way you've you've scanned in whether it's that biometric approach with the fingerprint scanner or with the key fob um, and transform it in a unique particular way to the service you're accessing. I'll talk more about that sequence in a little bit. So let's say you're using fingerprint scans to access a social media site and you're using it to

access your bank. The biometric data itself is on the device you're using, so the scanner you're using, it's not set up to a web server at your social media site or your bank. Instead, another process or series of processes transforms that biometric data into what amounts to the equivalent of a unique password for that particular service. It's just not a password you type in, it's one that's

generated from your physical biometric information. The social media site uses one process to transform the biometric data and the bank uses a totally different one, And if someone were to somehow get access to the database for both of those businesses, they would not be able to link the two profiles together to identify you because the mathematical transformation is done on your fingerprint data make it look like

it's two different people. So what's actually going on is the pairing of public and private keys, which I've talked about in previous episodes of tech Stuff. Web often is an a p I or application programming interface, so it creates login credentials through asymmetric encryption. Now it's a lot of technical talk for what's going on, but let's break it down into a more understandable description. We can look at web often as an ecosystem with three major entities.

You've got the user agent. That's the portal through which a user is accessing a service. So it could be a web browser. That's the primary one. So a web browser would be the user agent, and it just as however, you're getting access to what you're trying to log into. Then you have the servers upon which the service you're logging into exists. That is also called the relying party. It's the part that needs assurance that you are who you say you are in order to give you the

access to the stuff you want. Then you have the authentic ator. This is the element that acknowledges you are who you say you are. It's the trusted third party that tells the service this person's legit. I can vouch

that they are who they claim to be. And this could take the form of biometric data like a fingerprint, that could be retina scan, voiceprints, gam it could be a pen, it could be a gesture or it might require a USB security token that you plug into a laptop to authenticate that you are who you claim to be. There are two use cases in which these three parties interact.

The first is registration and the second is authentication. Registration, as the name implies, refers to the process of initially establishing an identity associated with an account using an authenticator. Authentication refers to using the authenticator to prove your identity

upon subsequent visits. So let's use an example. Let's say that you want to create an account with a fictional service we're gonna call it Schmoogle, and you are on a desktop computer, and you're on the web browser of your choice, that's the user agent, and you use your browser to navigate to the Schmoogle website and you start filling out a profile. He said, already, I want to profile on Schmoogle. The Schmoogle server, also known as the relying party in this ecosystem, sends back to the user

agent your browser what is called a challenge. The user agent sends that challenge plus a command to create new credentials to the authenticator, and the authenticator may send an authorization request to the user agent. UH In this example, Let's say that after you've hit register, your smartphone buzzes and you see a notification asking you to complete registration on your phone by scanning your fingerprint or hitting a

button or something like that. You authenticate, and the message goes back to the authenticator, which creates new credentials and signs off on the challenge. It creates a digital signature and sends that to the user agent. The user agent then sends the new credentials in the form of a public key paired with the signed challenge, and sends that to the relying party, and the relying party registers the user.

It's a long way of putting that process. Authentication is slightly different, but also involves the relying party requiring the authenticator to sign off on a challenge based on public key cryptography. Upon receiving the sign challenge, the relying party admits entry into the service. Now, much of the emphasis I've seen on web often has been its association with biometrics. In particular, that would be the factor known as something a user is because it's pretty darn hard to replicate

without the user. Not impossible, but difficult. I'll explain more in just a second, but first, let's take another quick break to thank our sponsor. All right, Since week passwords are a huge threat to security, the W three C sites that stolen weak or default passwords are responsible for eighty one percent of data breaches. The idea is that the biometric approach can eliminate an enormous and enormously expensive problem. Companies have to spend millions of dollars every year to

address or prevent data breaches. By taking passwords out of the ecosystem, the W three C and FIDO hope to eliminate the most common tools in a hackers arsenal. You can't guess someone's fingerprint or use a clever trick to fool someone into sharing their fingerprint password with you. Social engineering and phishing would get super complicated. You would need physical access to your targeted user to trick them into opening up the log in access to you, unless you

could figure some other trick away around it. Presumably, getting physical access to a user would raise a few more questions than just your average phishing attempt. The web authen specification already has wide adoption as well. It's supported in Windows ten, Android, Google Chrome, Mozilla, Firefox, Microsoft Edge, and

Apple Safari preview web browsers. So now it falls to service providers and site administrators to turn on support for web off in, and it opens up a new opportunity for companies to produce the purpherals needed to take advantage of this. Most smart funds and laptops have things like

built in cameras. Webcams are fairly common. We're seeing more companies incorporate cameras directly into displays for web oft then to become widespread, will likely see more devices that can interoperate with existing technology, like fingerprint scanners that can plug into existing computers via USB ports, or we'll see more of those security keys. Some services have been supporting web

often for a while now. Back in May two eighteen, Dropbox announced via its official blog that the service had integrated web at in support. The company did not toss passwords out the window or anything. Instead, Dropbox incorporated web often into two factor authentication, and the company acknowledges that there's still a lot of questions we need to answer

before we leave passwords behind entirely. So, for example, what if you were to depend upon a USB security key such as the Ubickoe security key that's like the industry standard. It's a little USB stick. You plug it into your laptop or your desktop computer. When you try and log into a service that requires the security key. Uh, there's a little button on the actual USB stick that starts

to light up. You press that button and it authenticates that you are who you say you are, and you're able to access without having to put in a password or more typically, you're using this as two factor authentication, so you're giving this an addition to a password. Now, these keys don't have any identifiable information stored on them. If someone else found your security key, they wouldn't be able to log into your account without knowing who you

are and which services you use with that key. So if you happen to have the UBI key security key USB thing on a key chain and it fell somewhere and some random person picked it up, it would be of no use to them. They wouldn't know it belonged to you, they wouldn't know how to use it. So you could feel fairly secure that your your your various accounts would be safe. But what about you? How are you to access your services if you lose that key?

I mean, it's another physical thing you have to keep up with it's a pain in the butt right well. According to Yubaco, the best practice is to have a

backup security key registered as well. So you could presumably have a web often implementation where a user could link more than one security key to the account and have a backup security key, and you would keep that physical USB security key in a safe place, maybe in an actual fireproof safe for example, and if you lost your primary key, you would still have a backup you could use and you can maybe deactivate your primary key at

that point. Yubaco points out that the threats for which the company made the keys in the first place are all remote account takeover threats. They aren't physical access threats, right, They're not this is someone who has gotten physical access to your computer and now they're gonna log on. But rather, this is someone who's trying to inject an attack on the Internet and pose as you, and it's the most

common tactic that attackers take. It's unlikely that you would encounter someone who would aim to get physical access to you first in order to get access to your online accounts. They're more likely to use social engineering and phishing tactics, or a man in the middle attack, which is what these security keys are designed to foil. The security key represents an entity the relying party trusts, and without that party in the login process, the relying party won't grant

access to the account. Now, apart from the concern that you might misplace a physical security key, there are other challenges associated with web all then, So let's go to biometrics. Let's say you're not using a physical security key or using a fingerprint scanner or retina scanner or something. Biometrics relate back to who you are biologically. A biometric system might authenticate your identity based off of some uh, some aspect of you that should be unique to you. Now.

Unlike a password, which is at least in theory, privately known and only known to the individual user, biometric data is public, right, I mean, it's it's things about us that other people can see. It's not hidden away. Most of our modern culture these days celebrates sharing images and videos of ourselves in public online forums, from social media sites to video platforms like YouTube. That puts pressure on companies creating biometric systems to make sure they're detecting the

real presence of a user. You might remember a story from a few years ago about some cigarette vending machines in Japan that used facial recognition software to determine if someone who was trying to buy cigarettes was actually old enough to do so. The system look for signs of aging that would indicate the buyer was of the appropriate age, But soon news broke that the system could be fooled just by holding up a printed out picture of an

older person's face. The camera couldn't tell the difference between a two dimensional image and a three dimensional human face in front of it. Now, that's a huge flaw. It's a pretty extreme example of how a biometric system could be fooled. But it reinforces the fact that these systems must be proven to be extremely reliable or else they are still big security vulnerabilities. Similar concerns were raised when Apple announced that new versions of its iPhone would allow

users to unlock their phones via facial recognition software. People began to ask questions like could the camera differentiate between images and actual faces? Could tell the difference between identical twins? And then there's a related problem. Sometimes the system might have trouble recognizing a person in different circumstances, like in

low lighting or at different parts of the day. There was an article in Slate in July two thous eighteen titled iPhone face i D struggles to recognize people in the morning. So these systems could fail to authenticate a person when it really is the real person. But because the circumstances are different from when you registered your identity, then there's the concern that some of these systems might exclude entire ethnicities. It's a case of technological bias, which

is something that can happen. The people who design the systems might exclude entire ethnicities, not necessarily intentionally, but just because of their own ethnic background that they're they're designing a system meant to recognize and differentiate people of their own ethnicity because that's where they're coming from. They're not thinking outside of that. And uh, there are real examples of this as well. Two thousand seventeen news story reported that once again Apple was in the news for a

bad reason. Their face i D had troubled distinguished in between different Chinese people, So that's a big problem. Fingerprints have likewise been shown to be vulnerable to security attacks. Yan Chrysler took some high resolution pictures of ursula von der Lyon the German Minister of Defense, and was able to make copies of her fingerprints and full fingerprint authentication

just from high resolution photos. Chrysler was also able to lift a fingerprint off of an iPhone screen and then use that lifted print to fool the iPhones touch i D technology and authenticate him as the proper owner of the iPhone. Now, these are pretty specific incidents, and they're not likely to become the types of situations that the

average Internet user will encounter. But I felt I needed to include a bit in this discussion on the subject to be thorough with it, to be fair and objective, and to show that while biometrics have advantages over passwords in some areas, there are still some things will need

to address if we want to use them regularly. Uh, the responsibility will no longer be let's make sure we make really good passwords and that we remember them all, but rather, let's make sure we keep track of our stuff and we don't let it fall into the wrong hands, particularly the wrong hands that are as clever as Yon Chrystler. That would be bad. Now, outside of the biometrics, some security experts have cautioned against Web often from a purely

algorithmic perspective. Some security researchers with the Paragon Initiative raised questions about two algorithms, in particular, stating that it was theoretically possible for someone to develop an exploit that would let attackers steal a key from a user and then clone it themselves, kind of like cloning a credit card.

But on the bright side, the Fighto Alliance got in touch with those researchers from Paragon Initiative to work on best practices and documentation, as well as improving protocols for Web, often to make it more secure. So that's a great step. So I'm not doom and glooming Web of then I actually think it's a really useful technology. But I also will completely admit it's one that's going to require a little care and shepherding along the way to make it

truly a useful, adoptable tech. And maybe within five years, ten years, we won't be worried about passwords anymore. We'll be using web athen to log into everything, And then I'll actually make my life a lot easier as long as I don't lose that security key, which I'm already having anxiety about and I don't even own one of the darned things. Yet they do exist. You can go

out there and get them right now. I'm just I got this terrible feeling that I'll be constantly trying to retrieve my accounts through complicated customer service menus because I lose stuff. But that's on me. If you guys have any suggestions for future episodes of tech Stuff, why not send me a message. The email address for the show is tech Stuff at how stuff works dot com, or pop on over to our website that's tech stuff podcast

dot com. That's where you're going to find an archive of all of our older episodes, as well as links to our social media presence so you can present us with something on social media. There's also a link to our online store. Remember every purchase you make there goes to help the show. We greatly appreciate it, and I'll talk to you again really soon for more on this and thousands of other topics. Is it how stuff works dot com