>> Cormac Herley: All right, so we're going to get started here. It's a
pleasure to introduce Paul van Oorschot from Carleton University who is
going to talk about passwords and stuff today. Paul's been around for a
long time. He's a professor at Carleton. He's been in industry and
academia. He's maybe best known as the author of the handbook on
cryptography which is a monster on monster citation thing. He's done a
whole bunch of other things. I won't bother going through them, but one
of the fun facts from his bio is that he was in the Waterloo Warriors
basketball team for four years as an undergraduate. So anyway without
further adieu, Paul and "The Persistence of Passwords."
>> Paul C. van Oorschot: Thank you, Cormac. And I noticed The Handbook
of Applied Crypto was not one of the books on your shelf. I was going
to ask you a little bit more about -- Well...
>> Cormac Herley: It's at home under [inaudible].
>> Paul C. van Oorschot: It's probably on the top of your desk at home.
That's -- Yeah. But anyway thanks for having me here, and thanks for
taking time out of your day to attend. I'm going to talk mainly about a
couple of papers. Actually a lot of this is work I've done with Cormac,
so Cormac will be the most important person in the room. We all know a
lot about passwords, and we want to try and make some progress on
solving some research problems and issues related to passwords. So I'm
hoping a couple of you I might get a chance to chat with while I'm here
for a couple of more days. And this might set a bit of a baseline for
some discussion there and get out of the way all the things that we
agree on and we usually spend all of our time talking about, so we can
maybe get to some research questions and figure out what we should
study next.
So a couple quotes, and these are out of some papers. And the first
one, I think, is the one that researchers who claim to do research in
this area should really take to heart. And that is, "The continued
domination of passwords over all other methods of end-user
authentication," really, you know, we should take this as a major
embarrassment to ourselves especially if we are the ones who continue
to propose year after year things which are far, far better than
passwords and none of which ever see the light of day for a lot of
reasons that we don't talk about or we don't understand. And, you know,
I'm personally tired of reading papers and, you know, hopefully I don't
write too many of them. But, you know, all of these papers that we
propose things that are much better. Well, somehow we must have
something wrong if we think they're so much better and yet they don't
get the uptake in the real world.
And we all seem to agree, you know, "The enthusiasm that almost all
parties show for getting rid of passwords hasn't translated into
support for any single alternative." So there's something wrong here.
And I think that we aren't gathering up all of our information
properly; although, we all have a lot of opinions. And as soon as we
get into a discussion, you're all going to tell me your individual
stories about passwords. And they're all going to be very interesting,
but very few of them move the yardsticks ahead and that's what we
actually want to try and do so that twenty years from now we're not
having this same conversation about how we haven't made any progress in
twenty years and yet we all have more passwords.
So one of the things that we do believe is that, "To make progress we
have to systematize our knowledge a little bit better," try and agree
upon the things that should agreeable upon if we get the right experts
together. So at least we can say, "Okay, this is what we know and this
is where we have to go. And these are the questions that are still
open." But it seems we can't even agree upon the things we should be
able to agree upon, and that's what I think, you know, systematization
here is a bit about. So.
>> : Can you provide us with the [inaudible] from where these quotes
are from?
>> Paul C. van Oorschot: These quotes -- So in the talk, I'll give the
references. There's a paper that Cormac and I wrote in [Inaudible]
magazine in January/February of this year called "The Research Agenda
Acknowledging the Persistence of Passwords." And then we and two other
co-authors, Frank Stajano and Joe Bonneau at Cambridge, had a paper at
Oakland this year, "The Quest to Replace Passwords." And I think both
of these are probably from the first paper but some of them might be
from the second. And a lot of this talk is really stub material taken
from that and talking about to, in particular, an authentication
framework we put forth in the Oakland paper. But I think we see that
more as a first step than a last step.
Okay, so in praise of passwords: you know, everyone tells us what they
hate about passwords, but it turns out that there actually are a lot of
things that passwords have going for them. And most of them actually
are pretty hard to replicate than the alternatives that we propose. And
if we look at alternatives that are proposed, people propose their
alternatives and they don't really state what their requirements are.
They just tell you what their proposal is, and they don't even tell you
what problem they're solving. They're solving the password problem. But
what exactly is the problem? What are their objectives? Do they have
the same criteria in mind that you do?
And I think actually stating what your objectives are or the lack of
stating is one of the problems. So, for example, is defense against
malware on the end client? Is that one of the objectives that should be
met by alternatives? I mean, if it is anything -- almost all, you know,
browser-based password managers should get thrown out the window. Most
federated schemes probably should get thrown out the window. So if
malware on the end client is one of your threats that you're trying to
address, you know, that should be stated explicitly.
And then it turns out that a lot of the alternatives proposed, you
know, we should end discussion of them right off the bat. But we don't
even seem to agree upon what the threat models are that the
alternatives should have. It also turns out that because there are so
many different stakeholders, we do have a lot of different interests
and the threat models of the different stakeholders or the factors that
they weight heavily as being important are very different. So, you
know, you take the website owners, you take the users, you take the
corporations users work for, you take the browser manufacturers, you
take the other software companies, everyone's got a little bit of a
different list. You know, who loses out? Who has to pay what costs?
What liabilities are there if something goes wrong?
And so everyone's list is a little bit different. That makes coming up
with a replacement challenging. So it's actually a lot harder than it
seems to come up with a replacement mechanism and alternative. It's not
in anyway a simple security usability tradeoff. In fact, a lot of the
security requirements compete not only against usability but against
other security requirements some of which are contradictory.
Deployability is hugely understated and doesn't get much attention in
the academic papers. You know, the economics: the quote here is, "The
economics might play as large a role as technology," who has to pay for
what.
These are issues which aren't the standard types of problems that we
solve as computer scientists. Are we looking for one single solution
that solves all the password problems in the world, or are we looking
in each scenario and each environment for the best fit for that
environment and scenario with means we're going to have many more than
just one solution replacing passwords. Some people think you want the
silver bullet and I think we're going to be, you know, waiting another
twenty years and still wondering where the silver bullet is. So it
seems clear to me the silver bullet hasn't happened; it's very unlikely
to happen. But then we have to admit we're not -- we're going to have
to take several other solutions.
How do we weight the requirements? So if we look at all the different
stakeholders, the properties that they think are important are
different. And they should be different, and in different environments
they also become different. So how do we come up with those factors?
And I think that's still part of the ongoing future work, but it has to
be acknowledged. And I think that there is a real diversity of players
and stakeholders involved which leads to different requirements.
So a couple of challenges in evaluation, and I guess we talk about this
as the pie slice problem. So if you think about all the different
threat vectors and, you know, the standard advice we give everyone is
choose longer, more complex, difficult to guess passwords. Well that,
you know, makes it harder for users from a usability point of view. It
helps not at all against keylogger attacks. It helps not at all against
phishing attacks. And so now do we know that the brute force or online
guessing attacks are where 95% of the problems are? Because if they're
not, and if 95% of our problems are keyloggers then all that nonsense
we tell people about choosing longer passwords is really a disservice
to them.
So we don't know how big the pie slices are in terms of which threats
can contribute which percentage of the damage. But further to that is
the point that there's a difference between a password being
compromised and there actually being harm to an end user. So if there's
a keylogger that gets your password, that doesn't necessarily mean that
you've lost anything because your password hasn't been exploited. You
know if it's a password for a bank account and the charges are reversed
after the money's taken out, was there actually harm? So how do we -Even if we did know all the pie slices and we knew how many passwords
were lost by what means, how does that translate to user harm? We don't
have the data on that.
So when we're trying to figure out what the best alternative is and
we're trying to figure out is the cost greater or is the damage done
greater than the cost of an alternative, we don't even know how to
measure the cost, and so we need some more data. And that's not easy
data to get. So can come up with some estimates and some plans, but I
think we have to acknowledge that we're kind of data poor here and that
in the absence of some of this data that we can't come up with a
conclusive decision.
A separate problem is lack of scientific method, and this I think goes
to what I think of a computer science culture or values problem. The
type of work -- Most of us in the room are probably from some sort of
computer science or engineering background. And, you know, the types of
things that we were taught and we somehow came to value were like
timing, how fast things are, and doing mathematical things. I mean,
most people don't like anything to do with end users. I mean, they're
messy and they get in the way and they complain a lot. If we actually
have to run user studies with real people, you have to get approval
from, you know, corporations or university boards. This slows things
down and not everyone agrees. So there are things that, you know, in
other disciplines they just take for granted that these things we have
to deal with, "We run user studies." That's done very much in computer
science. And we're seeing a little bit of a shift the last five or ten
years; there's more of a push towards usability and security, and
there's a strong little sub-community.
But by and large this is not something that our broad computer science
community values or does very well or even understands how to referee.
So I think that's a longer standing problem in terms of publishing and
coming up with criteria on how to evaluate. That complicates it. And I
put this down to really -- "A lack of scientific method." We don't
actually do science in computer science that way that, you know, you do
in a lot of the other natural sciences. That's a whole separate
discussion we could have, and I know that discussion has been had and
it will continue to go on.
Then I've got this point here about cherry-picking versus benchmark. So
a lot of the papers and proposals that you see written and presented,
they put forth their proposal without telling you really what problem
they're solving other than the authentication of password problem. And
then they pick one or two things where their proposal shines and then
they talk about how it's better than all the others. And they somehow
don't talk about the 18 areas where what they're proposing has
problems. And we kind of -- I don't know, we kind of accept a lot of
these papers, and we don't have what I would say is a standard
evaluation methodology. And so that's what I think is one of the
biggest pieces missing that we should evaluate even though some factors
are more important than others. Some properties are more important than
others in different environments and scenarios. We should still
evaluate new proposals across all these different factors. And then
after we see how they rate on the different factors, which allows us to
compare them to alternatives, we can say which might be more
appropriate in which environments and scenarios.
But we to date haven't done that too much. And that's a bid part of the
paper that I with three authors, including Cormac here, had presented
at Oakland this year. And I'll talk a little bit more about that.
So we came up with what we call a usability deployability security
evaluation framework, UDS framework. And the idea is specifically this
was for remote authentication, for Internet authentication, not to a
local laptop but to a remote website because the problems are a little
bit different if you're authenticating just to a local laptop in terms
of threat model and technologies that work really well. So we came up
with 25 characteristics or benefits, properties that we framed as
benefits, so we framed the property as a positive for comparing
different proposals.
Eight of them were categorized as usability-related. Six of them were
categorized as deployability-related, and eleven were categorized as
security-related. And there's nothing really magical about that set of
twenty-five, but amongst the four co-authors we argued back and forth
about which ones we should include. And there's a second list of things
that if we wanted to extend the list we can include. But those were
twenty-five that we thought were interesting as a baseline, and then we
came up with an evaluation methodology using those twenty-five
properties. And then we did kind of a benchmark analysis of thirty-five
different schemes which actually helped us refine which twenty-five
benefits that we thought should be in the course and also the
definitions of those twenty-five benefits evolved a little bit as we
iteratively scored and changed the criteria and then rescored the
alternatives.
And so I'll go through a little bit here of a discussion of what the
twenty-five properties are and then a couple of the schemes including
basic passwords, how we rated those, and then some overall conclusions
that we drew and where to go as next steps. So before I get into the
properties if we look at all the different password alternatives, we
can group them into categories of schemes and that helps us compare
things as well. And this a lot of the schemes that we evaluated is in
this list here. So there are password managers, these are built into
the browsers, as one category. So they're built into browsers like
Firefox. Then there are stand-alone password managers, things like
LastPass, and some of them are Cloud-based and some of them are clientbased.
There are schemes that involve proxies, so you've got your end client
and you've got websites you're trying to log into. And then there'll be
some proxy machine that your client goes to and it will communicate
with the end schemes. And those proxies can address some of the
concerns and deliver some of the characteristics that we want. There
are what we call the federated schemes or variations of single sign-on
schemes where somehow you log on once somewhere to some third party and
that third party then will get you logged into a bunch of other
schemes. There are graphical password schemes where there -- This
really is the end result is a password just like a text password. It's
a string to compare, to verify against, the end site's going to verify
against. And the idea with graphical passwords, you know, is to claim
that we can leverage some inherent advantages of our visual system for
memory or usability or something like that. There are a category of
what we call cognitive schemes where the end user have some secret in
mind whether it's a picture imaged-based or whether it's text-based or
something. And there's a challenge, and the user somehow translates the
challenge using the secret that they have into some response. Some sort
of cognitive workload has to go on in the user's mind in answering the
challenge. There are paper token schemes. So the paper token schemes,
typically these involve lists of one-time passwords. They're very
popular in Europe actually.
A side point to mention here, our categorization here there's several
different ways you could categorization schemes. So we have a scheme
called paper tokens. We didn't actually in the Oakland paper formally
have a category called one-time password schemes because some of the
one-time password schemes also involve hardware tokens which are the
different categories. So we could categorize things a little bit. There
are some alternatives that you can choose in categorizing schemes.
There are biometric schemes; we all know the standard biometric
schemes. It turns out that again they have certain advantages in, you
know, supervised environments and they tend to be less appropriate for
remote authentication or the web for some well-known reasons.
There are schemes involving hardware tokens, USB keys, dedicated
hardware. There are schemes involving cell phones or smart phones used
an auxiliary device. Not that you're logging in with your smart phone
but that you're login in with a laptop or desktop machine and you're
somehow using your smart phone as a second channel or a trusted path or
something to provide a property you can't get with a desktop machine
alone. And then there's kind of complicating or muddying the water a
little bit are these password recovery schemes because they're not
really typically password replacement schemes but they always come into
discussion when we do talk about password schemes.
So what I'll do here, I'll go through the 25 different -- Well, I don't
know if I'll go through all of them. But I'll try and give a flavor of
the types of benefits we're talking about here. And so U1 through U8
are the usability, then 6 deployability and 11 security-related.
Actually the last two are privacy related as well. So this is for what
we call legacy passwords or, you know, ordinary web passwords; this is
how we rated it. So on this scheme here, on this code in here, black is
-- Sorry. So green means we grant the full benefit. So for example,
passwords have nothing-to-carry. If passwords are remembered in your
minds, you don't have anything to carry because you're typically -other than your own body. We don't call that carrying anything. So text
passwords get a full benefit of nothing-to-carry. We have this category
called Quasi, or this rating called Quasi, which means almost and
infrequent errors. So with text passwords you have almost infrequent
errors. Usually we don't make too many mistakes typing in our
passwords. We type pretty well. Sometimes the lock key is set and we
make some errors. Sometimes you're on a strange keyboard and making
typing errors. But generally we almost -- we have almost infrequent
errors there. And Missing -- So the black ones here means that we don't
have that benefit.
So text passwords memorywise-effortless: well it turns out if you have
50 passwords even if you're reusing a lot of them you still have to
remember stuff, and as you get additional accounts, the cognitive load
goes up. So text passwords don't score well there.
Are they scalable-for-users? Okay, we're talking about 50 passwords
versus 100 passwords versus 3, it's not re-scalable. Text passwords:
more accounts means more load. Nothing-to-carry. Physically-effortless:
so for text passwords you do have to type. That's a physical effort as
opposed to some other schemes where there's actually no physical effort
whatsoever. So we don't grant that benefit for passwords. I mean, it's
not a big effort but it is an effort. Right? Facebook Connect? You
actually don't have to do any physical effort.
Easy-to-learn: well passwords have a great advantage here because
they're kind of the first thing you learn when you get your first
computer. So maybe the ground's unfair here; the rating scheme it
tilted towards passwords, but we give passwords easy to learn. We give
them that benefit.
Efficient-to-use: yeah, we can log in a couple of seconds, maybe five
seconds, if you have a very long password and stuff. But infrequenterrors: talked about. Easy-recovery-from-loss: one of the big
challenges with a lot of other schemes is if somehow you lose your
authentication device or token or whatever, how do you get recovery?
With passwords we have various ways or re-getting a password, either
over time we've iterated different schemes and so it depends on the
environment. But sometimes you can get mailed back a password.
Sometimes you can call up a help line in an enterprise or corporate
environment. But typically you don't have to wait three days to get a
new hardware token shipped with text passwords. Oh, [inaudible].
Accessible is about people who have not cognitive but physical
challenges, so the two big categories here are blind users and motorimpaired users. And we call -- The baseline we set here was for, if
again, skewed a bit towards text passwords. If users can use text
passwords but they can't use an alternative then we would penalize
those proposals in accessibility. So this is skewed toward text
passwords. [Inaudible]?
>> : Yes. So at the [inaudible] workshop last week Dirk, from Google...
>> Paul C. van Oorschot: Dirk Balfanz?
>> : Right. So he talked about four good properties of passwords.
>> Paul C. van Oorschot: Oh okay. Okay.
>> : And one of them was, you should be able to easily to tell your
secretary what your password is.
>> Paul C. van Oorschot: Delegation, yeah.
>> : Right. Do you have...
>> Paul C. van Oorschot: So we don't have that up. Let me just think if
that falls into one of the other -- Look there's a lot -- We could come
up ourselves with another 25 properties that are nice to have. That
turns out to be a huge one. If you go to anyone who's in a senior
management position, if you propose an alternative and you can't have
the secretary read your e-mail while you're away, that won't get
approved for internal use.
>> : That sounds really bogus.
>> Paul C. van Oorschot: Yeah.
>> : You should never do that, need an authority delegation mechanism
to let your secretary read your e-mail that does not involve giving her
your authen.
>> Paul C. van Oorschot: You're absolutely right. But it turns out that
a lot of proposals don't even let you do that. Right? And those schemes
will get squashed by the senior people. But let me see, does delegation
fit in...
>> : [Inaudible].
>> Paul C. van Oorschot: Does delegation fit into -- I don't think we
have that amongst the usability properties.
>> : It would up show up as a negative in the some of the security
stuff, I guess. Right? Because a lot of them are a replay in some sense
[inaudible].
>> Paul C. van Oorschot: Yeah, but I guess you could envision...
>> : But we don't have it in usability.
>> Paul C. van Oorschot: Yeah, but I guess you could envision
delegation schemes that don't impact security as well. So we tell -Because then that also brings into play whether you have revocation,
right? And -- But I'll be interested to look up his set of four there.
Stewart?
>> : Back to [inaudible] point, if you're using a biometric, for
example, and you die. You're next of kin cannot use that biometric to
get back at your online data. So if they need to get to your stock plan
or anything...
>> : If you die without telling your password, you have the same
property.
>> : I understand. But you can write down your password and put in your
will, and lots of people do.
>> : Oh my god.
>> : You can't do that with a biometric. So there is something -- there
is some usability factor there that is worth capturing because unless
you -- It's a deployability issue to make every website on the Internet
that uses passwords to go and also build a delegation feature for this
purpose that...
>> : [Inaudible]...
>> : ...[inaudible].
>> : ...put it in a safebox with your will.
>> : Hmm?
>> : Drink a can of Coke and put it in a safe deposit box with your
will.
>> Paul C. van Oorschot: Yeah for a couple more [inaudible].
Negligible-cost-per-user: that becomes important if you're trying to
have a lot of users and grow a company cheaply. But in general, cost
per user we thought was important. Server-compatible: do you have to
change? If you put out an alternative, do you have to have a couple
hundred thousand or a million or tens of millions websites all of a
sudden change what they're doing in order to adapt to a new scheme?
That's not so good, so server-compatible is important. Browsercompatible: do you have to change anything on the desktop end or can
you get access with this new alternative for passwords without changing
any on the client desktop. With an ordinary browser can you get in? Is
it mature technology? Has it been used outside of research environments
by the same people that are proposing it and tell you it's a good
scheme? Has it been used by people not involved with inventing the
scheme? Has it been used by hundreds of thousands of people in a real
word environment. Is it non-proprietary? Do you have to license stuff?
Do you have to -- intellectual property or is there secret, you know,
trade secrets involved? Or do you have to believe people when they do
their security analysis that it's secure? Can you actually look at it
yourself?
So it is open source? Now the security ones. Resilient-to-physicalobservation: I guess you can think about this as shoulder surfing
including with recording by, you know, camera devices. Is it resilientto-targeted-impersonation? If I know Crispin and I know Crispin's got a
cat named Fluffy and he drives a Porsche and whatever, does this
information help me guess his password? Is it resilient-to-throttledguessing? So throttled guessing. And we also have an unthrottled
guessing. So I guess it's not quite the same if you look at the
definitions, but one of these is essentially online-type guessing and
one of them is essentially-type guessing. Is it resilient-to-internalobservation? If we have malware in the client or if we malware on the
communications link, and if you're using SSL let's assume that this
self-fails for now because maybe there's PKI problems or some other
issue. So if you're internal to the communication channel or the
machine, is your scheme going to be resilient. So, for example, one
time password schemes, even if you observed one password going over SSL
and you got inside the channel, that one password would not help you on
the next log in.
Resilient-to-leaks-from-other-verifiers: so if there's a bunch of
different websites and, for example, you reuse a password and they're
storing password hashes one can leak a database that would help you log
into another. That's the property we're looking at. That's the property
we're looking at there. I'm sure never in any Microsoft. But resilientto-phishing, resilient-to-theft: the theft one in particular we're
thinking about schemes involving hardware devices or smart phones or
something where you physically steal something. We don't think of this
theft for something that's in your mind. We don't think of that as
being susceptible to theft so it kind of by definition is resilient. If
you write your passwords down and there's a piece of paper that can be
stolen then that's subject to theft. But when we think about base
passwords, we're not thinking of password lists you've written down. So
we do grant basic text passwords to be resilient to theft. Do you have
to have third parties? You have to have trust in third parties. Does it
require explicit consent? We think that it's beneficial if you have to
explicitly -- from a security perspective you have to explicitly
authorize, you know, an authentication as opposed to, again, there's
some schemes where automatically everything's authenticated without
even being aware as a user. And unlinkable: so here we're thinking
about no reusing user names but, I guess the canonical example is if
you think about biometrics. They're linkable. You're biometrics going
to be the same on all kinds of different applications, so that's an
example where it would not have the unlikable property. But generally
passwords can be used in ways that are unlinkable. If you reuse your
passwords everywhere and if you reuse you user names, that's a
different story. So this kind of -- You know, I don't want to go into a
big long discussion of which benefits should be added here and which
ones are less important. This happens to be the baseline for the paper
that we presented that we used, and we think it's interesting as a
start point from which other people might choose which set of 25 or 45
or 20 properties they might want to use.
And then once you decide upon your list, all the schemes that you're
comparing should get rated against the same list. Okay, so I don't
think it's worth going through. I want to leave some time for
discussion. But we could go through it and for the Firefox encrypted
password manager see what properties it got. And this coating here I've
added a plus if this is a benefit which is a better rating than text
passwords and a minus if it's a rating that's worse than regular text
passwords. In the chart I'll show you later and in the Oakland paper,
we actually had a little different scheme which we had red and green
which showed which were improvements or not. There's different ways of
doing this. One time passwords over SMS text messages: we could go
through that. In general this is what the table looks like, and here
are all the 25 properties. Here are all the 35 schemes that we rated.
And here are all the fun -- Yeah, so here green is better. Red was
worse. Full dot means it has the benefit. Hollow dot means it almost
has the benefit or quasi. Blank means doesn't have the benefit.
So we had a lot of interesting conversations over a lot of phone calls,
and we changed all of these dots -- probably every dot about six
different times to finally get here. I think most of these are probably
more or less right, and some of them, you know, it depends on the
definition. But the exercise of going through and comparing schemes,
more important than what the actual dots are, comparing, you know, two
different password managers on all of these properties and then saying,
"Well which one for this property? Is this scheme better than this
scheme?" The dots in here don't really matter as much as thinking about
how does this scheme do on this property. And also, I mean, if you're
filling out a chart like this, the blank is kind of like a zero rating
and the dot's kind of a one rating. And I guess the hollow dot, the
quasi, you might think of that as an almost or point in [inaudible].
You know, you could go through this and maybe have a zero, partial and
full rating. The granularity that you want to use, you can make that up
on your own and there's advantages and disadvantages. But we kind of
decided that we didn't want to have a continuous rating between 0.0 and
1.0 because you're going to fool yourself into how precise you are. And
it's going to be impossible within the definitions to be too precise.
It's more of the numbers, or the final ratings inside are far less
important than the consideration of this set of properties.
So maybe a couple of observations about, you know, things that we
learned from doing this exercise. There are some sets of benefits that
are incompatible or rare. So for example, if you want a scheme that's
both memorywise-effortless, you don't have to remember anything, and
you don't have to carry anything, well that seems hard to get because
generally if you don't have to remember anything, you probably are
carrying something to do the remembering for you. Just, you know,
that's probably the way it works out. So getting both of those things
is hard. Another scheme, another pair that's hard is if you want to
have something that's server compatible meaning there's no changes on
the server, the existing text passwords verification so you're probably
doing comparison against a fixed static stream, you're probably not
going to be resistant to internal observation. Because if that's a
fixed static string, once you observe it once you're going to be able
to replay it. So by insisting that you want to have the property of
server compatible, you're probably going to end up with a bunch of the
problems that come with static text passwords.
So there are sets of benefits you can't get. And I think it's
interesting to think about that because then if you try and generate a
requirements list and there are no schemes that actually have all of
these requirements, you're going to have to say, "Okay, now we're going
to have trade some of these off. We're going to actually give something
up if we want some other benefit."
The table also has -- it can be useful if we want to see -- if there's
only one or two schemes or categories of schemes and if there's a pair
of benefits that can only be granted or is only granted amongst, you
know, one or two schemes you can then look at it and say, "Well what is
it that's peculiar about that scheme? What aspect of that scheme lets
it have both of those when none of the other schemes have it?" And them
maybe you can try and adopt that property into other mechanisms. So I
think that's another useful aspect of a big table like that other than
all the fun conversations we had trying to fill in all the dots.
So coming up with combinations of schemes or sub-properties of schemes
and building those into other schemes can make for some nice
combinations. So our overall observations: the password managers -- And
this is quite subjective but let me just throw out some overall
feelings we had. The password managers gave us a lot of usability wins
and a lot of security wins, some security wins, but you still ended up
with managing static passwords, static text passwords which were replayable and, therefore, going to have a set of problems. So they're
going to be suboptimal from a security position.
The schemes involving the proxies gave some interesting properties not
available elsewhere, but the security wins were relatively minor and
there were larger usability and deployability costs. The federated
schemes and the single sign on schemes, the usability seemed okay
actually surprisingly good but they had some deployability
disadvantages. You typically -- And it's hard to measure but you have
to have buy-in from a lot of parties to get the federated schemes to
work. And the security gains were really questionable. A lot of the
federated schemes kind of give you way to many options, and you can do
subcomponents using various technologies. And some of them are
passwords and some of them are maybe PKI related, but in the end you
don't really know what you're evaluating. So they can claim to maybe be
able to offer high security but in any particular deployment people
might've made choices that use lower security technology. So we didn't
really have confidence that the claims of security in these federated
schemes were as good as they might be advertised. The graphical
passwords: some of them offered some usability advantages, but there
were deployment disadvantages and the wins in security were relatively
minor. So they might win on one or two aspects but it didn't seem to be
sufficient to be a winning scheme in a grand scale. The cognitive
schemes: none of them really seemed very viable. We kind of thought
that may be this was a sign that people are hoping for something that's
not going to happen. But the security gains were very small and there
were much larger usability and/or deployability costs.
The schemes involving paper tokens or hardware tokens of some sort, you
know, dedicated hardware or using the phone as an auxiliary device,
these were the best overall for security. A lot of these were one-time
password-type schemes and so we shouldn't be surprised that they were
best from security and so they could resist internal observation. But
the usability and deployability seem to be bigger barriers than people
realize, and one of the pieces of evidence there is that they haven't
been as broadly adopted as one might guess because some of these
schemes have been known for ten or fifteen years.
Biometric schemes actually had some usability advantages, some
usability disadvantages, but they were surprising disappointed both on
deployability and security aspects. And the password recovery schemes
again, they're not really meant as replacements; they're just kind of
fallbacks, and often they cause security problems.
And the big picture here: none of the alternatives of the 35 we looked
at -- We tried to look at the ones that were not only prominent but
also had interesting properties, none of them came close to having all
25 of the benefits. And that's maybe not surprising. But none of them
even preserves all of the benefits of our old hated text passwords, so
you're very much trading off one set of compromises. You're giving
something up in order to get something else. And that's probably why
we've had a lot of trouble moving away from text passwords because
people don't want to give up anything, and they really scream very
loudly if they have to give up anything even if you argue that what
you're getting back is more important than what you have to give up.
Where passwords excel and that's typically usability the highest
security alternatives are pretty weak. So when you move to higher
security you typically are reducing the usability. And almost always
you're going to reduce the deployability. The depolyability was a
category, a set of six characteristics that basically were baselined on
text passwords. So everyone's going to do worse than text passwords on
deployability because that's the de facto widely deployed scheme. So
there's a cost in moving away from the incoming.
And in general the small security or small usability gains are going to
be dominated by the disruption caused in moving to an alternative. I
guess the biggest summary comment here is using this evaluation
framework, the UDS evaluation framework, we really did feel again that
the -- we say the journey is the reward, the discussion is more
important, the discussion of the properties and the ranking of all the
different schemes against these properties, is more important than the
scores we got. And we're kind of hoping that this can be the start of
us having some sort of a more standardized evaluation methodology to
fairly ranked schemes so that every different person proposing a new
scheme doesn't cherry pick on their own properties that benefit their
scheme the most.
What I'm most interested in and in particular discussing with people
over the next couple of days and onward is what -- if we want to make
some more progress on this rather than just, you know, exchanging
stories about passwords and how we hate them and how we choose
passwords and things like this, how can we move ahead. So here are some
ideas on how we might move ahead and some of these are from, again, the
research agenda paper that Cormac and I had earlier this year. But I'd
be interested, genuinely interested in getting your opinions on which
of these might be interesting research directions to go forward on or
other suggestions of what to explore.
So one is looking at password managers in greater detail. I don't think
they even studied sufficiently for the usability that they may be able
to give us if we're going to be stuck with text passwords anyway.
Better systemization and better understanding of what they can offer.
For the federated systems and single sign on-type systems, getting a
better understanding of why none of them seems to have done very well
to date, and the ones that failed really badly which -- Well, I guess
some of them are deployed now, but some of them have failed very badly
and better understanding why they failed. And I'm not sure we have a
really good understanding of that. When we talk about password
strength, everyone talks about strong passwords, and we haven't really
defined exactly what that means. But a better consensus on what level
of strength is required in which scenarios in which environments would
maybe be helpful. Coming up with advise in password policies that are
realistic for real-world people and not giving people advice that we
know they're not going to follow or they can't follow and it causes
them just to reuse passwords and things like that.
Systematically studying how to combine mechanisms and properties from
different mechanisms to end up with overall schemes or combined schemes
that have, you know, the best of the security properties of the
individual schemes without losing too much -- or while retaining the
usability of the individual schemes and the deployability with minimal
deployability impact. So these are some of the ideas. But what I'm
really interested in is getting some thoughts on where we should
explore next steps to try and move ahead or if we should just, you
know, admit it. We'll just stick with text passwords for another 25
years. What the heck? They got us this far. So that's really what I
have to say, and I'm interested in having some questions and
conversations.
>> : Questions?
>> Paul C. van Oorschot: [Inaudible] Crispin?
>> : Yeah. Some properties strike me as vastly more important than
others.
>> Paul C. van Oorschot: Right, right.
>> : In particular the one that's jumping into my head after listening
to your talk is server deployability. Me and my two friends are
starting out some new social networking site. We think we're going to
be the next Zuckerberg. You know, we're going to be billionaires some
day and we can deploy exotic stuff then, but right now it's just me and
these three guys. And we want our website to be as accessible to users
as possible, so it has to be compatible with all clients. What are we
going to do? We're going to do passwords because anything that's a
barrier to any user is not acceptable.
>> Paul C. van Oorschot: Yeah, so you're Facebook. So I guess in that
sense if we're going to stick with server compatible, the logical
implication is...
>> : Actually I think it's client compatible. I [inaudible]...
>> Paul C. van Oorschot: Okay, because there are two. One is how many
servers have to change something and two --. So both of these are
important. The client compatible, you know, you might be able to get
people to download stuff or change something on the desktop.
>> : Like that's the point is that the clients are now diverse, you
know, Android phones, Windows phones, tablets, iPads, you name it, it
has to work on anything that's speaks http.
>> Paul C. van Oorschot: Yeah, well if you're going to end up -- So are
you willing to say ten million websites will have to change and that's
less important than deploying new client soft?
>> : I'm trying to think of something that would cause three guys'
social network to choose something other than passwords. And I can't.
>> Paul C. van Oorschot: Well, it's a really big barrier to adoption if
you...
>> : Yeah.
>> Paul C. van Oorschot: And so then -- But then you might end up stuck
with all the problems with passwords being replayable and resilient to
internal observation and...
>> : And that doesn't stop three social networking [inaudible] from
taking off.
>> Paul C. van Oorschot: Yeah. But the three guys, they don't really
care about security. They just want to get rich.
>> : Right. And that -- Economics matters more.
>> Paul C. van Oorschot: Well.
>> : You...
>> Paul C. van Oorschot: But again different environments. So that's
one environment, you and your three buddies. Another environment is
Microsoft Corporate. Are they happy with the security level that I
provide? So we have a different weighting of criteria.
>> : Yeah. Related to that point, aren't passwords the only thing that
make the nothing-to-carry criteria fully?
>> Paul C. van Oorschot: No. I think...
>> : [Inaudible]...
>> Paul C. van Oorschot: ...we have...
>> : ...[inaudible] that does biometrics?
>> : No.
>> : [Inaudible]...
>> Paul C. van Oorschot: So biometrics are nothing-to-carry.
>> : You have to have a device that...
>> Paul C. van Oorschot: So does your cell phone count?
>> : No. No. Someone's like, "Hey, you know...
>> : By that definition are...
>> : I'm going to go somewhere where...
>> : ...any passwords...
>> : ...oh, my cell phone doesn't work here but I'm using a kiosk.
[ Multiple inaudible voices simultaneously ]
>> : But that's -- You have to carry that, and you know that
[inaudible].
>> : So I have a camera, right, that I could authenticate to with
biometrics but that I couldn't with a password because it has an on and
an off. And if I want to authenticate that to authorize that it's okay
to download the pictures that I've taken, that has an input device that
works for a biometric but not for a password.
>> : Okay, yeah, I think I see the distinction. The distinction is
passwords are nothing-to-carry, are completely ubiquitous and that you
know work everywhere.
>> Paul C. van Oorschot: So most...
[ Multiple inaudible background voices continue ]
>> Paul C. van Oorschot: On the nothing-to-carry, it's the password
managers which are really password schemes and the federated and single
sign-on schemes, which I think is nothing-to-carry basically because
we're assuming that aspect gets implemented by passwords. The cognitive
schemes and graphical password schemes are really passwords. We didn't
charge for the schemes that use cell phones or smart phones. We said
they were almost nothing-to-carry assuming that most people or a lot of
people or soon a lot of people will carry some device with them, so
that's almost a nothing-to-carry. And then a biometrics got a nothingto-carry because if you assume there is some input device...
>> : And that's the thing, I think that's a huge assumption in today's
[inaudible].
>> Paul C. van Oorschot: The point is there are laptops, think pads,
you know, [inaudible] your fingerprint readers which you may or may not
like.
>> : [Inaudible], though, is the demand is no matter where I am if I
can get to a PC, I need to be able to log in and get...
>> Paul C. van Oorschot: Yeah, so I think...
>> : ...my e-mail. Period.
>> Paul C. van Oorschot: ...in terms of scoring, though, we could score
the biometrics as nothing-to-carry and then charge it for not being,
you know, compatible with the infrastructure. I mean this we could
charge more to a deployability. You could make trade offs. You can make
trade offs in how you [inaudible].
>> : We've had ten hours of conference calls on the very question you
raise, whether biometrics are really nothing.
[ Multiple inaudible voices simultaneously ]
>> : I want to look more as the password manager schemes because it
looks like the password manager schemes you're talking about are
stateful ones. And I think it's also worth considering stateless
password managers which also leave nothing-to-carry required but have
some security issues. And it seems, you know, that there are some
interesting trade offs between the two.
>> Paul C. van Oorschot: When you mean stateful you mean that the local
clients [inaudible] remember or was it something in the Cloud? Or
what's your definition of stateful?
>> : Well, the stateful ones have a local cache of passwords of some
sort. The stateless ones derive passwords dynamically for each site off
of, say, a single master password.
>> Paul C. van Oorschot: Right.
>> : And, therefore, they're much more portable but it's much more
important that the initial password is a strong password and there are
security trade offs.
>> Paul C. van Oorschot: But I do think, again, we're starting to see a
little bit more research on password managers. But in my mind we went a
long time without any real -- Well, the literature spikes. And I think
the password managers deserves more of a spike if we think is an
important problem.
>> : Yeah, I'd like to speak to that a little bit more. And coming back
to this question of the pie chart, you know, what are the relative
risks of different attack vectors? This is something we've been trying
to get a grasp on for a while, and I think we have some swag that says
malware is the bulk of the problem and that password guessing, weak
password guessing is relatively low but password reuse is actually
quite significant. And, you know, ballpark maybe two-thirds malware,
20% password reuse is the risk profile across users. But for people in
this room I think it's more likely to say that password reuse is the
big risk. So that says to me that for us collectively a password
manager is a really good thing; it mitigates that risk of reuse. But
then you're putting everything behind a single secret. You're putting
everything maybe in a local cache. And then that other spector of the
two-thirds malware thing for most users is the big problem.
>> Paul C. van Oorschot: Is it true saying with the password managers,
though, because we did a little side analysis where we were comparing
another alternative to password managers with and without an encrypted
password. It was like -- So, you know, by default I think the Firefox
password manager will store your passwords but it's not encrypted under
a master. If you look at the standard, you know, properties we had for
rating here it turned out that if you had a password manager with a
master password, there's a danger that someone could observe you typing
in the master password. If there's no master password, you can't
observe people typing in the master password. So it almost looks worse,
if it's against the criteria we use, worse if you have a master
password because you're charging for something that you don't penalize
for the absence of.
So like what threat model -- If your browser itself is storing the
passwords and it's storing the passwords for fifty websites, what's the
threat model that's going to get you into trouble? It's malware in the
desktop or somehow you've got malware in the browser that can read that
stash. But that's a lot different -- So is malware on the desktop the
problem you're worried about?
>> : I would say the average user...
>> Paul C. van Oorschot: Or if it's backed up. If your database gets
backed up then that's a risk of theft. But it's -- I don't think we've
studied this enough.
>> : Yeah. It's a tough point. The big risk there is I'm going from
putting all my eggs behind four baskets -- You know, I have four
passwords that I use across the fifty sites -- to putting all my eggs
behind one basket. Where, you know, maybe it's less guessable set of
passwords but as soon as my machine is [inaudible], you know, it's game
over for everything. [Inaudible].
>> Paul C. van Oorschot: I mean, and there's also the password managers
where you have one master password and then maybe you generate all
those site passwords based on, you know, a hash of the master and the
URL. And there's other password managers which just take your existing
passwords and throw them into a bag and you get access to them. And
then if you're evaluating the password managers, are you assuming that
you're going to keep all the users' [inaudible] passwords or that this
password manager is going to generate brand new passwords for all the
sites. So it's not so easy to compare them head up there. But I think
that'll be interesting work.
>> : So one thing that strikes me every time I look at this anew is
that like if you look at federated here -- I mean I guess we talked
about this a little bit already, but I think we really missed out. We
didn't have a complete-enough list on usability stuff. If you assume,
you know, users govern what goes on and it looks like federated schemes
are just great. From a usability point of view and the world will
organize itself around what users what, it looks federated should've
conquered the world and that hasn't happened.
>> Paul C. van Oorschot: So federated -- If we look at things that are
green in this quadrant here, this is our usability rows here. The green
means better than text passwords. I guess the password managers and the
federated have a lot of green. The biometrics have some green but also
some red. So, yeah, so these should've done better unless the
deployability is a bit roadblock.
>> : [Inaudible] huge barrier in terms of federated. Like [inaudible]
didn't do federation with some of our really big partners. Like it's
one of those things to where, you know, if not every single scenario
supports it then you're going to have to have other mechanisms. That's
really been the [inaudible] for us as we've tackled the federation
scheme [inaudible] all our partners.
>> Paul C. van Oorschot: I think your point is that we have a list of
eight usability properties there, and there might be a few others that
are show stoppers. So when we talked about these symbols, too, there
were other symbols. There were some that we thought we might designate
a row as an absolute must-have. So that if you're missing a bullet
there, the scheme just gets lost out of consideration. But there's
other properties on some schemes that are so bad we thought we should
put the skull and crossbones in there. That if the skull and crossbones
shows up there, that also --. So even if you have the mandatory ones,
if you one skull and crossbones that just blows it out of the water.
So, you know, which ones are we missing here? And it's...
>> : Yeah, I don't disagree what you're saying about deployability, but
I think, you know, I mean it seems like Open ID is -- It's the case
that users are beating the door down saying, "We demand this federated
stuff that looks so good," right? I mean that's far from being the
case, right? So we clearly have missed out on stuff there. You know,
delegation is one good example. But there clearly must be other stuff,
right? And maybe we're just being too generous when it comes to
efficient to use, right, because, you know, you do your password in
about three seconds. So if it takes twenty seconds it doesn't sound
like a lot but it's a lot more than three seconds.
>> Paul C. van Oorschot: Yeah and then if you're doing it twelve times
a day, three seconds is maybe your threshold. If you're doing it once a
month and it's online banking or it's something that you think is
really important, maybe fifteen seconds is fine.
>> : So do we know that we can actually use this model for anything
predicted? I mean if we come back and say, you know, these are
adoptions rates, for example, and hardware tokens, this is where it
would map out [inaudible]? There's a correlation between [inaudible]...
>> Paul C. van Oorschot: We have in fact. But one of the related
observations we made was if we look at hardware tokens here -- So you
look at these passcode generators like Secure ID, you know, they do
fantastic on the security here and the usability's got some issues.
Like what was the roadblock? These things have been around for a long
time. Is it cost? Is it the users don't like it? So we don't know how
to weight these different properties. And some of them are what I would
call heavy hitter properties and they should be weighted ten times more
than some others, and that's where I don't think we have enough
information yet or enough understanding.
>> : Is that where the next step in research is, is to, say, research
the fact [inaudible]?
>> Paul C. van Oorschot: One of the things that was suggested that we
could do was, you know, to take these properties and then to say, "In
scenario X this is the weighting that should be given to these
properties. And with that weighting which of the schemes then are the
best for that scenario?" And in a corporate environment or in a banking
environment, you know, I think people might be interested in knowing
for their one environment what is the best. And I think that's a
logical thing to do. Crispin?
>> : I think your table screams some predictive stuff. Passwords
totally dominate this market like everyone else is in the dust. And
they are the only one that scores six out of six deployability. And if
you look at the ones that score five out of six or four, they are some
of the most popular alternatives. Deployability stomps. The rest of
this stuff is like, "Ah, nice to have you." You must have the
deployability.
>> Paul C. van Oorschot: Yeah, I think one of the conclusions that we
did site was that the deployability seems to be not given enough
attention by the academics who are interested in -- you know, the
security academics are interesting in security. And so we've got all
these things with fantastic black dots here and, oh, we kind of
overlooked all this red stuff. Right? And by the way we had to give up
some red stuff here in order to get some green stuff. Right?
>> : Yeah, like one good deployability [inaudible] is that [inaudible]
cost per user, right? So [inaudible] is that, you know, if you want to
be Facebook and you want to put two billion people, you know, on your
scheme, well, ten cents per user even one cent per user is just way too
much. Right? [Inaudible] any non-zero marginal cost per user is just
end of discussion.
>> Paul C. van Oorschot: And by the way, you know, people launching
those schemes, some of them weight the security aspects very, very low.
Right? You know, what do they lose? You're signing up for free. They
made no promises to you.
>> : And users [inaudible].
>> Paul C. van Oorschot: Well, they don't care until they do. But they
don't --.
>> : Right. In general, I mean it's not [inaudible].
>> Paul C. van Oorschot: [Inaudible]?
>> : There is something that I've seen recently that seems to be taking
off, and I think it's very close to deployability. And that's where the
site -- The usual model is we expect people to switch to this model.
But what I'm seeing more and more is sites that say, you know, "Create
an account on this site or login with your Facebook account or login
with your Google account."
>> Paul C. van Oorschot: It's essentially a federated scheme though.
>> : A choice of federated schemes. In other words they don't require
that you get federated with that. They'll also let you create an
account. But if you have one then they'll let you use this and that way
you get the ease of use if you've already signed up for the pain of
having [inaudible].
>> : I notice that being very popular. But the thing that freaks me out
about it is the UX of, yes, "Create an account on our never-heard-of-it
website. Enter your Facebook password here." Hmm? See a threat?
>> Paul C. van Oorschot: One of the other huge, huge problems that I
see, and maybe this has been discussed a lot, I'm not sure, but you
know all these websites that essentially mandate that you're using an
e-mail address as your account ID. Okay, that's fine. But then the next
thing they do is ask you for your password. And so, of course...
>> : Yeah, but they ask you for any password, "Make one up for our
site."
>> Paul C. van Oorschot: But, of course, the natural thing you're going
to do is you're going to type in your Hotmail or your Gmail e-mail
address and then you're going to type in your Hotmail or your Gmail
password to that site that you've never before visited. That just seems
wrong. Now if it was a delegation scheme and they said, "Use your
existing Hotmail or Gmail e-mail address," and it goes into a window
and that got sent off to Hotmail or Gmail -- And this idea of having
third-party verifiers that a website doesn't get involved in. They just
get back a yes or no, that's kind of a pseudo-type of federated scheme.
It's kind of a delegated log in, right?
>> : If you look at some of the overt features in Win 8, federated is
going to get more interesting. It won't be ubiquitous or it won't take
over the world because Win 8 won't take over the world. Oh, of course
it will [inaudible].
>> Paul C. van Oorschot: So maybe the right thing here is to offer to
the people that want to escape can escape, and I'll hang around and
take questions from anyone else that wants to hang around for a bit
longer.
>> : [Inaudible].
>> : The doors aren't locked?
>> : The doors are not locked.
>> Paul C. van Oorschot: But it's such a polite group. You know?
>> : So other questions?
>> : To look at this chart, it looks like the security properties -- So
for the existing schemes right now if I ask myself, "What can I do to
make these things better?" In existing schemes they inherently have
some of kind of security properties. It's hard to improve that part.
But the usability part, to me being some things that have [inaudible],
can, you know, get better. Like for instance if it's easy to learn and
efficient to use. That doesn't seem like an inherent of those methods.
It's just, you know, maybe they have bad interface right now.
>> Paul C. van Oorschot: Yeah. So I mean there's lots of schemes here,
too, that it's tough. There were, you know, quite frankly some very
subjective ratings we gave here. Like some of these schemes are
proposed and there were never any user studies done, so how do we rate
how infrequent the errors are and how easy to learn it is? So how we
graded was based a lot on available information. And then easy to
learn: if you had a better way of educating people about it and you've
got a little time slice, could that -- I guess we'd have to do a trialerror to see if you can improve that. But, yeah, that seems an
opportunity to do improvement I guess.
>> : Right. But the discussion here is, you know, maybe that part we
can improve that. But the deployability which is currently
[inaudible]...
>> Paul C. van Oorschot: One of the things that we can actually -maybe a silver lining here that I believe, if you get a Microsoft or
Google or an Amazon and they put their weight behind one of these, all
of a sudden the deployability thing, you know, moves ahead a big step
because there's a big push and people like fall in line with it. It's
very hard for me to propose the scheme and to push that, but if a big
corporate player...
>> : Maybe if we called it something like [inaudible] it would just
really...
[ Multiple inaudible voices and laughing simultaneously ]
>> Paul C. van Oorschot: Someone like Cormac can move these things
quickly. So I guess there's places here where I don't think we should
be too pessimistic because someone's going to figure something out here
by weaving some of this stuff together. I mean like Google two-step.
You know, it's not really new. It's kind of like, you know, a one-time
password over some type of phone interface or even e-mail. But, you
know, if they get a lot of people behind it and the people learn how to
use it and it gives you some advantages, you can move ahead. Right?
>> : Just [inaudible]. When we're looking at new [inaudible] schemes,
we try to look at the banking sector because they have the most skin in
the game. And it's a little bit pressing actually to see what
authentication look likes in the banking sector. But if they don't move
to some new scheme then it's probably not better than the existing one
that they had. And if it's not good enough for banking then, you know,
what's the value for regular users [inaudible].
>> Paul C. van Oorschot: I think it's a little bit misleading, though,
to place too much on what you see of the banking system because, you
know, our perception as users I think is that they rely very, very
heavily on passwords. And they do use passwords. But, you know, a lot
of them are also using cookies to your browser and a lot of them are
also doing IP address monitoring and profiling and, by the way, the
banks typically can reverse all their transactions which you can't
reverse a lot of other stuff in the real world. So.
>> : So if they have a real economic cost to a user's account being
compromised then they absorb that cost. It's not really on the users
shoulders, it's on their shoulders. So they have the highest interest,
really, in keeping their user accounts secure.
>> Paul C. van Oorschot: What I'm suggesting is I think the banks are
doing more than you see.
>> : Oh yeah, for sure. For sure. And probably in the right direction.
But, you know, when it comes to specific schemes they haven't exactly
pioneered some, you know, new fangled scheme that's really going to
replace passwords. [Inaudible].
>> Paul C. van Oorschot: The cost, right?
>> : Just to comment on that: so I was interacting a lot with the banks
when the financial regulators said that they had to implement some sort
of two-factor authentication and most of them started using the
PassMark scheme. And the reason they were using it was because it was
something that could be sold to them that met the requirements not that
they believed it worked at all or anything. But they have a regulator;
it’s whatever the regulator tells them they have to do. They have to
figure out. And they did the absolute minimum that they could do to
meet that regulatory requirement. The assumption that there’s good
usability research being done there and that they know what they’re
doing, they’re pretty much doing what the government has to tell them.
So by trusting the banks, you’re basically saying, “Well, Uncle Sam is
the folks who really know what they’re doing when it comes to
authentication.” And I talked to those guys too, and they said, “Well,
we knew we had to pass some law because the banks wouldn’t do anything
if we didn’t. And we don’t know how this stuff works, so we figured
tell them they’ve got to do something and see what they come up with.”
And that’s how we got where we are.
>> : Yeah, that really kind of points to the fact that [inaudible]
today.
>> : Yeah.
>> : Have you given any serious study to the possibility that maybe
passwords really are the best idea?
>> Paul C. van Oorschot: Well…
>> : [Inaudible]
>> Paul C. van Oorschot: Well that was one the…
>> : Who are you and what have you done with Crispin Cohen?
>> Paul C. van Oorschot: That actually was one of the things we
mentioned in the [inaudible] privacy article was that, you know, they
actually are a pretty darn good fit for a lot of –- Like these websites
that want to give you a free newsletter or something and they’re asking
you for a user ID and a password just so that they can, you know, send
some spam your way [inaudible]. It’s like, “Why would you want to use
anything more secure than passwords?” Because they’re not actually
looking for security; they’re just looking for some contact. So, you
know…
>> : [Inaudible] access [inaudible]? Yeah, I use a secure ID. But three
guys website? Password looks like a winner.
>> Paul C. van Oorschot: I would think that two-thirds – You know, just
make a number up. Two-thirds of the places where passwords are used,
they’re probably perfectly adequate.
>> : Not just adequate, optimal.
>> Paul C. van Oorschot: Yeah. Yeah.
>> : Along those lines I take issue with this black dot next to easy to
learn because there’s a very minimal amount that I need to know to use
a password, but I need to know a lot more to use it well.
>> Paul C. van Oorschot: So easy to learn versus easy to learn well?
>> : Yeah, it’s like driving. It’s very easy to get license but
[inaudible].
>> Paul C. van Oorschot: What state are you from?
>> : New York. I’m getting used to this driving thing again. Whoo.
>> Paul C. van Oorschot: Yeah, so I think a number of these are very
subjective, and the idea of looking at these criteria is important. How
they were scored, very open to interpretation. But again with this
framework, you if you wanted to start up a group here for the next
month and define your own definition of what easy to learn means? I
think that’d be interesting. Again, if the same people come up with the
ratings for all of those schemes as opposed to using someone else’s
rating and then comparing it to your rating.
>> : I think we had like easy to learn and [inaudible] and then
frequent [inaudible]. There was kind of a coupling there. You know, we
argued a lot over the definition. So the idea with easy to learn was,
you know, it’s kind of intuitively clear what you’re supposed to do,
right, and the other [inaudible] were kind of captured elsewhere. But,
yeah, the factoring there is a little imprecise.
>> Paul C. van Oorschot: It’s subjective. Charlie?
>> : One of the criteria that I think is missing, it’s sort of related
to the resilient to internal observation, it’s sort of related to the
original question you brought up is it supposed to be resilient to
malware running on the end-user device? Which is, you know, an
extremely important problem and we tend to [inaudible] only because we
don’t have any solution.
>> Paul C. van Oorschot: We originally had two separate security
criteria. One was resistant to client-end malware and one was resistant
to communications-channel malware including looking inside SSL. We
collapse them up into this one.
>> But there’s one piece of protection that, again, it’s important for
scheme where passwords win is that if I’m at a public workstation or
something like that, I’m willing to type in my password to access my
Hotmail account but I’m not willing to type in my password to access my
brokerage account. And so it does give me protection against, you know,
the malicious end station that no federated scheme could ever provide
and most of the hardware-based things couldn’t either.
>> Paul C. van Oorschot: Yeah. Yeah. So I mean the idea of can you use
this on un-trusted client platforms is a little bit different than –
It’s kind of a one-time scenario as opposed to, you know, malware on
your home station at work.
>> : It’s kind of like one of highest, you know, meta points that kind
of jumped out to me and it jumps out [inaudible] it’s like if you look
most of the green here seems to occur on the security thing which seems
to be where the bulk of effort has gone. And it looks like there hasn’t
been that much hardware going into making things more usable. It seems
like, you know, well we all agree that passwords are bad. Why are they
bad? Because they’re not secure. Let’s work on that and then as an
afterthought express outrage/surprise when, you know, the world
[inaudible] your door. It looks like that way [inaudible].
And the other pairing that it seems to be, the more I think about it,
is really hard is like negligible cost for the use and server
compatible. No one except Firefox Password Manager achieves those two,
right. So it kind of means that if you want to be the next Facebook and
zero cost per user is a requirement, you have to rip out the existing
server infrastructure, right. There’s no – Unless we’re missing
something there’s no other reason…
>> Paul C. van Oorschot: There’s a point…
>> : The research agenda is come up with something that gets five out
of six in deployability. The only one going to never get is mature is
because you just came up with it.
>> Paul C. van Oorschot: Yeah.
>> : And have just not laughable security. If it can come close then
that would be an innovation because there’s nothing on your chart.
>> : An important part of this is you can do better in terms of…
>> : Deployability.
>> : …deployability…
>> Paul C. van Oorschot: Right. You’re not going to see…
>> : [Inaudible] something they’ve already deployed. So you’re never
going to see anything there.
>> : You can have a – play the puzzle game in your browser. I’m not
sure that’s a good idea but you can.
>> : What’s [inaudible]?
>> : Play tic-tac-toe and win. I pulled that out of my butt. That’s a
bad idea. But what you put into the browser doesn’t have to be text in
a field.
>> : Right. But it’s still not going to be green because it won’t be
any better than passwords. Right? You can’t – Everything’s build
already to use passwords so you’ll never see green there no matter –
even if your scheme is the null scheme, right, if it’s empty. If
[inaudible]…
>> : Well, I didn’t ask for that.
>> : …if [inaudible] except everyone.
>> : I didn’t ask for that. I was asking for five dots in the
deployability realm.
>> : Red circles. Not green and red.
>> Paul C. van Oorschot: Yeah, you’re never going to see green because
– you not going to see green because you can’t do better than solid
dots.
>> : So there’s nothing on this chart, there’s nothing I’ve ever heard
of that gets five out of six in that. And I agree with you that it’s
not possible to get six out of six because mature is going to fail for
any innovation.
>> : Right. This is on the problem of working with the existing
hardware to go with the existing server.
>> : Yeah.
>> : [Inaudible].
>> : If you can come up with something that works on PC, Mac and three
brands of phone, now we can discuss whether it is of merit.
>> : Well, I was thinking the authentication protocols that companies
are coming out with for cars which I personally hate. But,
nevertheless, somebody must like them. Which are these things that, you
know, you carry around [inaudible] in your pocket and it just works
kind of thing. And that is easier to use than a password. Easier to
screw it up too but --.
>> : So I think we’ve exhausted ourselves on this. Well we got all the
way through a talk on passwords without anybody mentioning xkcd 936 so
that’s a new [inaudible].
[ Audience clapping ]