08-Techs - Authn - Moodle

IT Security
Techniques
I&C School – Prof. P. Janson
September 2014
B. Techniques
B.3. Authentication
© 2014 P. Janson
1 of 35
IT Security
The whole matrix concept rests on
the ability to identify and authenticate subjects
 Subjects can be systems, virtual machines, processes, applications, etc.
 But in the end all the above are driven by people
 So identifying and authenticating people is the issue
© 2014 P. Janson
2 of 35
IT Security
This section first discusses means to authenticate users
How to identify (refer to) users will be discussed later
© 2014 P. Janson
3 of 35
IT Security
There are basically 3 complementary ways of authenticating a user
 By something she knows, e.g. some secret
 By something she is, e.g. some biometric evidence
 By something she has, e.g. some trusted identification document
 Comparison
NB: There is some intended duplication with Ph. Oechslin’s EPFL course to set the stage for later chapters
© 2014 P. Janson
4 of 35
IT Security
Something a user knows: userid and password or PIN
 Passwords must be stored at verifying computer
 Passwords must be transmitted to verifying computer
=> exposure
 Passwords must be typed into end system
• Passwords must never be shared with anyone to prevent identity theft
• Passwords must never be written down => easy to remember => easy to guess
• Passwords must be hard to guess => hard to remember => often written down
• Protecting userids as well as passwords always helps (see later: identity management)
© 2014 P. Janson
5 of 35
IT Security
Passwords must be stored at verifying computer => exposure risk
 User / password file access must be restricted to system administration and login processes
 Stored passwords must be one-way encrypted / hashed with salt
 Compare and match passwords hashed versions, never cleartext ones
 In spite of this rule many reputable companies still store them in cleartext
• Sony 2011 debacle
• IEEE 2012 accident – passwords stored in cleartext in publicly accessible log files
© 2014 P. Janson
6 of 35
IT Security
Passwords must be transmitted to verifying computer => exposure
 Passwords must never be sent in the clear
 Best is to one-way encrypt / hash them before sending
 NB: this does not prevent a hashed password from being intercepted and replayed
(more on this later)
© 2014 P. Janson
7 of 35
IT Security
Passwords must be typed into end system => exposure
 Hide keyboard while typing
 Ensure that no camera is watching the keypad
 Obfuscate password field in login panels
 Beware of key-logging malware – major password risk with today’s end systems
© 2014 P. Janson
8 of 35
IT Security
Passwords must be easy to remember yet hard to guess
© 2014 P. Janson
9 of 35
IT Security
Passwords must be easy to remember yet hard to guess
Look at the 500 most frequent – thus stupid – passwords in 2008
123456
jennifer
jessica
corvette
porsche
player
james
angels
firebird
flyers
fred
scott
prince
suckit
ladies
asdfgh
rosebud
danielle
calvin
girl
password
hunter
panties
bigdog
guitar
sunshine
mike
fishing
butter
fish
johnson
2222
beach
gregory
naughty
vagina
jaguar
beaver
shaved
apollo
12345678
fuck
pepper
cheese
chelsea
morgan
brandon
david
united
porn
3434x
asdf
amateur
buddy
giants
toyota
great
4341
surfer
parker
1234
2000
1111
matthew
black
starwars
fender
maddog
turtle
matrix
tits
video
7777777
whatever
booty
travis
cool
4128
samson
qwert
pussy
test
austin
121212
diamond
boomer
anthony
hooters
steelers
teens
member
london
muffin
young
blonde
hotdog
cooper
runner
kelly
time
12345
batman
william
patrick
nascar
cowboys
blowme
wilson
tiffany
scooby
boobs
7777
redsox
nicholas
fucked
paris
1313
swimming
paul
sydney
dragon
trustno1
daniel
martin
jackson
edward
ferrari
butthead
zxcvbn
jason
donald
marlboro
star
lucky
golden
rock
scorpio
dolphin
mine
women
290’731 occurences out of
32M leaked passwords !
qwerty
thomas
golfer
freedom
cameron
charles
cookie
dennis
tomcat
walter
bigdaddy
srinivas
testing
helpme
0
3434
mountain
gordon
king
voodoo
696969
tigger
summer
ginger
654341
girls
chicken
fucking
golf
cumshot
bronco
internet
shannon
jackie
fire
extreme
madison
casper
racing
magnum
mustang
robert
heather
blowjob
computer
booboo
maverick
captain
bond007
boston
penis
action
murphy
monica
sandra
redskins
987654
stupid
5555
juice
letmein
access
hammer
nicole
amanda
coffee
chicago
bigdick
bear
braves
voyager
carter
frank
midnight
pookie
erotic
brazil
shit
eagle
abgrtyu
baseball
love
yankees
sparky
wizard
343434
joseph
chester
tiger
yankee
rangers
jasper
hannah
college
packers
dirty
lauren
saturn
hentai
777777
master
buster
joshua
yellow
34343434
bulldog
diablo
smokey
doctor
lover
birdie
monster
dave
baby
einstein
ford
japan
gemini
newyork
dreams
michael
1234567
maggie
camaro
money
ncc1701
sexsex
xavier
gateway
barney
trouble
teresa
eagle1
cunt
dolphins
freddy
naked
apples
little
maxwell
football
soccer
biteme
secret
phoenix
rabbit
hardcore
steven
gators
victor
white
jeremy
11111
brian
0
arsenal
squirt
august
redwings
music
shadow
hockey
enter
dick
mickey
peanut
666666
viking
angel
tucker
topgun
11111111
mother
mark
chevy
access14
stars
3434
smith
rush2112
ncc1701
thx1138
qazwsx
ou812
8675309
= The Starship Enterprise registration number
= The name of George Lucas’s first movie
= Follows a simple pattern on a typical keyboard
= The title of a 1988 Van Halen record
= A phone number in a 1982 Tommy Tutone song
monkey
killer
ashley
falcon
bailey
john
willie
snoopy
junior
princess
bigtits
bill
nathan
startrek
winston
wolf
apple
canada
sticky
russia
abc123
george
thunder
taylor
knight
johnny
welcome
blue
thx1138
mercedes
bitches
crystal
raiders
sierra
warrior
nipple
alexis
blazer
cocacola
scorpion
pass
sexy
cowboy
111111
iceman
gandalf
chris
eagles
porno
5150
green
peter
steve
leather
sammy
iloveyou
aaaa
cumming
animal
rebecca
fuckme
andrew
silver
131313
tigers
spanky
panther
winner
badboy
doggie
super
pussies
forever
234343
slut
alex
bonnie
hunting
broncos
tester
6969
charlie
richard
123123
purple
winter
yamaha
samantha
debbie
zzzzzz
qazwsx
cock
angela
4444
8675309
florida
peaches
kitty
private
mistress
jordan
superman
fucker
bitch
andrea
brandy
justin
house
spider
gunner
magic
beer
viper
beavis
zxcvbnm
eric
jasmine
rainbow
skippy
phantom
harley
asshole
orange
hello
horny
compaq
banana
miller
melissa
horney
lakers
rocket
ou812
bigcock
nipples
legend
kevin
112234
marvin
billy
ranger
fuckyou
merlin
scooter
dakota
carlos
driver
flower
booger
bubba
rachel
theman
jake
happy
power
movie
matt
arthur
blondes
6666
iwantu
dallas
michelle
please
aaaaaa
tennis
marine
jack
1212
2112
slayer
oliver
lovers
sophie
victoria
success
qwertyui
cream
enjoy
albert
© 2014 P. Janson
Source: http://www.whatsmypass.com/?p=415
10 of 35
IT Security
Passwords must be easy to remember yet hard to guess
 Nearly 50% of users use existing names, words, slang, or trivial passwords
(consecutive digits, adjacent keyboard keys, and so on)
• Approximately 1 in 9 people use at least one password on the foregoing list
• And 1 in 50 people use one of the top 20 passwords on the list
• People are so predictably stupid that most hackers use just such passwords lists
for hashing and comparison to stolen stored password lists
to quickly identify vulnerable accounts in so-called dictionary attacks
• Even SHA-1 “salts” can be computed at the rate of billions / sec
(http://www.youtube.com/watch?v=lrGMxH8WNZ8)
• Serious companies and government agencies should know better – but they do not
81’883 of the 860’160 password hashes exposed in the Christmas 2011 data breach
at Strategic Forecasting Inc. were cracked in only 4 hours, 53 minutes, and 6 seconds!
(http://www.thetechherald.com/articles/Report-Analysis-of-the-Stratfor-Password-List)
• The same holds for PIN codes
http://www.datagenetics.com/blog/september32012/
© 2014 P. Janson
11 of 35
IT Security
How to pick secure passwords
 Passwords must have enough entropy to be hard to guess
Guessing Probability = PWlife x Guessing Rate / AlphabetSizePWsize
Change passwords regularly – every year or even every quarter
Limit guessing rate – to prevent automated machine-driven attacks
Terminate connection after limited number of failed trials
Use large enough alphabets – upper and lower case + numbers (62)
Special characters would be great but are not accepted by all systems
Use long enough passwords
PWsize > log (PWlife x GuessRate / GuessProbability) / log AlphabetSize
8
> log (100 D x 100 per D /
10-9
) / log 62
• Avoid real words in any language or slang even with classical fantasies
• e.g. 0 for O, 1 for I, 2 for Z, 3 for E, 4 for A, 5 for S, 6 for G, 7 for T, 8 for B, 9 for q
• Backwards spelling, dropping vowels, letters for phonemes, mixed cases, etc.
If you feel it is nice and simple a dictionary attack already has it built in !!!!
• Check (crack) passwords with tools like http://ophcrack.sourceforge.net/ (EPFL)
© 2014 P. Janson
12 of 35
IT Security
Alternatives / complements to passwords
• Pass phrases – larger entropy at cost of more typing
• Pass questions – hard to answer / made up personal questions
• Pass patterns – pre-agreed but randomized click sequence (see Androïd)
• Pass graphs – recognize pre-agreed but randomized picture / drawing
• Pass algorithms – build password through simple algorithm with good entropy secret
© 2014 P. Janson
fixed sentence
system
year
(in unusual language)
descriptor
descriptor
s
o
a
s
E
0
t
t
u
a
n
a
T
2
w
h
s
t
k
i
H
1
e
r
h
s
u
x
L
6
n
t
i
u
d
y
S
9
t
i
t
k
a
z
N
3
y
n
13 of 35
IT Security
Banish password sloth
 Password reuse as a measure for remembering it without writing it down
© 2014 P. Janson
14 of 35
IT Security
Userids (… much more on this in later identity management chapter)
 It is easier to break into a system by trying most frequent passwords on all user accounts
than by trying a dictionary attack on an individual user account
THUS
• Userids should be hard to guess
No natural names, e-mail address, etc.
• Userids should be easy to remember (though they may be written down)
Preferably not assigned by system / administration
• Userids should be selected by the users
Risk of collisions
}
} => pick something “special” enough
Risk of simplicity
}
use some of the tricks for passwords
© 2014 P. Janson
15 of 35
IT Security
Beware of password reset
 Users WILL forget their passwords
• System administrators should not be able to retrieve a forgotten password
• Otherwise they could also impersonate any user at any time
• One more reason for hashing stored passwords
• => Forgotten passwords should only be reset
• Resetting a password is harmless by itself
• Communicating a reset password to the user presents two challenges
1.. Use a trusted channel to the right user
◦ User cannot logon since the password was precisely reset
◦ E-mail not very secure
◦ Identity verification and password reset page present question design challenge
(http://goodsecurityquestions.com/)
◦ SMS or in-person visit to help desk
2.. As soon as reset a password should be immediately changed again for security
◦ Reset password should expire within short period of time to prevent any abuse
© 2014 P. Janson
16 of 35
IT Security
True example – Wired & Longshot’s Matt Honan’s life takedown
Simplified time line
 Fri 17:00
• iPhone power down => cold reboot
• iCloud login failed => connect to MacBook
• MacBook requested Gmail PIN … but had no PIN
• Call to Apple support … on another phone
* MacBook & iPad wiped out*
* Red alert *
• 16:33 – Apple had accepted a password reset call with only 4 credit card digits verification
(which Honan learned only much later from hacker)
=> Honan locked out
A
• 16:52 – Gmail password recovery mail to Apple e-mail account
(recovery userid was blotted out but same as Google)
=> Honan locked out
(shows why userids should be treated like passwords)
• 17:02 – Twitter password reset
=> Honan locked out
G
T
• 17:12 – Offensive hacker posts on Honan’s Twitter account
http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/all/
© 2014 P. Janson
17 of 35
IT Security
True example – Wired & Longshot’s Matt Honan’s life takedown
Analysis
 < 1-hour operation <= Daisy-chained accounts
• Amazon account takeover
• Call Amazon to add a (false) credit card number to the account
◦ Requires only name, e-mail address, and billing address
• Call again to reset e-mail address
◦ Requires only name, billing address, and (false) credit card number just given
• Visit amazon.com and reset password => sent to e-mail just given
• Logon to amazon.com and check real credit card numbers on file (last 4 digits)
 The very four credit card digits that Amazon considers unimportant enough to display are
precisely the same ones that Apple considers secure enough to verify an identity
 NB: these four credit card digits can be obtained from many other sources!
• Apple account takeover – Same userid as Google & required only last 4 credit card digits
• iCloud account takeover – Used “Find My” to wipe Apple devices and lock out owner
A
G
• Gmail account takeover – No 2FA & reset betrays enough of recovery account (Apple)
• Twitter account takeover – Password recovery account was (rightly guessed to be) Gmail
• iPhone, iPad, MacBook erasure – Lock-out (+ no back-up => very expensive recovery)
© 2014 P. Janson
T
18 of 35
IT Security
True example – CloudFlare’s CEO Matt Prince account take-over
 Wall Street Journal 2011 Most Innovative Internet Company
providing secure web services to government and industry (incl. US, Wikileaks, LulzSec,...)
• Insecure linked accounts issue
• CloudFlare client accounts use gmail 2FA (password + PIN via mobile phone)
but account recovery by-passes gmail 2FA
• CloudFlare client account reset linked to CloudFlare CEO account
by cc incl. password => unnecessary exposure
• CloudFlare CEO account reset linked to his private gmail account
• Private gmail account reset voice-linked to mobile phone account
X
• Policy conformance issue
Hackers convinced AT&T to forward CEO mobile combox to their own
based on last 4 digits of CEO SSN instead of pre-defined security question
• Hackers then
1. Reset gmail password => recovered PIN from rerouted combox
2. Logon to gmail account => re-linked it to hacker’s own mail account
3. Reset CloudFlare CEO account => recovered reset password from CEO gmail account
4. Reset CloudFlare client account => recovered reset password from CEO business mail
5. Defaced CloudFlare client web site (temporarily, then got caught by FBI via IP address)
© 2014 P. Janson
19 of 35
IT Security
Pass puzzles and CAPTCHAs
Completely Automated Public Turing Test to Tell Computers and Humans Apart
 Will not authenticate an individual but help prove that the user is not a machine
• Therefore preventing automated password guessing / access / transaction attempts
 Non-trivial puzzle to be solved, e.g. recognizing and retyping distorted characters
• Quite helpful though many distortions are now recognizable by computers
© 2014 P. Janson
20 of 35
IT Security
Two-channel and two-factor authentication (2FA)
 When passwords aren’t good and secure enough for some application …
 … Use two-channel authentication
• Verifying computer sends random code to user via separate (secure) channel
◦ e.g. SMS to pre-defined mobile no. as Google, Apple, MS, etc. do
• User enters received code into end system
◦ Alternately mobile phone can send back picture of holder’s face
Caveats
1. Determined criminals have successfully penetrated SMS systems
to capture and forward random codes to their own mobile phone
2. Beware of two channels becoming one (e.g. lost / stolen smart phone)
• … Use two-factor authentication – Biometrics or identification token in addition to password
© 2014 P. Janson
21 of 35
IT Security
Something a user is: biometrics
 Biometrics are not new – in fact the oldest and original authentication technique in the world
• What is relatively new is using them on computers
• Typing profile, speed, response time
• Inaccurate, subject to environmental factors
• Dynamic signature / handwriting recognition
• Fairly secure, somewhat expensive
• Palm vein recognition
• Fairly secure, somewhat cumbersome
• Hand geometry recognition
• Quite secure, expensive and cumbersome
• Fingerprint recognition
• Quite affordable, not very secure unless checking live finger
• Voice recognition
• Reasonably affordable, neither very secure nor very consistent
• Face recognition – variability challenge
• Reasonably affordable, not very secure unless checking live person
• Iris recognition
• Reasonably affordable, not very secure unless checking live eyeball
• DNA recognition
• Very secure but still sci-fi
© 2014 P. Janson
22 of 35
IT Security
Biometrics present the same problems as passwords
… only worse
 Remote storage requires trust or secret transformation
 Remote transmission requires secret transformation plus time-stamping against replay
 Local verification is thus preferable but then requires trusted hardware
 As a result biometrics is preferably used as a second authentication factor
• + Biometrics verification is not immune to errors
• False positives
◦ Mistakenly accepting an identity thief for a legitimate user
• False negatives
◦ Mistakenly rejecting a legitimate user
̵ Trembling hand
̵ Sour throat
̵ Wounded finger
̵ Aging hand or face geometry
© 2014 P. Janson
23 of 35
IT Security
And biometrics are unique but not secret
Thus biometrics theft is not very hard and therefore very threatening
 Typing profile, signature, handwriting, voice may be recorded and replayed or imitated
 Fingerprint, face, iris can easily be collected in real life, imaged and faked
• http://www.youtube.com/watch?v=3M8D4wWYgsc
• BUT the trouble is: Biometrics cannot be reset like passwords !
• Cancellable biometrics – through secret transformation – can help to some extent
Source: IBM T.J.Watson Research Center – Biometrics (N. Ratha)
© 2014 P. Janson
Reprinted by courtesy of International Business Machines Corporation,
© (2008-2009) International Business Machines Corporation
24 of 35
IT Security
Something a user has: a token – soft or hard
 Enables storing and using crypto keys on user side
© 2014 P. Janson
25 of 35
IT Security
Basic cryptographic authentication protocol
• Sign unique, verifiable string to prevent replay of recorded protocol
• Timestamp-based or counter-based
User
System
userid, Sign(timestamp / count)
• Challenge-based
User
System
challenge / nonce
userid, Sign(challenge)
• Soft tokens can of course be abused by malware
Hard tokens are more costly but also more secure and more portable
• In either case tokens should be protected by passwords / PINs for local / remote authentication
to protect against token theft / loss
• Token-based authentication is thus typically two-factor
It replaces password protection with crypto protocol for remote authentication
© 2014 P. Janson
26 of 35
IT Security
Hard tokens with our without user and machine interfaces
 Using challenge- or timestamp-based protocol
Contact
Challenge
Challenge
Response
Response
 With such a token not only the user but every transaction can be authenticated
 Malware cannot interfere because the user confirms every transaction on the token
 Visa acknowledges < 0.1% fraud with such credit devices
 Fast Identification Online (FIDO) Alliance is aiming to standardize crypto protocol
regardless of local authentication device / technology
© 2014 P. Janson
27 of 35
IT Security
Two-way authentication
• All techniques seen so far focused only on ONE-WAY authentication
• Computer authenticates user but not the other way around
• This is a major flaw and danger in most existing internet services
• Rogue service can impersonate legitimate one
◦ post genuine-looking logon form
◦ and collect valid user credentials for replay
• Trouble is whichever side authenticates first risks revealing credentials to stranger
• Solution is TWO-WAY cryptographic authentication
© 2014 P. Janson
28 of 35
IT Security
Two-way cryptographic authentication protocol
• Sign unique, verifiable string in both directions
• Timestamp-based or counter-based
User
System
userid, Sign(timestamp / count)
systemid, Sign(timestamp / count)
• Challenge-based
User
System
userid,
systemid, challengeS
challengeU, Sign(challengeS)
Sign(challengeU)
System challenges user first to thwart reflection attacks
© 2014 P. Janson
29 of 35
IT Security
Authentication strength levels
 e.g. NIST Guideline 800-63
 Other classifications exist
© 2014 P. Janson
30 of 35
IT Security
NIST Guideline 800-63
 4 levels protect against ever harder attacks
Protects
Level
On-line
guessing
Replay
Eavesdropping
Verifier
faking
Man-in-themiddle
1
V
V
2
V
V
V
3
V
V
V
V
V
4
V
V
V
V
V
Session highjacking
V
 Each level calls for stronger authentication methods
Token type
Level
Soft token
One-time
passwords
Hard token
1
V
V
V
V
2
V
V
V
V
V
V
V
3
4
© 2014 P. Janson
Passwords & PINs
V
31 of 35
IT Security
Other recommendations exist
0
No identification, no authentication
1
Cleartext passwords
2
Encrypted passwords
3
Multiple encrypted factors, no hard token
4
Soft public key token
5
Multiple encrypted factors, with hard token
6
Hard public key token without keypad
7
Hard public key token with keypad
8
Hard public key token with keypad and connection to end system
9
Hard public key token with keypad and connection to end system + M out of N agreement against collusion
© 2014 P. Janson
32 of 35
IT Security
Web authentication today
 Telnet – Passwords in the clear = worthless
 rsh – .rhosts list of trusted hosts = coarse grain + worthless in case trusted host is attacked
 [ssh – encrypted password or PKI system = better but now passé]
 [HTTP
• Rare, should use password digest]
 [Forms-based
• Tricky because application-managed – not an application function]
 Cookies – insecure unless encrypted or wrapped in SSL sessions
• Poor way to simulate sessions over a connectionless HTTP exchange
• Typically include session ID, expiration term, URL domain and path
 Plain SSL
• Minimal approach today
 SSL client certificates optimal but
• Soft ones lack portability
• Hard ones require secure token distribution
© 2014 P. Janson
33 of 35
IT Security
“Unauthentication”
 Logoff is important to “close the door”
 Many systems fail to support it – like leaving door open after coming in
 Minimal requirement is automatic time-out after some reasonable inactivity period
© 2014 P. Janson
34 of 35
IT Security
New acronyms in this lesson
 2FA = two-factor authentication
 TAN = Transaction Authentication Number
© 2014 P. Janson
35 of 35