Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff Works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: How Stuff Works and my Heart Radio and I love
Speaker 1: all things tech. And today we're gonna cover a topic
Speaker 1: that's a listener request that nikkil Cardale and I apologize.
Speaker 1: I am sure I have butchered the pronunciation of your name.
Speaker 1: That is totally on me, but he sent in a
Speaker 1: great request for a podcast topic. He linked me to
Speaker 1: an article on The Verge, which is one of my
Speaker 1: favorite tech news sites. By the way, Verges is great
Speaker 1: if you want to catch up on tech news. But
Speaker 1: the article has the title the Web just took a
Speaker 1: big step toward a password free future, and it was
Speaker 1: written by John Porter. The article talks about an authentication
Speaker 1: standard called web authen that's a W E B A
Speaker 1: U T h N, which is short for Web authentication.
Speaker 1: So in this episode, we're going to explore why we
Speaker 1: would want to move beyond passwords in the first place.
Speaker 1: I mean, what's wrong with passwords. We're going to cover
Speaker 1: that and what web often is and how we might
Speaker 1: interact with that in the future. So strap in securely,
Speaker 1: because security is what this is all about. So let's
Speaker 1: start with passwords. The idea of the password is truly ancient,
Speaker 1: and I don't just mean it's been around for decades
Speaker 1: and computer science. It's truly ancient, and it was a
Speaker 1: pretty common go to for various societies to protect and
Speaker 1: authenticate information and messengers. Do you need access to a
Speaker 1: secure location, better know the password. Chances are it's sword fish.
Speaker 1: You want to confirm that the information you are delivering
Speaker 1: is legit. What you got to share the password. But
Speaker 1: we all know this stuff, right, It's right up there
Speaker 1: with the history of codes and cryptic rams. I'm not
Speaker 1: telling you anything you don't know already. So let's flash forward.
Speaker 1: Let's say a few dozen centuries, and then we'll arrive
Speaker 1: at the Massachusetts Institute of Technology, good old m i T.
Speaker 1: And the year is nineteen sixty. A mathematician and physicist
Speaker 1: named Dr Fernando Corbato was working in the universities relatively
Speaker 1: young computation center. Now, back in those days, computers were
Speaker 1: monsters of the thing. The practice at the time was
Speaker 1: to use dumb terminals, meaning you had a keyboard and
Speaker 1: you had to display but it didn't have any computation
Speaker 1: power itself. It was connected to a centralized computer along
Speaker 1: with several other dumb terminals. So you have multiple terminals
Speaker 1: all connecting back to one centralized computer system. The computer
Speaker 1: couldn't truly multitask. You couldn't have all of those dumb
Speaker 1: terminals communicating simultaneously with that centralized computer. Instead, it would
Speaker 1: dedicate a certain number of processing cycles to each terminal,
Speaker 1: and it would rotate through the terminals in turn in
Speaker 1: a process that was called time sharing. So let's say
Speaker 1: that you've got ten dumb terminals attached to this central computer.
Speaker 1: For a certain number of cycles, the computer would say,
Speaker 1: all right, let me handle the commands from terminal one.
Speaker 1: Then I'll go to terminal two, terminal three, etcetera, etcetera,
Speaker 1: until I get back around to terminal one. This would
Speaker 1: happen pretty fast, so the delay wasn't always necessarily noticeable.
Speaker 1: It all depending on how many terminals there were and
Speaker 1: how many processing cycles were dedicated to each terminal. But
Speaker 1: you get the idea. So this computation time was precious.
Speaker 1: In fact, M I T. S standard practice in nineteen
Speaker 1: sixty was to limit each computer user to just four
Speaker 1: hours of computer time every week, so you can see
Speaker 1: that you need to make really good use of that
Speaker 1: computer time. Now people were literally using the same machine
Speaker 1: and reserving those blocks of time to do work on
Speaker 1: that computer, and that meant that you had various graduate students, professors,
Speaker 1: lab employees, and more, all relying on the same hardware
Speaker 1: and more importantly for this discussion, the same disc file system,
Speaker 1: and they all had different files that they would work on.
Speaker 1: So there need to be some way to protect one
Speaker 1: person's files so that the respective person could be reasonably
Speaker 1: sure those files would be there when they would need
Speaker 1: them next. So Fernando's solution was to create a password system.
Speaker 1: Each user would have his or her own password that
Speaker 1: would allow them to access their files while keeping all
Speaker 1: the other users files off limits. It was sort of
Speaker 1: a clueg solution to the problem, and Fernando himself didn't
Speaker 1: necessarily think it was meant to be the go to
Speaker 1: methodology for securing data from that point forward. It was
Speaker 1: really just kind of a stop gap. But sometimes when
Speaker 1: an idea takes hold, we just run with it, even
Speaker 1: if it turns out that that idea might not have
Speaker 1: been the best one. To hitch our wagons too in
Speaker 1: the long run, and so is the case with passwords. Now.
Speaker 1: At first, passwords didn't need to be particularly complicated or
Speaker 1: disguised in any complex way, because the number of people
Speaker 1: who had access to the computer in the first place
Speaker 1: was pretty darned small, and so was a manageable system.
Speaker 1: You could, and theory even have your passwords completely unencrypted,
Speaker 1: and as long as no one is digging around for it,
Speaker 1: it's fine. But you know, you always find troublemakers. And
Speaker 1: Fernando's approach couldn't scale up to something as immense as
Speaker 1: the Internet without some pretty significant enhancements. So we're gonna
Speaker 1: flash forward again, and now we're in the nineteen seventies,
Speaker 1: a little more than a decade after the modest solution
Speaker 1: from Fernando had taken deep hold in the computer labs
Speaker 1: across various universities. That's when Robert Morris Senior came up
Speaker 1: with another methodology to use in combination with passwords to
Speaker 1: make them more secure. This was called hashing. Now, in hashing,
Speaker 1: you start off with your password, and the password is
Speaker 1: made up of a string of characters. Uh so, maybe
Speaker 1: it's all letters, maybe it's a combination of different things.
Speaker 1: Maybe it's case sensitive and that means you could have
Speaker 1: both upper and lower case letters in that particular password.
Speaker 1: Maybe it includes numerals and symbols in it. But whether
Speaker 1: it's a strong password or not, you have a series
Speaker 1: of characters that make up your password. Then you take
Speaker 1: that serious series of characters are rather, the system does,
Speaker 1: and it applies a mathematical operation to that series of
Speaker 1: characters to transform them into a numerical code that represents
Speaker 1: the original password. That numerical code is what would get
Speaker 1: stored in a database, and that creates that added level
Speaker 1: of security because of some one else were to get
Speaker 1: access to this database, they wouldn't find a bunch of raw,
Speaker 1: unencrypted passwords that they could then use to get unauthorized
Speaker 1: access to a system. Instead, they would get the numerical
Speaker 1: codes that represent passwords but are not themselves passwords. So,
Speaker 1: in other words, if I got the hash of your password,
Speaker 1: let's say I get this incredibly long string of numbers
Speaker 1: that represents your relatively short password, and I were to
Speaker 1: try and log into an account that you owned, that
Speaker 1: long string of numbers wouldn't work for me, because that's
Speaker 1: what you get after the hashing process. It's not your
Speaker 1: actual password itself. So if the only thing stored on
Speaker 1: the database is this hash, it protects the original password.
Speaker 1: Without knowing what operation was used on that original string
Speaker 1: of characters, it would be very hard to reverse engineer
Speaker 1: the process to get those original passwords. So let's say
Speaker 1: that the mathematical process was a and a very large
Speaker 1: prime number was used to multiply against the value of
Speaker 1: your password. If I don't know the identity of that
Speaker 1: very large prime number, then I cannot determine what was
Speaker 1: the original string. That's the idea behind this particular method
Speaker 1: of of security. Over time, more enhancements were added to
Speaker 1: make passwords additionally secure. Remember that any security system tends
Speaker 1: to be involved in a high stakes game against those
Speaker 1: who would penetrate that system. So you have the hackers
Speaker 1: on one side. They want to know how the security works,
Speaker 1: and in the process they can learn how to exploit
Speaker 1: the security systems. That might not be to capitalize on
Speaker 1: that knowledge. They may just want to know how it works.
Speaker 1: But whether that's the case or not, they do. If
Speaker 1: they know how it works, they know how to exploit it.
Speaker 1: That's and that's a danger. I mean, obviously that makes
Speaker 1: the system insecure. It's like if someone who probably isn't
Speaker 1: a thief, but maybe you know they could be persuaded
Speaker 1: to be a thief if you gave them a copy
Speaker 1: of the key into the bank vault. That's probably a
Speaker 1: bad idea. So on the other side of this game
Speaker 1: are the security system engineers who are trying to shore
Speaker 1: up defenses and make it harder for outsiders to get
Speaker 1: access to a system. So they're trying to identify and
Speaker 1: patch vulnerabilities before those vulnerabilities can be exploited, or if
Speaker 1: a vulnerability has been exploited, to address that and fix
Speaker 1: it so that it's no longer an entry point into
Speaker 1: the system. So that's why we started seeing other methods
Speaker 1: being used with passwords, like salting, for example, that became
Speaker 1: part of the password systems. Salting is when a system
Speaker 1: adds a string of random data before the actual password
Speaker 1: characters and then puts the entire string through the hashing process,
Speaker 1: and that makes it even more complicated to unravel because
Speaker 1: not only do you have the starting password, you have
Speaker 1: the random data of the salt That has further complicated
Speaker 1: the whole process, and a lot of security depends upon
Speaker 1: the people using the system being careful. Hi, there's the
Speaker 1: rub is an assumption that is frequently unsafe to make.
Speaker 1: To have a truly secure system, you need the people
Speaker 1: who create accounts to make strong passwords that are difficult
Speaker 1: or impossible to guess. Because if I could guess that
Speaker 1: you are going to use let's say your cat's name
Speaker 1: as your password, it really doesn't matter how much salting
Speaker 1: or hashing or other fancy things are going on behind
Speaker 1: the scenes with the password. If I can guess what
Speaker 1: you used as your password, I can just type that
Speaker 1: in when logging in. As you and I have access,
Speaker 1: I don't need to do any fancy decoding, d HA
Speaker 1: shing or anything like that. I don't have to even
Speaker 1: get access to the hashed passwords in that database. If
Speaker 1: I could just guess that used Mr. Kiddies as your password,
Speaker 1: then I'm going to get in. That's why there's such
Speaker 1: an emphasis on creating strong passwords, because it makes it
Speaker 1: very hard for attackers to score a hit by just
Speaker 1: knowing a few details about you or making some educated guesses.
Speaker 1: The longer and stronger your password is, the less likely
Speaker 1: someone is going to get access to your account through
Speaker 1: a brute force attack, not when a hacker or a
Speaker 1: cracker or whatever you want to call them, uses a
Speaker 1: password generator, for example, that cycles through possible passwords. Typically
Speaker 1: it will start with common passwords, maybe default passwords for
Speaker 1: certain systems like routers tend to have default passwords and
Speaker 1: a lot of people don't change them and that could
Speaker 1: become a problem, or common passwords that people tend to
Speaker 1: rely upon, like password, or if you're really clever, password
Speaker 1: one two three, and seriously, if you use password one
Speaker 1: two three is a password, please change it? Please? It
Speaker 1: would be a great idea. And then after that the
Speaker 1: password generator might work its way through a list of
Speaker 1: common words and a big database that hackers tend to
Speaker 1: develop that where they'll store common passwords in that database.
Speaker 1: So it's not a true dictionary. It's called a dictionary attack.
Speaker 1: It's not necessarily a true dictionary where you're just working
Speaker 1: through all the words of a various of a specific language,
Speaker 1: but rather you're working through a database of words that
Speaker 1: have been flagged as being common passwords. Because we humans
Speaker 1: tend to pick these sort of things, we tend to
Speaker 1: rely upon them. Now beyond that, let's say that you
Speaker 1: haven't used one of these common words, the generator might
Speaker 1: start going through new guesses and the hopes of landing
Speaker 1: on the right one. So if you make your password
Speaker 1: very strong, lots of upper and lower case letters and
Speaker 1: numbers and some symbols, and you make it long enough,
Speaker 1: it makes it very hard for a brute force attack
Speaker 1: to get through, because it's not likely that it's going
Speaker 1: to hit upon that specific combination of characters. Of course,
Speaker 1: the flip side of that is it also makes it
Speaker 1: very hard for you to remember that password. And that's
Speaker 1: the other big weakness of passwords. We have to use
Speaker 1: them to access our stuff, and convenience is a very
Speaker 1: important thing to us. Security is important, but so is convenience.
Speaker 1: If I make the most amazing password and it is
Speaker 1: not impossible to crack with a conventional computer system, like
Speaker 1: it would take centuries for a computer to guess the password,
Speaker 1: and by the time it did, I'd be long dead
Speaker 1: and wouldn't care anyway. That's fine. But if I can't
Speaker 1: remember the password, what good does it do me? I
Speaker 1: can't access my stuff anyway. So if all of our
Speaker 1: passwords are unique, which they should be, if we make
Speaker 1: every password we use on every service a unique password
Speaker 1: across all of those services, and all of those passwords
Speaker 1: are really strong, We're probably gonna need some sort of
Speaker 1: password vault or manager to hold all of them because
Speaker 1: we're not going to be able to remember all of
Speaker 1: these unique strings of characters with upper and lower case
Speaker 1: and numbers and symbols. It's just our brains just don't
Speaker 1: tend to work that way. So I use a password
Speaker 1: manager myself. I use dash Lane, but there are tons
Speaker 1: of services out there, so I'm not saying dash Lane
Speaker 1: is the one and only it's the one I use,
Speaker 1: but there are lots of other really good ones out there,
Speaker 1: and we might enable other security measures as well. In fact,
Speaker 1: we should if we have the option, stuff like two
Speaker 1: factor authentication to improve security and reduce the chance that
Speaker 1: some unauthorized person would get access to our stuff. I've
Speaker 1: talked about this before, but just as a reminder, two
Speaker 1: factor security is when you combine factors, or you can
Speaker 1: think of them as sort of like categories of stuff
Speaker 1: to authenticate that you are who you say you are.
Speaker 1: So one factor could be a password that falls into
Speaker 1: the category of something you know, something you the user knows,
Speaker 1: so that's one factor. Then you would want to use
Speaker 1: a different factor, something belonging to a different category. So
Speaker 1: that might be a token, or it might be a
Speaker 1: cell phone that you have where you've registered your cell
Speaker 1: phone number in your profile, right, so when you log in,
Speaker 1: you do your password, that's something you know, and then
Speaker 1: the service sends you a message onto your cell phone.
Speaker 1: Maybe there's a text message with a code at one time,
Speaker 1: use code associated with it that you are supposed to
Speaker 1: enter in order to log into the service. This factor
Speaker 1: relies on something that you have the phone, so something
Speaker 1: you know, the password, something you have the phone and
Speaker 1: become Combining those fact there's you decrease the chance that
Speaker 1: someone other than yourself can access your stuff. It's still
Speaker 1: not full proof, there's still ways to work around it
Speaker 1: if you're really determined, but it reduces the chances of
Speaker 1: somebody being able to get unauthorized access to your accounts.
Speaker 1: So if you use services that offer to factor authentication,
Speaker 1: I highly recommend you actually activate that. But it's pretty
Speaker 1: clear that passwords aren't the ideal solution for security. They
Speaker 1: rely too heavily on the people using the systems to
Speaker 1: take the steps needed to make those systems truly secure.
Speaker 1: And I'm not placing all the blame on users because
Speaker 1: taking all those steps, if you're really trying to be
Speaker 1: super secure and you also want to rely on a
Speaker 1: lot of different services, that's a big pain in the butt,
Speaker 1: you know, it's it's it's not convenient. And on top
Speaker 1: of all of that, we're also at the dawn of
Speaker 1: the age of quantum computing, which could potentially render modern
Speaker 1: passwords as obsolete. That's because the peculiar way that quantum
Speaker 1: computers depend upon phenomena like superposition, in which a quantum
Speaker 1: particle can inhabit multiple states at once, sort of like
Speaker 1: a light switch being able to be off and on
Speaker 1: at the same time, or the quantum phenomena of entanglement,
Speaker 1: in which two quantum particles had their states tied to
Speaker 1: one another, no matter how far apart those particles might
Speaker 1: be in space. The whole quantum computer discussion gets really complicated,
Speaker 1: but what it boils down to for the purposes of
Speaker 1: cryptography is that a quantum computer with sufficient computing power
Speaker 1: will be very good at certain tasks, and among them
Speaker 1: could be breaking modern security systems. If you had a
Speaker 1: hacker who had access to a powerful quantum computer and
Speaker 1: the right algorithm. Because it's not just that a quantum
Speaker 1: computer can magically do this. You'd have to actually design
Speaker 1: the algorithm to do this. But people have designed such
Speaker 1: algorithms they could con eviably penetrated secure system in a
Speaker 1: relatively short amount of time, and so even strong passwords
Speaker 1: are on borrowed time. That sets the stage for us
Speaker 1: to talk about web athen although that's not a cure
Speaker 1: all for the quantum computer problem, but I'll explain more
Speaker 1: about that in just a second. First, let's take a
Speaker 1: quick break, all right, So what is web auth in?
Speaker 1: So it's a specification that has recently been upgraded to
Speaker 1: full on standard status by the Worldwide Web Consortium or
Speaker 1: W three C and the Fido Alliance f I d O.
Speaker 1: But what the heck does all of that mean? Well,
Speaker 1: the W three C is quote an international community where
Speaker 1: member organizations, a full time staff, and the public work
Speaker 1: together to develop Web standards. Led by Web inventor and
Speaker 1: director Tim Berners Lee and CEO Jeffrey Jaff. W three
Speaker 1: c's mission is to lead the Web to its full
Speaker 1: potential end quote. So the purpose of the W three
Speaker 1: C is to standardize stuff for the Web so that
Speaker 1: there's kind of a unified foundation upon which all web
Speaker 1: stuff can be built. Without some sort of organization to
Speaker 1: oversee this, you could end up with a very fractured
Speaker 1: experience that would be a nightmare to navigate, because as
Speaker 1: a user, you might discover that you can't visit some
Speaker 1: websites or use some web services if you were using
Speaker 1: a particular browser versus another, or a particular device versus another.
Speaker 1: Might be that, oh, when I'm on this smartphone, I
Speaker 1: can't access this thing, or if I'm using Chrome instead
Speaker 1: of Firefox, I can't go to this website. That would
Speaker 1: be awful. So we don't want that to happen. Standards
Speaker 1: allow us to create that common ground where we know,
Speaker 1: as long as everything is built on those standards, we
Speaker 1: should be able to access it through standardized browser or device,
Speaker 1: or rather a browser device that works on those same standards. Now,
Speaker 1: in turn, if we did not do that, then we
Speaker 1: would have a very fractured approach, right. You would have
Speaker 1: to have multiple browsers on your computer in order to
Speaker 1: access different things. You might say, oh, well, I want
Speaker 1: to go to my bank, but that means I got
Speaker 1: a quit out of Chrome and I need to open
Speaker 1: up uh, you know, Firefox or Safari or something like that.
Speaker 1: That would be a nightmare. On top of that, you
Speaker 1: might end up having certain types of services where you
Speaker 1: would have to install lots of different extensions onto an
Speaker 1: existing browser, which could introduce security vulnerabilities. So that could
Speaker 1: be bad. So the W three C seeks to make
Speaker 1: the web a virtual place where anyone with a browser
Speaker 1: or a web enabled device can access the stuff on
Speaker 1: the web in a positive way, meaning way that doesn't
Speaker 1: like invite malware and security breaches. Now, the final alliance
Speaker 1: is quote an open end street association with a focused
Speaker 1: mission authentication standards to help reduce the world's over reliance
Speaker 1: on passwords end quote. So this ties directly into the
Speaker 1: whole purpose of web off in. The goal of FIDO
Speaker 1: is to use open standards to develop better ways to
Speaker 1: secure systems that not only protect data but are easy
Speaker 1: for end users to employ without negatively impacting access to
Speaker 1: the web. That's a tall order. You want something that's
Speaker 1: more secure than passwords, you don't want it to be
Speaker 1: more inconvenient than passwords are, and you want to make
Speaker 1: sure that the actual practice of using it is no
Speaker 1: more negative than a password would be. The organization creates
Speaker 1: these specifications that makes them free to use globally. Fido
Speaker 1: is a relatively young organization that grew out of an
Speaker 1: alliance between PayPal, Lenovo, and several other companies back in
Speaker 1: two thousand twelve, and that developed out of earlier discussions
Speaker 1: between PayPal and a company called Validity Sensors that was
Speaker 1: really focusing on the possibility of using biometrics as a
Speaker 1: means of identifying a user rather than passwords. Okay, so
Speaker 1: those two organizations, Phido n W three C have declared
Speaker 1: the web Authen specification a standard, so now it's adopted
Speaker 1: as the official standard. Now we can dive into what
Speaker 1: web authen is all about now. First, web Authen itself
Speaker 1: is one part of a larger group of specifications called
Speaker 1: Phido two, and it's a standard that focuses on the
Speaker 1: platform or browser level of the Internet ecosystem, So we
Speaker 1: could call this sort of a client side standard. Ultimately,
Speaker 1: what the standard allows for is for web based sites
Speaker 1: and services to use a Phido security key or biometric
Speaker 1: data or a personal mobile device to access their various accounts.
Speaker 1: BioMed tricks could rely on stuff like a fingerprint scan
Speaker 1: or face scan or retina scan, voiceprint The idea here
Speaker 1: is that the user would never have to remember a
Speaker 1: password again, they would instead depend upon this authentication strategy. Now,
Speaker 1: in addition, the log in credentials would be unique to
Speaker 1: each service or site, so in other words, you'd be
Speaker 1: using the same input on your level, like your experience
Speaker 1: would always be the same. It might be the fingerprint
Speaker 1: scan Let's say, so you want to log into your bank,
Speaker 1: use your fingerprint scanner, but then you want to log
Speaker 1: into a social media site, use the fingerprint scanner again.
Speaker 1: So to you, you're using the exact same thing each time.
Speaker 1: But on the back end, the actual credentials that are
Speaker 1: created are unique to the bank or to the social
Speaker 1: media site or whatever. So you don't have one universal
Speaker 1: set of credentials for everything, because that would be a
Speaker 1: very poor security method. So we're going to think about
Speaker 1: fingerprint scans for much of this episode just as the
Speaker 1: purpose of of simplicity. But obviously it could be lots
Speaker 1: of different stuff, and you might even use something like
Speaker 1: a security key on a special USB stick that you
Speaker 1: would plug into a computer when you want to log
Speaker 1: into services. So it doesn't have to be biometric data
Speaker 1: connected directly to you. It could be a specific key
Speaker 1: that you've used when you've registered on some service, and
Speaker 1: then you just have to keep track of that key
Speaker 1: for the rest of your life. So here's the thing.
Speaker 1: Your fingerprint obviously doesn't change from site to site. That's
Speaker 1: the point, right Your fingerprint is unique to you, so
Speaker 1: it's what gives you the authority to access your profiles
Speaker 1: across these various services. At the same time, you don't
Speaker 1: want the digital representation of your fingerprint to be the
Speaker 1: same from service to service, is what I talking about
Speaker 1: a second ago. You don't want that set of credentials
Speaker 1: to be universal because that would be a huge security vulnerability.
Speaker 1: If hack we're able to get access to the digital
Speaker 1: representation of your fingerprint, this set of credentials, in other words,
Speaker 1: then they could presumably use that as a means to
Speaker 1: access your stuff. They could clone your method of access
Speaker 1: and then access your things as if they were you,
Speaker 1: So that would be a bad thing. Other sequences such
Speaker 1: as hashing can take the data from the the way
Speaker 1: you've you've scanned in whether it's that biometric approach with
Speaker 1: the fingerprint scanner or with the key fob um, and
Speaker 1: transform it in a unique particular way to the service
Speaker 1: you're accessing. I'll talk more about that sequence in a
Speaker 1: little bit. So let's say you're using fingerprint scans to
Speaker 1: access a social media site and you're using it to
Speaker 1: access your bank. The biometric data itself is on the
Speaker 1: device you're using, so the scanner you're using, it's not
Speaker 1: set up to a web server at your social media
Speaker 1: site or your bank. Instead, another process or series of
Speaker 1: processes transforms that biometric data into what amounts to the
Speaker 1: equivalent of a unique password for that particular service. It's
Speaker 1: just not a password you type in, it's one that's
Speaker 1: generated from your physical biometric information. The social media site
Speaker 1: uses one process to transform the biometric data and the
Speaker 1: bank uses a totally different one, And if someone were
Speaker 1: to somehow get access to the database for both of
Speaker 1: those businesses, they would not be able to link the
Speaker 1: two profiles together to identify you because the mathematical transformation
Speaker 1: is done on your fingerprint data make it look like
Speaker 1: it's two different people. So what's actually going on is
Speaker 1: the pairing of public and private keys, which I've talked
Speaker 1: about in previous episodes of tech Stuff. Web often is
Speaker 1: an a p I or application programming interface, so it
Speaker 1: creates login credentials through asymmetric encryption. Now it's a lot
Speaker 1: of technical talk for what's going on, but let's break
Speaker 1: it down into a more understandable description. We can look
Speaker 1: at web often as an ecosystem with three major entities.
Speaker 1: You've got the user agent. That's the portal through which
Speaker 1: a user is accessing a service. So it could be
Speaker 1: a web browser. That's the primary one. So a web
Speaker 1: browser would be the user agent, and it just as however,
Speaker 1: you're getting access to what you're trying to log into.
Speaker 1: Then you have the servers upon which the service you're
Speaker 1: logging into exists. That is also called the relying party.
Speaker 1: It's the part that needs assurance that you are who
Speaker 1: you say you are in order to give you the
Speaker 1: access to the stuff you want. Then you have the
Speaker 1: authentic ator. This is the element that acknowledges you are
Speaker 1: who you say you are. It's the trusted third party
Speaker 1: that tells the service this person's legit. I can vouch
Speaker 1: that they are who they claim to be. And this
Speaker 1: could take the form of biometric data like a fingerprint,
Speaker 1: that could be retina scan, voiceprints, gam it could be
Speaker 1: a pen, it could be a gesture or it might
Speaker 1: require a USB security token that you plug into a
Speaker 1: laptop to authenticate that you are who you claim to be.
Speaker 1: There are two use cases in which these three parties interact.
Speaker 1: The first is registration and the second is authentication. Registration,
Speaker 1: as the name implies, refers to the process of initially
Speaker 1: establishing an identity associated with an account using an authenticator.
Speaker 1: Authentication refers to using the authenticator to prove your identity
Speaker 1: upon subsequent visits. So let's use an example. Let's say
Speaker 1: that you want to create an account with a fictional
Speaker 1: service we're gonna call it Schmoogle, and you are on
Speaker 1: a desktop computer, and you're on the web browser of
Speaker 1: your choice, that's the user agent, and you use your
Speaker 1: browser to navigate to the Schmoogle website and you start
Speaker 1: filling out a profile. He said, already, I want to
Speaker 1: profile on Schmoogle. The Schmoogle server, also known as the
Speaker 1: relying party in this ecosystem, sends back to the user
Speaker 1: agent your browser what is called a challenge. The user
Speaker 1: agent sends that challenge plus a command to create new
Speaker 1: credentials to the authenticator, and the authenticator may send an
Speaker 1: authorization request to the user agent. UH In this example,
Speaker 1: Let's say that after you've hit register, your smartphone buzzes
Speaker 1: and you see a notification asking you to complete registration
Speaker 1: on your phone by scanning your fingerprint or hitting a
Speaker 1: button or something like that. You authenticate, and the message
Speaker 1: goes back to the authenticator, which creates new credentials and
Speaker 1: signs off on the challenge. It creates a digital signature
Speaker 1: and sends that to the user agent. The user agent
Speaker 1: then sends the new credentials in the form of a
Speaker 1: public key paired with the signed challenge, and sends that
Speaker 1: to the relying party, and the relying party registers the user.
Speaker 1: It's a long way of putting that process. Authentication is
Speaker 1: slightly different, but also involves the relying party requiring the
Speaker 1: authenticator to sign off on a challenge based on public
Speaker 1: key cryptography. Upon receiving the sign challenge, the relying party
Speaker 1: admits entry into the service. Now, much of the emphasis
Speaker 1: I've seen on web often has been its association with biometrics.
Speaker 1: In particular, that would be the factor known as something
Speaker 1: a user is because it's pretty darn hard to replicate
Speaker 1: without the user. Not impossible, but difficult. I'll explain more
Speaker 1: in just a second, but first, let's take another quick
Speaker 1: break to thank our sponsor. All right, Since week passwords
Speaker 1: are a huge threat to security, the W three C
Speaker 1: sites that stolen weak or default passwords are responsible for
Speaker 1: eighty one percent of data breaches. The idea is that
Speaker 1: the biometric approach can eliminate an enormous and enormously expensive problem.
Speaker 1: Companies have to spend millions of dollars every year to
Speaker 1: address or prevent data breaches. By taking passwords out of
Speaker 1: the ecosystem, the W three C and FIDO hope to
Speaker 1: eliminate the most common tools in a hackers arsenal. You
Speaker 1: can't guess someone's fingerprint or use a clever trick to
Speaker 1: fool someone into sharing their fingerprint password with you. Social
Speaker 1: engineering and phishing would get super complicated. You would need
Speaker 1: physical access to your targeted user to trick them into
Speaker 1: opening up the log in access to you, unless you
Speaker 1: could figure some other trick away around it. Presumably, getting
Speaker 1: physical access to a user would raise a few more
Speaker 1: questions than just your average phishing attempt. The web authen
Speaker 1: specification already has wide adoption as well. It's supported in
Speaker 1: Windows ten, Android, Google Chrome, Mozilla, Firefox, Microsoft Edge, and
Speaker 1: Apple Safari preview web browsers. So now it falls to
Speaker 1: service providers and site administrators to turn on support for
Speaker 1: web off in, and it opens up a new opportunity
Speaker 1: for companies to produce the purpherals needed to take advantage
Speaker 1: of this. Most smart funds and laptops have things like
Speaker 1: built in cameras. Webcams are fairly common. We're seeing more
Speaker 1: companies incorporate cameras directly into displays for web oft then
Speaker 1: to become widespread, will likely see more devices that can
Speaker 1: interoperate with existing technology, like fingerprint scanners that can plug
Speaker 1: into existing computers via USB ports, or we'll see more
Speaker 1: of those security keys. Some services have been supporting web
Speaker 1: often for a while now. Back in May two eighteen,
Speaker 1: Dropbox announced via its official blog that the service had
Speaker 1: integrated web at in support. The company did not toss
Speaker 1: passwords out the window or anything. Instead, Dropbox incorporated web
Speaker 1: often into two factor authentication, and the company acknowledges that
Speaker 1: there's still a lot of questions we need to answer
Speaker 1: before we leave passwords behind entirely. So, for example, what
Speaker 1: if you were to depend upon a USB security key
Speaker 1: such as the Ubickoe security key that's like the industry standard.
Speaker 1: It's a little USB stick. You plug it into your
Speaker 1: laptop or your desktop computer. When you try and log
Speaker 1: into a service that requires the security key. Uh, there's
Speaker 1: a little button on the actual USB stick that starts
Speaker 1: to light up. You press that button and it authenticates
Speaker 1: that you are who you say you are, and you're
Speaker 1: able to access without having to put in a password
Speaker 1: or more typically, you're using this as two factor authentication,
Speaker 1: so you're giving this an addition to a password. Now,
Speaker 1: these keys don't have any identifiable information stored on them.
Speaker 1: If someone else found your security key, they wouldn't be
Speaker 1: able to log into your account without knowing who you
Speaker 1: are and which services you use with that key. So
Speaker 1: if you happen to have the UBI key security key
Speaker 1: USB thing on a key chain and it fell somewhere
Speaker 1: and some random person picked it up, it would be
Speaker 1: of no use to them. They wouldn't know it belonged
Speaker 1: to you, they wouldn't know how to use it. So
Speaker 1: you could feel fairly secure that your your your various
Speaker 1: accounts would be safe. But what about you? How are
Speaker 1: you to access your services if you lose that key?
Speaker 1: I mean, it's another physical thing you have to keep
Speaker 1: up with it's a pain in the butt right well.
Speaker 1: According to Yubaco, the best practice is to have a
Speaker 1: backup security key registered as well. So you could presumably
Speaker 1: have a web often implementation where a user could link
Speaker 1: more than one security key to the account and have
Speaker 1: a backup security key, and you would keep that physical
Speaker 1: USB security key in a safe place, maybe in an
Speaker 1: actual fireproof safe for example, and if you lost your
Speaker 1: primary key, you would still have a backup you could
Speaker 1: use and you can maybe deactivate your primary key at
Speaker 1: that point. Yubaco points out that the threats for which
Speaker 1: the company made the keys in the first place are
Speaker 1: all remote account takeover threats. They aren't physical access threats, right,
Speaker 1: They're not this is someone who has gotten physical access
Speaker 1: to your computer and now they're gonna log on. But rather,
Speaker 1: this is someone who's trying to inject an attack on
Speaker 1: the Internet and pose as you, and it's the most
Speaker 1: common tactic that attackers take. It's unlikely that you would
Speaker 1: encounter someone who would aim to get physical access to
Speaker 1: you first in order to get access to your online accounts.
Speaker 1: They're more likely to use social engineering and phishing tactics,
Speaker 1: or a man in the middle attack, which is what
Speaker 1: these security keys are designed to foil. The security key
Speaker 1: represents an entity the relying party trusts, and without that
Speaker 1: party in the login process, the relying party won't grant
Speaker 1: access to the account. Now, apart from the concern that
Speaker 1: you might misplace a physical security key, there are other
Speaker 1: challenges associated with web all then, So let's go to biometrics.
Speaker 1: Let's say you're not using a physical security key or
Speaker 1: using a fingerprint scanner or retina scanner or something. Biometrics
Speaker 1: relate back to who you are biologically. A biometric system
Speaker 1: might authenticate your identity based off of some uh, some
Speaker 1: aspect of you that should be unique to you. Now.
Speaker 1: Unlike a password, which is at least in theory, privately
Speaker 1: known and only known to the individual user, biometric data
Speaker 1: is public, right, I mean, it's it's things about us
Speaker 1: that other people can see. It's not hidden away. Most
Speaker 1: of our modern culture these days celebrates sharing images and
Speaker 1: videos of ourselves in public online forums, from social media
Speaker 1: sites to video platforms like YouTube. That puts pressure on
Speaker 1: companies creating biometric systems to make sure they're detecting the
Speaker 1: real presence of a user. You might remember a story
Speaker 1: from a few years ago about some cigarette vending machines
Speaker 1: in Japan that used facial recognition software to determine if
Speaker 1: someone who was trying to buy cigarettes was actually old
Speaker 1: enough to do so. The system look for signs of
Speaker 1: aging that would indicate the buyer was of the appropriate age,
Speaker 1: But soon news broke that the system could be fooled
Speaker 1: just by holding up a printed out picture of an
Speaker 1: older person's face. The camera couldn't tell the difference between
Speaker 1: a two dimensional image and a three dimensional human face
Speaker 1: in front of it. Now, that's a huge flaw. It's
Speaker 1: a pretty extreme example of how a biometric system could
Speaker 1: be fooled. But it reinforces the fact that these systems
Speaker 1: must be proven to be extremely reliable or else they
Speaker 1: are still big security vulnerabilities. Similar concerns were raised when
Speaker 1: Apple announced that new versions of its iPhone would allow
Speaker 1: users to unlock their phones via facial recognition software. People
Speaker 1: began to ask questions like could the camera differentiate between
Speaker 1: images and actual faces? Could tell the difference between identical twins?
Speaker 1: And then there's a related problem. Sometimes the system might
Speaker 1: have trouble recognizing a person in different circumstances, like in
Speaker 1: low lighting or at different parts of the day. There
Speaker 1: was an article in Slate in July two thous eighteen
Speaker 1: titled iPhone face i D struggles to recognize people in
Speaker 1: the morning. So these systems could fail to authenticate a
Speaker 1: person when it really is the real person. But because
Speaker 1: the circumstances are different from when you registered your identity,
Speaker 1: then there's the concern that some of these systems might
Speaker 1: exclude entire ethnicities. It's a case of technological bias, which
Speaker 1: is something that can happen. The people who design the
Speaker 1: systems might exclude entire ethnicities, not necessarily intentionally, but just
Speaker 1: because of their own ethnic background that they're they're designing
Speaker 1: a system meant to recognize and differentiate people of their
Speaker 1: own ethnicity because that's where they're coming from. They're not
Speaker 1: thinking outside of that. And uh, there are real examples
Speaker 1: of this as well. Two thousand seventeen news story reported
Speaker 1: that once again Apple was in the news for a
Speaker 1: bad reason. Their face i D had troubled distinguished in
Speaker 1: between different Chinese people, So that's a big problem. Fingerprints
Speaker 1: have likewise been shown to be vulnerable to security attacks.
Speaker 1: Yan Chrysler took some high resolution pictures of ursula von
Speaker 1: der Lyon the German Minister of Defense, and was able
Speaker 1: to make copies of her fingerprints and full fingerprint authentication
Speaker 1: just from high resolution photos. Chrysler was also able to
Speaker 1: lift a fingerprint off of an iPhone screen and then
Speaker 1: use that lifted print to fool the iPhones touch i
Speaker 1: D technology and authenticate him as the proper owner of
Speaker 1: the iPhone. Now, these are pretty specific incidents, and they're
Speaker 1: not likely to become the types of situations that the
Speaker 1: average Internet user will encounter. But I felt I needed
Speaker 1: to include a bit in this discussion on the subject
Speaker 1: to be thorough with it, to be fair and objective,
Speaker 1: and to show that while biometrics have advantages over passwords
Speaker 1: in some areas, there are still some things will need
Speaker 1: to address if we want to use them regularly. Uh,
Speaker 1: the responsibility will no longer be let's make sure we
Speaker 1: make really good passwords and that we remember them all,
Speaker 1: but rather, let's make sure we keep track of our
Speaker 1: stuff and we don't let it fall into the wrong hands,
Speaker 1: particularly the wrong hands that are as clever as Yon Chrystler.
Speaker 1: That would be bad. Now, outside of the biometrics, some
Speaker 1: security experts have cautioned against Web often from a purely
Speaker 1: algorithmic perspective. Some security researchers with the Paragon Initiative raised
Speaker 1: questions about two algorithms, in particular, stating that it was
Speaker 1: theoretically possible for someone to develop an exploit that would
Speaker 1: let attackers steal a key from a user and then
Speaker 1: clone it themselves, kind of like cloning a credit card.
Speaker 1: But on the bright side, the Fighto Alliance got in
Speaker 1: touch with those researchers from Paragon Initiative to work on
Speaker 1: best practices and documentation, as well as improving protocols for Web,
Speaker 1: often to make it more secure. So that's a great step.
Speaker 1: So I'm not doom and glooming Web of then I
Speaker 1: actually think it's a really useful technology. But I also
Speaker 1: will completely admit it's one that's going to require a
Speaker 1: little care and shepherding along the way to make it
Speaker 1: truly a useful, adoptable tech. And maybe within five years,
Speaker 1: ten years, we won't be worried about passwords anymore. We'll
Speaker 1: be using web athen to log into everything, And then
Speaker 1: I'll actually make my life a lot easier as long
Speaker 1: as I don't lose that security key, which I'm already
Speaker 1: having anxiety about and I don't even own one of
Speaker 1: the darned things. Yet they do exist. You can go
Speaker 1: out there and get them right now. I'm just I
Speaker 1: got this terrible feeling that I'll be constantly trying to
Speaker 1: retrieve my accounts through complicated customer service menus because I
Speaker 1: lose stuff. But that's on me. If you guys have
Speaker 1: any suggestions for future episodes of tech Stuff, why not
Speaker 1: send me a message. The email address for the show
Speaker 1: is tech Stuff at how stuff works dot com, or
Speaker 1: pop on over to our website that's tech stuff podcast
Speaker 1: dot com. That's where you're going to find an archive
Speaker 1: of all of our older episodes, as well as links
Speaker 1: to our social media presence so you can present us
Speaker 1: with something on social media. There's also a link to
Speaker 1: our online store. Remember every purchase you make there goes
Speaker 1: to help the show. We greatly appreciate it, and I'll
Speaker 1: talk to you again really soon for more on this
Speaker 1: and thousands of other topics. Is it how stuff works
Speaker 1: dot com