Slide 1
Slide 1 text
one, two step.
Henri Watson
Slide 2
Slide 2 text
$ whoami
• Second year student at Abertay
(HackSoc Secretary + Securi-Tay 2017 Organiser)
• Intern at SkyScanner (Summer 2017)
• I dig
• Security UX
• Embedded devices
• Payments technologies
• Public transportation
Slide 3
Slide 3 text
Most web apps implement some form
of authentication system
Slide 4
Slide 4 text
Login forms come in all sorts of
shapes and sizes
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
Not all login forms are equally secure
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
HTTPS only secures
the transport layer
Slide 14
Slide 14 text
HTTPS does not protect data at rest
Slide 15
Slide 15 text
https://haveibeenpwned.com/
Slide 16
Slide 16 text
http://www.wired.co.uk/article/mark-zuckerberg-hacked-password-released
Slide 17
Slide 17 text
Static information can be
stolen and reused
Slide 18
Slide 18 text
Static information is
terrible for authentication
Slide 19
Slide 19 text
Two-Factor Authentication
attempts to solve this problem
Slide 20
Slide 20 text
Something you know
+
Something you have
Slide 21
Slide 21 text
Keep the password,
but add a physical layer
Slide 22
Slide 22 text
some people missed that
“static information” slide
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
A different code is requested each
time, so replay attacks don’t work
Slide 26
Slide 26 text
A different code is requested each
time, so replay attacks don’t work
(unless we can capture 20~30 login attempts)
Slide 27
Slide 27 text
One code does not reveal the
remaining codes on the card
Slide 28
Slide 28 text
MITM is hard,
phishing is so much easier
Slide 29
Slide 29 text
“We need to reactivate your card!”
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
Static data in a physical format is
still static data
Slide 32
Slide 32 text
How can we quickly provide a user
with a one time use code?
Slide 33
Slide 33 text
Users have phones,
text them one-time use codes!
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/
Slide 36
Slide 36 text
SS7 attacks also allow your phone
number to be hijacked without
your carrier’s cooperation
Slide 37
Slide 37 text
SMS verification also causes problems
when roaming/outwith service areas
Slide 38
Slide 38 text
Could we provide an
initialisation vector at sign up?
Slide 39
Slide 39 text
Give the user
a code generator!
Slide 40
Slide 40 text
http://www.tokenguard.com/images/tokens/SID700.gif
http://www.intech.ro/site/images/otptoken/otp-token-c100.jpg
Slide 41
Slide 41 text
Both the website and the device
have a shared secret key
Slide 42
Slide 42 text
The code is calculated by computing
the HMAC of the current time using
the shared secret key
Slide 43
Slide 43 text
As long as the key is not intercepted
during the initial setup, the key
can’t be externally determined
Slide 44
Slide 44 text
Fobs can be
expensive and inconvenient
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
Many of these are based on the
Time-based One-Time Password
algorithm
Slide 48
Slide 48 text
Agree on five parameters:
a secret key
the current time
an interval
a hash function
a token length
Slide 49
Slide 49 text
Our key is 012345ABCDEF, it is
04/06/2017 @ 11:39:58am (UTC),
we’ll use a 30sec interval,
sha1, and 6 digit tokens
Slide 50
Slide 50 text
04/06/2017 @ 11:39:58am (UTC)
is 1491478798 seconds since
the UNIX epoch
Slide 51
Slide 51 text
1,491,478,798 divided by our interval
(30) results in 49,715,959
Slide 52
Slide 52 text
Compute
HMAC-SHA1
(49715959, 012345ABCDEF)
=
e91433413775c646b2255cfa8bde51247796973e
Slide 53
Slide 53 text
Take the four least significant bits
and use this as an offset in the
original hash
(e -> 1110 -> 14)
(e91433413775c646b2255cfa8bde51247796973e)
Slide 54
Slide 54 text
Take four bytes starting from the
offset and discard the most
significant bit.
(11000110 01000110 10110010 00100101)
Slide 55
Slide 55 text
The token is then the lowest 6 digits
(pad from the left if needed)
(2358076490)
Slide 56
Slide 56 text
If the code generated on both sides
matches, all is good!
Slide 57
Slide 57 text
but what if the code generator
is visible?
Slide 58
Slide 58 text
http://thedailywtf.com/images/remy/robotguys.png
Slide 59
Slide 59 text
This can be avoided by
requiring user interaction.
Slide 60
Slide 60 text
HOTP uses a counter instead of a
timestamp but can have sync issues
Slide 61
Slide 61 text
Some apps ask the user to
approve logins on their phone.
Slide 62
Slide 62 text
https://9to5google.files.wordpress.com/2016/06/google-prompt-two-factor.png?w=1024&h=0
Slide 63
Slide 63 text
Early Yubikeys used an internal
counter to generate codes in a
similar fashion.
https://static1.squarespace.com/static/54764dcde4b0ad59b84ad859/t/
54eccc9ce4b0328389b9b398/1424805028325/YubiKey-Standard-1030x687.png?
format=1500w
Slide 64
Slide 64 text
These are all
still vulnerable to phishing
Slide 65
Slide 65 text
As the code generator works
independently, it cannot verify
the website’s identity
Slide 66
Slide 66 text
Challenge-Response protocols
fix this issue
Slide 67
Slide 67 text
The Chip Authentication Program
is used by several UK banks to verify
transfers to new recipients
https://www.barclays.co.uk/cs/Satellite?
blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1367516798251&ssbin
ary=true
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
The Chip Authentication Program
piggybacks the Chip and PIN process
to generate an eight digit code
Slide 70
Slide 70 text
(Barclays UK Debit Card issued in 2015. Inspected using Cardpeek.)
EMV-wide payment
card application selector
Visa Debit application,
used for most transactions.
Link application,
used by UK-only ATMs.
CAP application,
used by online banking login.
Slide 71
Slide 71 text
After verifying the user’s PIN, the
authenticator asks the card to sign a
fake purchase
Slide 72
Slide 72 text
The cryptogram from this fake
transaction is encoded as a token
which can be verified by your bank
Slide 73
Slide 73 text
Phishing attacks are useless as the
user has to independently confirm
the amount and account number
Slide 74
Slide 74 text
What if we’d like to verify
the domain name?
Slide 75
Slide 75 text
Some organisations (notably US DoD)
have deployed PKCS#11 smartcards
https://images-na.ssl-images-amazon.com/images/I/61rdJCNG5nL._SX355_.jpg
Slide 76
Slide 76 text
PKCS#11 smartcards have a limited
number of identities and are
generally unsuitable for use outwith
their issuing organisation
Slide 77
Slide 77 text
U2F tries to be a modern version
of PKCS#11 client authentication
certificates
Slide 78
Slide 78 text
No content
Slide 79
Slide 79 text
https://twitter.com/meixger/status/654587740365955072
Slide 80
Slide 80 text
No content
Slide 81
Slide 81 text
The web browser acts as as
middleman between the token
and the web service
Slide 82
Slide 82 text
A unique private key is generated on
the device for each account on each
web service
Slide 83
Slide 83 text
As this key is based on the domain
name, phishing attacks are
impossible
Slide 84
Slide 84 text
https://developers.yubico.com/U2F/Protocol_details/Overview.html
Slide 85
Slide 85 text
The key generation process is fully
handled by the token in hardware
and can’t be extracted
Slide 86
Slide 86 text
First the user registers
their key with a service
Slide 87
Slide 87 text
U2F Token Browser Server
u2f.register();
Generate
challenge
Wait for press
Generate reply
Store token
identity
Validate
challenge
AJAX/form
submit
Slide 88
Slide 88 text
The service now has a public key
specific to this user on this service
Slide 89
Slide 89 text
When authenticating the user,
we ask for another signature but
pass the stored identity
Slide 90
Slide 90 text
U2F Token Browser Server
u2f.sign();
Generate
challenge
Wait for press
Generate reply
Look up
token identity
Validate
challenge
AJAX/form
submit
Slide 91
Slide 91 text
If an adversary is able to present a
valid certificate for a domain, they
could proxy your U2F signature
Slide 92
Slide 92 text
Browser MITM Server
u2f.sign();
Generate
challenge
Look up
token identity
Validate
challenge
AJAX/form
submit
Proxy
Slide 93
Slide 93 text
TLS channel ID is a proposed spec to
add self-signed client certs to the
TLS handshake
Slide 94
Slide 94 text
U2F identities can additionally be
pinned to a TLS channel ID
Slide 95
Slide 95 text
Browser MITM Server
u2f.sign();
Generate
challenge
Look up
token identity
Validate
challenge
AJAX/form
submit
Proxy
Create keypair Create keypair
X
keypair
public key
Slide 96
Slide 96 text
Although hardware U2F tokens are
difficult to use on smartphones,
software tokens could be used
Slide 97
Slide 97 text
U2F has little support outside of
Google Chrome
(Firefox bug #1065729)