March 18, 2019 • 42 mins
The W3C and FIDO recently adopted the WebAuthn specification as a standard. What is WebAuthn, and will it replace passwords?
Learn more about your ad-choices at https://www.iheartpodcastnetwork.com
See omnystudio.com/listener for privacy information.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Get in touch with technology with tech Stuff from how
stuff Works dot com. Hey there, and welcome to tech Stuff.
I'm your host, Jonathan Strickland. I'm an executive producer with
How Stuff Works and my Heart Radio and I love
all things tech. And today we're gonna cover a topic
(00:24):
that's a listener request that nikkil Cardale and I apologize.
I am sure I have butchered the pronunciation of your name.
That is totally on me, but he sent in a
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
(00:46):
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.
(01:06):
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
(01:26):
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.
(01:49):
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
(02:10):
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
(02:33):
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
(02:55):
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.
(03:16):
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
(03:37):
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
(03:58):
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,
(04:22):
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
(04:44):
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
(05:04):
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
(05:25):
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
(05:47):
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,
(06:11):
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
(06:33):
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
(06:55):
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,
(07:18):
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
(07:38):
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
(08:01):
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
(08:23):
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
(08:44):
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
(09:05):
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
(09:26):
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
(09:48):
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
(10:10):
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
(10:32):
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
(10:53):
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
(11:14):
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
(11:35):
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
(11:57):
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
(12:17):
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
(12:39):
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
(13:02):
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
(13:25):
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,
(13:47):
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
(14:09):
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
(14:29):
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
(14:51):
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,
(15:15):
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
(15:37):
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
(15:58):
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,
(16:23):
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
(16:44):
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
(17:05):
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
(17:25):
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
(17:48):
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
(18:12):
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
(18:34):
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
(18:58):
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
(19:18):
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
(19:40):
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,
(20:03):
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
(20:24):
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
(20:45):
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
(21:06):
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
(21:29):
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
(21:51):
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
(22:14):
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
(22:37):
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.
(22:59):
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
(23:21):
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.
(23:41):
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
(24:04):
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
(24:28):
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
(24:50):
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
(25:14):
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
(25:36):
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
(25:57):
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
(26:20):
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
(26:43):
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.
(27:05):
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.
(27:29):
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
(27:51):
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.
(28:11):
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
(28:34):
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
(28:54):
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
(29:18):
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
(29:39):
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.
(30:00):
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.
(30:22):
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
(30:50):
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
(31:10):
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
(31:32):
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
(31:54):
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
(32:16):
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
(32:38):
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
(32:59):
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
(33:21):
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.
(33:43):
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
(34:05):
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
(34:28):
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
(34:50):
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,
(35:13):
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,
(35:33):
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
(35:53):
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.
(36:16):
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
(36:39):
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
(37:01):
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
(37:22):
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
(37:44):
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
(38:05):
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
(38:26):
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
(38:47):
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.
(39:08):
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
(39:30):
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
(39:50):
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,
(40:11):
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
(40:34):
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,
(40:57):
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,
(41:22):
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
(41:42):
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
(42:05):
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
(42:33):
and thousands of other topics. Is it how stuff works
dot com
Get in touch with technology with tech Stuff from how
stuff Works dot com. Hey there, and welcome to tech Stuff.
I'm your host, Jonathan Strickland. I'm an executive producer with
How Stuff Works and my Heart Radio and I love
all things tech. And today we're gonna cover a topic
(00:24):
that's a listener request that nikkil Cardale and I apologize.
I am sure I have butchered the pronunciation of your name.
That is totally on me, but he sent in a
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
(00:46):
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.
(01:06):
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
(01:26):
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.
(01:49):
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
(02:10):
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
(02:33):
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
(02:55):
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.
(03:16):
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
(03:37):
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
(03:58):
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,
(04:22):
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
(04:44):
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
(05:04):
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
(05:25):
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
(05:47):
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,
(06:11):
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
(06:33):
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
(06:55):
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,
(07:18):
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
(07:38):
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
(08:01):
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
(08:23):
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
(08:44):
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
(09:05):
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
(09:26):
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
(09:48):
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
(10:10):
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
(10:32):
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
(10:53):
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
(11:14):
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
(11:35):
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
(11:57):
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
(12:17):
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
(12:39):
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
(13:02):
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
(13:25):
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,
(13:47):
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
(14:09):
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
(14:29):
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
(14:51):
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,
(15:15):
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
(15:37):
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
(15:58):
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,
(16:23):
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
(16:44):
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
(17:05):
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
(17:25):
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
(17:48):
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
(18:12):
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
(18:34):
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
(18:58):
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
(19:18):
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
(19:40):
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,
(20:03):
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
(20:24):
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
(20:45):
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
(21:06):
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
(21:29):
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
(21:51):
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
(22:14):
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
(22:37):
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.
(22:59):
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
(23:21):
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.
(23:41):
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
(24:04):
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
(24:28):
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
(24:50):
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
(25:14):
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
(25:36):
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
(25:57):
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
(26:20):
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
(26:43):
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.
(27:05):
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.
(27:29):
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
(27:51):
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.
(28:11):
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
(28:34):
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
(28:54):
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
(29:18):
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
(29:39):
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.
(30:00):
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.
(30:22):
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
(30:50):
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
(31:10):
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
(31:32):
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
(31:54):
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
(32:16):
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
(32:38):
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
(32:59):
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
(33:21):
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.
(33:43):
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
(34:05):
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
(34:28):
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
(34:50):
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,
(35:13):
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,
(35:33):
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
(35:53):
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.
(36:16):
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
(36:39):
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
(37:01):
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
(37:22):
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
(37:44):
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
(38:05):
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
(38:26):
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
(38:47):
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.
(39:08):
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
(39:30):
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
(39:50):
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,
(40:11):
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
(40:34):
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,
(40:57):
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,
(41:22):
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
(41:42):
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
(42:05):
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
(42:33):
and thousands of other topics. Is it how stuff works
dot com
TechStuff News
Hosts And Creators
Oz Woloshyn
Karah Preiss
Popular Podcasts
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Decisions, Decisions
Welcome to "Decisions, Decisions," the podcast where boundaries are pushed, and conversations get candid! Join your favorite hosts, Mandii B and WeezyWTF, as they dive deep into the world of non-traditional relationships and explore the often-taboo topics surrounding dating, sex, and love. Every Monday, Mandii and Weezy invite you to unlearn the outdated narratives dictated by traditional patriarchal norms. With a blend of humor, vulnerability, and authenticity, they share their personal journeys navigating their 30s, tackling the complexities of modern relationships, and engaging in thought-provoking discussions that challenge societal expectations. From groundbreaking interviews with diverse guests to relatable stories that resonate with your experiences, "Decisions, Decisions" is your go-to source for open dialogue about what it truly means to love and connect in today's world. Get ready to reshape your understanding of relationships and embrace the freedom of authentic connections—tune in and join the conversation!