►
Description
Traditional two-factor technologies, requiring you to type in a code from your phone, are a hassle and have numerous security shortcomings. A recently published standard from the FIDO Alliance, Universal 2nd Factor (U2F) is the next step in the evolution of account security. Through tightly integrating hardware tokens like the YubiKey, the web browser, and websites like GitHub, U2F provides an easier and more secure way to lock down your web accounts.
Jerrod Chong and Ben Toews, from Yubico and GitHub respectively, discuss how U2F works, how it improves the security and user experience of two-factor authentication, and why and how GitHub chose to adopt this new standard.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
B
C
Here
at
github,
we
want
to
make
u2f
truly
universal
security
is,
without
a
doubt,
the
most
important
thing
we
do
at
github,
but
our
entire
job
is
to
ensure
the
privacy
and
the
confidentiality
of
the
code
that
our
users
have
trust
us
with.
U2F
helps
security
by
bringing
a
very
user-friendly
easy
to
use
device
to
end
users
and
developers
providing
strong
Hardware
back
multi-factor
authentication,
I
use.
C
D
C
D
C
D
B
So
what
is
universal,
psycho
packer
u12?
It's
a
new
open
sanitation
standard
that
defied
alliance
and
the
question
you
can
ask
is:
what
is
it?
Why
is
it
different
today,
my
jobs,
to
give
you
an
overview
and
kind
of
break
it
down
for
you,
and
hopefully
you
dive
deeper
into
the
protocol
and
see
what
get
out
have
done
to
put
it
into
get
up
so
question
you've
probably
asked
is
that
we've
seen
two-factor
authentication
solutions
out
there,
we've
seen
that
happening
for
a
long
time.
B
B
We've
seen
that
also
with
just
highway
devices
that
have
been
around
for
some
time
and
it
also
boils
down
to
cost
and
provisioning,
and
all
these
other
things
that
we
are
aware
of,
but
really
the
main
thing
that
I
feel
it's
lacking
from,
or
we
feel
is
lacking
in
the
ecosystem,
is
something
that
what
we
really
need
to
address,
which
is
usability
and
security
right.
So,
even
if
your
inconvenience
with
caste
or
other
issues,
if
it
doesn't
solve
the
security
problem,
I
think
we
are
not
moving
forward.
B
So
today
we're
going
to
talk
about
what
is
the
benefits
of
u2f
and
then
give
you.
The
breakdown
on
the
protocol
first
got
to
be
simple,
simple,
edit,
all
our
scales,
not
just
user,
but
implementation
about
usage.
It
should
work
out
of
the
box.
These
are
important
criteria,
saan
just
using
a
security
product
or
using
a
security
solution
or
service.
B
The
other
thing
is
about
security,
and
security
is
important.
Sms
and
one-time
pass
codes
are
all
in
some
ways:
symmetric
keys
that
are
still
fishable
and
what
we
need
to
move
away
is
build
protocols
that
take
the
advantage
of
asymmetric
keys.
We
all
know
that
with
PGI,
but
pikia
has
his
challenges,
and
so
this
is
a
very,
very
exciting
model,
and-
and
once
you
understand
the
protocol,
you
probably
have
an
aha
moment
on
why
using
this
type
of
asymmetric
key
protocol
really
makes
sense
scalability.
B
B
It
is
a
one-to-one
relationship,
so
it's
hard
to
scale
when
you
think
of
every
service
want
to
do
their
own
strong
off,
there's
only
so
many
keys,
we'll
carry
as
well,
so
many
apps
that
you
want
to
carry
so.
The
idea
behind
you,
twelve
is
really
one
device
that
can
support
many
services
and
it's
part
of
the
whole
design
of
protocol
and
explain
a
little
bit
as
well,
and
today
we
leave
live
in
a
very
reach,
feel
environment
about
privacy
and
data,
and
so
that's
part
of
the
consideration
of
this
protocol
as
well.
B
B
Here
are
the
flows
high-level
flows,
so
you
can
understand.
Think
of
registration
as
a
process
to
on
board
your
Authenticator
and
here's
where
things
get
interesting.
The
device
itself
is
what
generates
the
key
pair,
which
is
very
different
from
other
models,
which
is
some
central
body,
creates
the
keys
and
puts
those
keys
in
your
device
this
key
or
if
authenticators,
implement
the
protocol.
The
Authenticator
generates
the
key
pair
and
then
gives
public-key
to
the
service
so
think
of
it
as
every
service.
B
The
device
can
generate
a
uniquely
different
key
pair,
so
this
changes
the
model
of
scalability,
but
it
also
changes
the
model
of
registration
right
because,
if
you
think
of
it,
if
I've
got
a
disabilities
and
find
some
way
to
dispute
the
keys,
that's
a
scalability
problem
as
well,
and
when
you
get
the
back
the
registration
information,
there
are
a
few
other
things
that
are
important,
which
is
the
service
can
decide
to
trust
your
Authenticator
or
not.
So
if
you
decide
today,
you
want
to
build
something
in
software
which
can
be
done.
B
You
want
to
build
another
Highway
advice.
Service
can
still
decide
which
device
or
Authenticator
they
trust
and
the
critical
path
for
how
the
authentication
works
is
the
key
handle
so
I'm
a
service
I
store
your
public
keys.
How
do
I
know
that
you're
gonna
be
able
to
sign
your.
You
know
the
challenge
again
for
the
authentication,
and
so
the
important
thing
is
the
key
handle
is
use
to
either
derive
the
private
key
or
to
unwrap
the
private
key,
and
why
is
they
important?
B
Because
you
can
think
of
a
model
where
you
just
don't
want
to
use
one
single
site
in
the
five
sites?
Can
this
scale
to
hundreds
of
sites
right,
so
storage
in
certain
devices
are
going
to
be
limited.
So
if
you
have
a
key
derivation
system
that
will
totally
take
care
of
the
of
the
storage
for
creating
all
the
key
pairs
and
then
being
able
to
regenerate
the
private
key
on
the
fly,
so
a
couple
components
before
I
jump
into
the
protocol
details
three
major
components.
B
B
So
what's
the
missing
piece
missing
piece
is
a
client,
and
today
the
client
that
supports
you,
12
of
the
box,
is
Chrome,
so
actually
been
supporting
you
12
since
last
October,
some
of
you
who
have
you
you
a
security
key
with
Gmail
some,
so
this
has
been
launched
for
some
time
but
we're
taking
a
step
further.
Obviously,
to
improve
the
protocol.
You
see
the
USB
transfer,
which
is
what
we
released
and
the
specs
have
been
released
for
two
other
transports,
which
is
both
bluetooth
as
NFC.
B
So
kind
of
going
into
the
protocol
and
diving
in
and
I
think
this
would
give
you
a
good
idea
why
we
built
the
way
we
built
it
start
with
authentication.
So
it's
both
using
public
key
cryptography
as
well
as
channeis
response
bribe
I'm.
Assuming
most
of
you
know
what
public
key
is
private
public
keys.
Basically,
if
you
create
the
key
pair
on
the
device
and
someone
sent
you
the
challenge
and
you
sign
it
and
if
the
receiving
party
has
the
public
key,
you
can
always
verify
the
signature.
B
B
Nicks
I
talked
about
phishing
and
men
in
the
middle,
so
modern
day.
Pals
need
to
take
care
of
this
right
on
the
box,
can't
depend
on
other
means
of
the
ecosystem,
so
building
this
in
is
critical
for
the
ecosystem,
so
the
client
plays
important
role
here
right.
So
that's
why
we
are
working
with
that
phone
vendors
and
it's
a
it's
a
critical
path,
because
if
the
client
does
some
of
these
checks,
it
really
elevates
the
game
and
makes
it
really
hard
for
attacks.
B
So
introducing
origin
and
China
like
China
ID,
basically
is
to
do
what
they
used
to
call
origin
origin
bound
certs,
which
is
host
client
base,
certs
doing
strong
ton
on
TLS.
But
the
key
thing
is
that
the
client,
in
this
case
the
browser
takes
care
of
that
for
you
right
so
think
of
it
as
a
bad
actor
site.
B
If
somehow
you
could
redirect
the
user
and
we
didn't
hit
origins,
then
you
could
be
possibly
signing
for
the
wrong
site
having
this
in
the
client,
which
is
the
browser,
I
mean
the
browser
knows
if
you
did
a
redirect
and
if
it
gives
that
origin
to
the
device,
the
device
is
going
to
sign
with
the
wrong
origin
and
you
can
absolutely
detect
if
there's
an
attack.
So
this
is
the
critical
path
where
the
client
pays
important
role
to
make
sure
that,
where
the
users
going
is
really
where
the
users
going
versus
something
happening.
B
B
B
As
we
get
into
a
larger
ecosystem,
I'm
sure
none
of
you
will
create
software
apps
and
other
authenticators
in
in
the
space.
Think
that
the
protocol
would
want
to
protect
is
cloning
of
possibly
the
software,
and
so
that's
a
counter
that
the
service
can
check.
If
that's
too
high
of
a
counter
or
too
little.
You
know
you
can
do
some
some
quick
checks
on
that.
B
B
And
I
get
the
last
part,
which
is
I,
think
kind
of
ties.
Everything
together,
which
I've
talked
about
doing
the
initial
registration.
It
obviously
asked
the
device
to
join
the
key
pair
and
the
key
handle
and
the
device
would
send
back
the
public
key
for
the
service,
which
is
unique
for
that
service,
and
it
will
also
send
back
the
key
and
oh
now.
B
The
critical
piece
in
the
registration
process
is
about
trust
as
well.
In
the
current
system,
most
services
are
gonna
trust
authenticators
implementing
u12,
but
you
can
imagine
a
scenario
whereby
either
the
service
or
the
provider
may
only
trust
a
subset
for
whatever
reason,
and
so
the
service
needs
to
be
to
figure
out
whether
they
want
to
trust
the
device
or
not.
B
So
in
the
protocol
today,
there's
an
Esso
station
cert
that
we
send
to
the
service
that's
being
signed
as
a
whole
registration
package
and
the
service
can
decide
whether
they
trust
a
key
from
cubicle,
for
example,
this
bridges,
the
gap
between
public
consumption
versus
maybe
enterprise
consumption
and
really
provides
diversity
in
terms
of
how
people
develop.
You
know
different
types
of
authentic.
B
So
hopefully,
this
gives
you
kind
of
a
good
idea
of
the
protocol
breakdown
and
what
we're
really
trying
to
focus
is
you
know?
Besides
the
attack,
this
is
just
a
scalability
aspects
with
the
use,
EE
aspects
together
with
the
simplicity.
Ultimately,
we
create
an
ecosystem
where
it's
very
difficult
to
use,
even
though
it's
so
so
secure
and
so
scalable,
then
we
really
make
it
very
difficult
to
use
or
enable
strong
authentication
so
kind
of
wrapping
up
here.
B
This
is
the
high-level
view
of
what
you
can
do
today
to
extend
your
service,
your
app
your
solution,
your
game,
to
do
strong
off.
Basically,
today,
I'm
I'm,
pretty
certain
you're
using
some
type
of
hash
database
for
passwords.
So
we
want
to
extend
that
so
that
the
additional
metadata
that
go
user
record,
namely
you
want
to
think
about
whether
you
allow
for
multiple
devices,
multiple
authenticators
I'm,
assuming
yes-
and
you
want
to
do
some
quick
checks
on
whether
they
are
approved
Authenticator
for
your
environment
and
then
basically
just
handling
recovery
flow
and
I.
B
Think
that
will
become
again
the
big
question
for
as
we
advance
suspects,
which
is
how
do
we
tie
in
recovery
if
you're,
if
your
front
door
is
very
strong,
then
how
do
we
get
to
protect
the
side
doors
in
the
back
door?
The
way
we
look
at
it
is
that
if
authenticators
are
everywhere,
whether
it's
a
Yubikey
or
built
into
your
phone
or
your
laptop,
then
recovery
flows
shouldn't
default
to
your
mother's
maiden
name
right.
So
that's
something
to
consider
when
you
build
your
apps
that
you
know
take
care
of
your
recovery
flow.
B
A
A
With
this
blog
post,
our
initial
implementation
of
two-factor
authentication
was
OTP
one-time
password
based,
so
a
user
would
receive
a
code
on
their
phone
or
a
mobile
device,
either
by
opening
an
application
and
typing
in
a
code
that
it
generated
into
github
comm,
or
we
would
send
them
an
SMS
text
message
with
a
code
in
it
that
they
would
then
type
into
github,
calm
and
there's
a
couple
of
usability
flaws
with
our
initial
implementation
that
you
see
with
most
OTP
based
two-factor
authentication
implementations.
The
first
is
that
SMS
is
not
reliable
text.
A
Messages
are
very
hard
to
deliver
reliably.
The
SMS
protocol
doesn't
have
any
reliability
mechanisms
built
into
it.
So
when
we
send
you
a
message
with
your
code
in
it,
there's
a
good
chance
that
you
might
not
get
it
and
while
it
works
fairly
good
for
those
of
us
in
the
United
States
who
are
implementing
this,
there's
a
lot
more
problems
with
deliver
abilities
when
we're
trying
to
send
overseas
to
certain
countries.
The
other
big
usability
problem
that
we
find
with
the
OTP
implementation
is
that
the
user
experience
of
using
the
app
is
terrible.
A
If
you
want
to
log
into
github-
and
you
have
to
go,
find
your
phone,
then
you
have
to
unlock
your
phone.
Then
you
have
to
find
the
app
open
the
app
scroll
through
a
huge
list
of
all
the
websites
that
you've
set
up
to
FA
on
and
type
in
a
code.
It's
a
pretty
terrible
experience,
but
at
the
end
of
the
day,
while
our
initial
implementation
has
some
some
usability
difficulties,
it's
still
two-factor
authentication
and
that's
that's
better
than
nothing
and
it's
a
huge
security
improvement.
A
Fast-Forward
a
year
to
October
of
2014
yubico
launched
the?
U
bikini
oh
and
the
U
bikini
o
n,
with
this
blog
post,
which
ad,
which
included
you
to
have
support,
so
the
security
team
at
github
was
interested
and
impressed.
We
thought
that
this
new
protocol
sounded
pretty
cool.
It
addresses
a
lot
of
the
usability
concerns
with
our
initial
implement,
as
Jared
mentioned,
and
it
also
had
some
pretty
cool
security
improvements.
A
Few
days
later,
a
friend
of
mine
on
the
the
chrome
security
team
tries
to
bribe
me
into
implementing
u2f
on
github,
so
now,
I'm
really
interested
so
on.
October
24th
I
took
a
stab
at
implementing
u2f
and
it
turned
out
to
be
not
super
straightforward.
The
JavaScript
at
the
time
was
kind
of
hard
to
understand
how
to
write
it,
because
you
were
talking
to
a
Chrome
extension.
The
Google
Chrome
implementation
wasn't
native
at
that
point
and
figuring
out
how
to
send
post
messages
to
this
hidden.
A
This
Chrome
extension
was
not
simple,
so
I
closed
it
and
I
gave
up
a
month
later,
I
tried
again
a
little
bit
more
resolved
this
time
to
try
it.
The
good
of
the
security
team
had
been
talking
about
it
and
we
decided
that
this
is
something
that
we
were
really
interested
in
implementing
and
trying
to
make
it
more
pervasive
in
the
ecosystem
trying
to
encourage
other
developers
to
do
it.
So
I
took
another
stab.
As
you
can
see,
it
was
a
bit
of
work.
A
A
To
start
this
process,
we
used
the
u2f
gem,
so
someone
out
there
in
the
open
source
community
username
castle,
made
a
ruby
library
for
doing
the
cryptography
for
you
to
have
and
for
dealing
with
some
of
the
the
challenge
response
negotiations
that
are
in
the
protocol.
So
there
was
already
an
open
source
gem.
It
took
a
bit
of
work
from
us
to
make
it
something
that
we
were
comfortable
using.
So
we
contributed
for
a
bit
back
to
this
project
and
that's
what
we're
using
today.
A
The
next
kernel
that
we
ran
into
like
I
said
the
initial
chrome
implementation
was
the
browser
extension
well.
This
browser
extension
was
checking
the
the
origin
of
the
website.
That
reason-
and
we
do
our
development
on
github,
dev
and
apparently
dot
dev-
is
not
a
valid
TLD,
so
the
Chrome
extension
just
didn't
work
and
it
gave
a
really
horrible
Opie
error
message
so
that
took
a
while
to
debug
and
then
also
it
required
HTTP
and
our
you
know.
A
My
development
instance
on
my
laptop
wasn't
running
HTTP,
so
I
ended
up
having
to
hack
the
the
Chrome
extension
quite
a
bit
and
build
my
own
copy
to
even
begin
developing.
You
know
for
github.
The
next
step
is
to
fix
our
II.
The
next
step
is
to
figure
out
how
to
persist
the
registration
in
the
database,
so
we
added
a
database
table
added
a
Ruby
on
Rails
model.
This
is
we're
restoring
the
key
handled
certificate,
the
public
key,
the
counter,
that's
all
pretty
common
stuff
in
the
in
the
reference
implementations.
A
The
one
thing
that
we
added
to
our
model
was
the
nickname.
We
wanted
users
to
be
able
to
register
multiple
keys
on
the
like
for
one
account,
so
you
can
provide
a
nickname
to
your
key
and
that
way.
When
you're
looking
at
route
to
factory
settings,
you
can
manage
those
more
easily,
so
that
was
pretty
simple,
but
now
I
needed
a
flow
for
actually
registering
a
device
and
I'm,
not
a
UI
guy
at
all,
so
I
build
something
that
was
horrible
and
ugly,
but
the
back
end
is
stayed
pretty
much
the
same.
A
We
have
a
u2f
registrations
controller,
and
this
just
gives
end
points
where
it
generates
a
challenge
which
is
then
as
Jared
described,
signed
by
the
device,
and
then
we
have
our
registration,
and
the
focus
here
for
us
was
on
the
flow.
The
security
keys
make
for
a
really
good
flow
kind
of
naturally,
but
I,
don't
I
managed
to
mess
it
up
and
it
looked
terrible.
So
that's
something
that
we
we
worked
on
more
as
we,
we
moved
along
I'm
gonna
give
a
quick
demo
of
what
it
looks
like
to
read.
A
All
righty,
so
here
I,
am
logged
into
my
beat
aids
account.
This
is
my
test
account
so
to
register
key,
go
to
settings
security,
two-factor
authentication.
So
this
is
just
your
normal
to
FAA
settings
and
you
can
see
that
I
already
have
registered
the
key
that
I
keep
on
my
keychain,
but
today
I
got
this
cool
github
branded
Ubik
you
that
we're
giving
out
at
the
octave
doctor
shop
back
there,
which
you
should
go
pick
up.
A
If
you
don't
have
one
so
I
said,
I
want
to
register
a
new
device
plug
in
my
key
I'm
gonna
call
this
my
yubikey
edge.
This
is
an
edge
yeah.
I
took
a
key
so
now
there's
a
little
light.
Blinking
here,
just
press
a
button
and
boom
I
have
my
new
registered
device,
and
this
is
what
I
mean
when
I
say
that
we
wanted
to
smooth
the
easy
flow.
It's
it's
pretty
intuitive
and
easy
to
to
work
with
I.
Think.
A
So
what
we're
doing
here
is
we're
actually
looking
at
your
user
agent
and
making
sure
that
your
browser
supports
u2f
and
that
you
have
you
to
have
key
on
your
account
and
if
so,
we
show
you
a
special
u2f,
login
page,
which
is
hopefully
easy
to
use
and
go
back
to
a
live
demo,
because
I'm
the
internet
seems
to
be
working,
which
is
awesome
all
right
so
now,
and
the
log
out
of
my
account
we're
going
to
hope
that
I
can
remember.
My
test
accounts
password.
A
A
A
All
right,
so
the
next
step
in
our
implementation
was
to
test
this.
This
was
new
techno
the
year
now,
but
we
wanted
to
make
sure
that
it
would
work
well
and
not
do
what
my
demo
just
did
so.
I
ended
up.
Writing
a
whole
you
to
have
client
implementation
in
Ruby
for
our
automated
tests,
and
we
also
wanted
to
make
sure
that
this
worked
with
a
bunch
of
different
hardware
manufacturers.
A
A
A
So
the
next
step
do
I
polish
I
brought
in
my
my
friend,
David
Graham,
who
works
at
github
she's,
an
incredible
user
interface
designer
he's
a
really
great
guy,
and
he
put
some
polish
on
it
and
made
it
what
made
it
what
it
is
today,
I
really
focused
on
usability
and
flow
tried
to
make
it
an
experience.
That's
good
for
the
users
next
step
is
today:
github
ships,
u2f
so
I
closed
this
this
tracking
issue
that
I've
had
open
since
June.
A
Earlier
this
morning
we
should
clock,
and
that
was
after
I
guess
it's
cut
off
in
the
screenshot
82
comments
on
this.
We
did
a
lot
of
discussion
internally
about
how
to
ship
this
right
at
the
right
time
in
the
right
place
and
are
pretty
happy
with
the
turnout.
So
that's
it
for
our
story.
The
next
step
in
the
story
is
that
we
encourage
you
to
implement
this.
A
We
really
believe
that
this
is
an
improvement
for
security
and
if
this
can
become
more
commonplace
in
the
ecosystem,
we
really
think
that
the
security
of
the
Internet
as
a
whole
can
be
improved,
and
if
you
go
to
a
good
about
comm,
slash,
showcases,
slash
Universal
second
factor,
we
have
a
list
of
all
the
projects
on
github
that
will
help
you
implement
this.
So
right
now
on
the
showcase
there's
Ruby
Golan,
Python,
Java
libraries
there's
also
django
plugins
wordplay
wordpress
plugins,
there's
libraries
for
c-sharp
4c.
B
A
Probably
some
other
stuff,
but
yeah.
We
encourage
you
to
go
implement
this,
for
yourself,
go,
try
it
on
github.
If
you
don't
have
one
of
the
keys,
there
should
have
been
a
little
wooden
token
in
the
bag
that
you
got
this
morning
and
you
can
go
to
the
octo
shop
and
exchange
that
wooden
token.
For
a
plastic
token,
yeah.
B
I
know
so
for
those
watching
life
of
a
stream.
You
know
we
had
a
pretty
huge
search
for
the
special
keys
that
people
could
buy.
We
hear
you
guys
and
actually
we're
gonna
double
the
offer
for
those
watching
over
the
stream
and
want
to
get
the
special
edition
key.
So
so
stay
tuned
and
well,
you
know
we'll
make
sure
we
can
get
as
many
of
these
special
keys
two
to
one
that
really
wants
it.
Thank
you.
Cool.
A
Yes,
the
question:
is
you
don't
want
to
get
true,
Yubikey
launched
and
that
that's
quite
true,
it's
a
huge
problem
that
we've
had
with
traditional
two-factor
authentication
is
someone
White's
phone,
they
lose
their
phone,
they
get
a
new
phone
or
they
can't
get
SMS.
They
change
their
phone
number
and
you
have
the
same
potential
problems
with
the
Yubikey.
If
you
lose
it,
that's
a
problem,
but
unlike
a
phone,
you
can
just
plug
in
another
Yubikey
and
configure
that
and
you
can
work
with
our
support
team
to
recover
your
account.
A
B
I
think
the
question
is
to
have
your
backups
and
you
could
have
more
than
one
key
where
it
could
be
even
your
own,
app
that
you
created
that
understands
you
12,
so
the
ecosystem
doesn't
mean
that
you
have
one
key
for
your.
You
know
one
account
you
can
register
I.
Think
I
don't
mean
this,
but
you
can
register
so
a
lot
of
keys.
B
B
Yeah,
so
the
soleus
PlayStation
4
for
us
is
we
sign
it
with
South
sensor.
You
can
implement
your
own
chaining
of
your
trust.
It's
really
up
to
each
manufacturer
to
decide
what
they
want
to
put
on
there
by
essentially
is
for
you
to
verify
that
this
key
was
actually
made
by
the
manufacturer.
So
if
we're
buying
a
Yubikey,
you
know
you
we
put
out,
you
know
a
root
server
out
there
and
you
can.
You
can
verify
you
can
say
this
yeah.
B
B
Yeah,
so
we
work
as
a
bigger
community
in
the
phyto
alliance
right
now,
so
the
5-door
Alliance
has
a
entire
the
lobby
companies
there.
You
can
do
a
quick
search
on
Federline,
so
the
specs
are
part
of
the
Fido
lines
and
yes,
it's
gone
to
the
party
reviews.
There
are
many
of
these
organizations
a
part
of
security
I
in
the
Alliance.
So
yes,
it's
definitely
been
reviewed.
A
lot
of
the
considerations
for
various
attacks
on
the
protocol
is
also
online.
B
B
So
the
question
was
that
Jared
innkeepers
is,
is
a
cryptographic
intense
operation,
and
how
does
how
do
we
do
it,
uniquely
so
as
secure?
So
we
use
we
use
chips
from
very
trusted
manufacturers
who
we
use
the
XP
chip
same
one,
that
you
find
your
iPhone,
so
you
trust
your
iPhone
or
not
to
do
Apple
pay,
obviously
that's
up
to
the
vendor.
So
the
entropy
comes
from
the
chip
that
we
use
the
secure
element
that
we
use
on
it
on
Hauer.
So
you
could
use
simple
microcontroller
to
do
that.
It's
you
know.
B
So
the
question
was:
can
the
Yubikey
replace
traditional
authentication
like,
for
example,
within
our
co2
betoken,
so
I
think
the
question
is:
do
you
want
to
use
the
RSA
token
I?
Think
we've
evolved
past
OTP
and
owl?
You
know
so
today
we
present
you
the
keys
that
you
after
you
Ubik.
You
can
also
do
OTPs
on
the
same
device.
So
I
think
the
question
is
that
all
TPS
are
are
not
good
enough.
I
mean
it's,
it's
it's
better
than
just
using
a
password,
but
it's
not
good
enough
I.
B
Maybe
we
need
to
think
two
three
years
down
the
road
and
if
we
want
to
build
systems
that
is
secure
and
scale,
that's
that's
not
the
solution.
That's
not
to
go
back
to
symmetric
keys
and
having
more
hashes
of
symmetric
keys.
That's
I
mean
you
can
do
to
a
certain
extent,
but
ultimately
we
talk
about
scale
and
usability.
That's
not
the
right
model.
A
B
Yeah,
so
the
question
is:
what
kind
of
storage
is
on
the
key?
Think
of
it
as
there
there
is
a
there
is
a
device
key
uniquely
generated
when
you
first
use
it,
but
what
you
send
to
the
service
is
a
derived
key,
so
you're
not
storing
like
all
these
key
pairs
for
all
the
services,
because
that
will
take
up
a
lot
of
storage.
As
you
say,
and
then
it
has
other
issues
in
terms
of
scalability,
so
most
implementers
most
authenticators
today,
we've
seen
is
mostly
derived
keys.
B
You
could
choose
to
wrap
keys,
so
you
could
choose
to
wrap
your
private
key
with
some
other
key.
That's
on
the
device
only
and
send
the
whole
key
up,
that's
and
send
a
hash
out,
for
example,
that's
up
to
you,
but
we
choose
to
do
the
right
key.
So,
theoretically,
there's
no
limit
to
the
number
of
services
that
one
key
can
pair.
B
B
B
Yeah,
so
so
the
this
is
a
question
about
the
design
of
the
wiki.
It's
pretty
similar
to
a
number
of
other
manufacturers.
Is
it's
a
touch
and
it's
it's
not
biometric.
It's
it's
a
for
us
is
that
it's
a
capacitance
sensor,
which
is
when
you,
when
you
touch
the
goal,
ring
a
circle
or
the
goal
contact
it
is
actually
go
and
it
will.
It
would
generate
the
crypto
operation.
B
B
B
Gets
there
yeah?
That's
why
the
client
is
the
most
important
piece.
So
we
talked
about
the
client
piece
that
is
the
that
is
part
of
this
equation,
which
is
the
client
not
just
checks
that
you're
coming
to
the
right
side,
the
origin
right,
because
if
you're
going
to
github
it
better
make
sure
that
it's
going
to
github
and
not
some
redirect
or
another.
You
know
bad
active
site,
calm,
and
so,
if
it's
always
gonna
check
for
origin,
the
client
will
obviously
send
both
the
challenge
and
the
origin
to
the
device.
B
B
A
B
Little
little
boost
over
there
but
you're
right.
So
the
challenge
and
the
response
needs
to
be
handled
very
securely
with
the
middle
layer,
which
is
the
client
or
whatever
the
platform
is,
and
so
I
mean
we're
working
with
Google,
obviously
Caribbean
team.
So
the
next
platform
that
Google
will
introduce
this
is
the
Android,
so
stay
tuned
I
mean
it's
we're
gonna
they're
working
on
the
wireless
with
NFC,
so
it's
gonna
be
really
cool
where
you
can
do
authentication
over
NFC
on
on
Android
devices,
so
stay
tuned
for
that
yep.
A
A
So
I'm
good
hub
Enterprise,
the
database
is
going
to
be
the
same
database.
That's
storing
all
the
other
enterprise
data
data,
so
you
can
yes.
So
that's
another
thing:
I
forgot
to
mention
in
enterprise
version
2.4,
which
is
shipping
I,
believe
in
the
next
couple
of
weeks.
There
will
be
support
for
you
to
F
and
you'll,
be
able
to
yeah
use
that
just
the
same
as
you
would
on
github.com
yeah.
B
So
I
think
the
question
was
about:
how
do
we
converge
to
touch
ID,
I?
Think
the
ecosystem,
if
you
need
to
separate
the
actual
authentication
stack
from
the
identification
of
the
user,
so
in
in
the
u2f
case,
you
can
layer
things
on
top
I
mean
we
could
add
a
biometric
sensor
that
is
local
on
the
device
to
verify
what
the
user
is
right
and
then,
but
the
stack
is
what
we're
talking
about.
B
So
the
u2f
stack,
we're
talking
about
is
a
open
standard,
so
it
really
shouldn't
I
mean
identification
is
one
aspect,
but
really
when
we
talk
about
what
the
protocol
is
to
do
the
authentication,
that's
the
critical
piece,
so
we
want
to
standardize
this
right,
because
otherwise,
if
everybody
do
have
the
own
way
of
making
their
own
authentication
cause,
then
you
get
a
you
know
you
get
what
we
have
today,
which
is
all
these
variant
solutions.
So
just
like
how
we
start
from
here,
TDPS
now
we're
to
TLS.
We
we
want
to
make
the
transition.