A Myriad of Options and Opportunities

collarlimabeansSécurité

23 févr. 2014 (il y a 3 années et 1 mois)

53 vue(s)

a l a d d I n . c o m

Authentication Mechanisms
:

A Myriad of Options and Opportunities


Andrew Lindell

Chief Cryptographer

Aladdin Knowledge Systems

Assistant Professor

Bar
-
Ilan University

a l a d d i n . c o m

Background

Authentication is a basic cryptographic task


Due to its importance, there is an abundance of different
solutions and different models


Human memory (passwords)


Hardware devices


Online servers


Biometrics


Logon


Authentication to applications


Authentication to websites


Authentication for authorization

a l a d d i n . c o m

Choosing an Authentication Mechanism


In order to make an informed decision


It is necessary to understand the
security ramifications

of
each choice (this requires an understanding of
how

they work)


It is necessary to weigh up the
risks and benefits

of the
different options


Not all applications need the highest security


An
Internet newspaper service

(even with paid subscription)
does not require smartcard
-
based authentication


Not all mechanisms are comparable


One mechanism may be excellent assuming a trusted
computer, but be very poor otherwise


Another mechanism may be “reasonable” on

both a trusted or untrusted computer


Which is better?

a l a d d i n . c o m

Where is the User in the Equation


Users are often considered to be the enemy


They are the often the weakest link in the security chain


They don’t choose good passwords and don’t make efforts to
keep them secret


They don’t follow security policy


Why?


Reason 1


education:

they often don’t feel that they are the risk
(who would target them?)


Reason 2


frustration:

how many passwords can be tolerated?


My university account, my work account, my smartcard, my building
code, my car code, 2 PINs for ATM cards, 2 Internet banking
passwords, my computer at home, countless other Internet
passwords


Users are often expected to do the
impossible

a l a d d i n . c o m

This Talk


We will present a list of key
decision factors

to be
considered when choosing an authentication
mechanism


Security factors


Other factors (cost, ease of deployment etc.)


We will then consider two mechanisms in order to
demonstrate an analysis based on these factors


Single sign
-
on (4 variants)


Smartcard (logon, laptop protection,




web authentication)


(Plain passwords, one
-
time passwords




and biometrics appear at the end of




the talk…)

a l a d d i n . c o m

Decision Factors


Security

Security factors


Vulnerability to attacks


Requires an in
-
depth understanding of the mechanism and
threats


Multiple factors of authentication


Typically a yes/no answer


Protection from phishing attacks


Has become more and more important


Effect of use on an untrusted local machine


This factor is often ignored


Usability as a security issue


See more next…

a l a d d i n . c o m

Usability as a Security Issue


Usability is typically viewed as an issue of human
comfort, but this is
not

the case


Example


fingerprint
-
protected access to a building


Due to high security needs


Access to a building is protected by a fingerprint reader


The reader is calibrated to accept very few false positives


Tailgating is strictly forbidden


The result:


Users have to try
multiple times

to enter


A line typically forms at peak hours


Due to overall user frustration,
tailgating is common



as is
opening the door to users

(who can claim that they can’t get their
fingerprint to be accepted)

a l a d d i n . c o m

Usability as a Security Issue


Another classic example of usability = security


Administrator forces high
-
quality passwords


Users don’t change their password


Administrator forces frequent password change as well


Users change their password immediately back


Administrator forces password to be different from 15 previous


Users make a series of passwords:
pwd001!
,
pwd002!
,…


Administrator forces users to take a random password
r%D3y)u


User writes the password on a piece of paper and



leaves it on their desk


Yes this still happens today!!!

a l a d d i n . c o m

Usability as a Security Issue


Successful security products must factor usability in


When analyzing a new product/method, the question of
user convenience needs to rank very high


How can we improve in this area?


Help users
minimize the number of devices

they carry


If you issue a smartcard or other device, incorporate the proximity
inside (this also ensures that they don’t forget their device at their
desk)


If users need flash drives, incorporate this as well


Provide users with
added personal benefit


If the security product contains a password management system, let
the user use it for their personal passwords as well

a l a d d i n . c o m

Decision Factors


Others

Other factors


Ease and cost of deployment


Does it require (expensive) hardware devices


Does it require modifying existing applications and infrastructure


Ease of management, including recovery


What happens when a user forgets/loses something


How easy is it to add and revoke users


How easy is it to update a user’s information


Applicability


Can it be used to protect a laptop?


Does it need the user to be online?


Usability

a l a d d i n . c o m

Single Sign
-
On

The basic idea


The user remembers a single password


The single password unlocks multiple passwords
belonging to the user




******

a l a d d i n . c o m

Single Sign
-
On Models


Online:

user authenticates to the
server with a password, the server
authenticates for the user to the
application


Online
-
smartcard:

user
authenticates to the server with a
password
-
protected smartcard
and the server authenticates to
the application


Smartcard:
user authenticates
to a smartcard that contains all of
the user’s passwords


Software:

the user’s passwords
are encrypted under its single
password and stored on disk

******

******

*******

******

******

******

a l a d d i n . c o m

Single Sign
-
On


How it Works

Online single sign
-
on


User authenticates to a server:


With
smartcards
, the user authenticates to the smartcard and
then public
-
key operations are used to authenticate to the server
(e.g., SSL with client authentication)


With
passwords
, the user sends her password to the server
over a secured SSL channel


After authenticating the user, the server carries out the
logon procedure to the application for the user (again,
over a secured channel)


The user’s password to the application is never revealed

******

a l a d d i n . c o m

Single Sign
-
On


How it Works

Smartcard
-
based single sign
-
on


The user’s passwords to applications and websites are
stored on the user’s smartcard


The user authenticates to the smartcard, after which the
user password to the application is read to the PC and
automatically filled into the logon page of the application

a l a d d i n . c o m

Single Sign
-
On


How it Works

Software
-
only single sign
-
on


The user’s passwords to applications and websites are
stored on the user’s machine (or flash disk)


The passwords etc. are encrypted by the user’s single password


The user inputs its password which is used to decrypt
the application passwords, after which the user
password to the application is automatically filled into the
logon page of the application

a l a d d i n . c o m

Single Sign
-
On


Security Factors

Vulnerability to attacks


Software:



Vulnerable to offline dictionary attacks on password file


Given the encrypted passwords (and profiles), can guess the user
password and attempt to decrypt


This is very effective: millions of passwords can be checked per
second


If stored on flash disk for portability, vulnerable to theft


All modes:


No offline dictionary attacks on application passwords


Can use very long passwords for applications, logon to laptop, file
encryption and so on

a l a d d i n . c o m

Single Sign
-
On


Security Factors

Multiple factors of authentication


Online SSO with smartcard authentication:


Yes


Online SSO with password authentication:


No


Smartcard
-
based SSO:


Yes


Software
-
only SSO:


No


a l a d d i n . c o m

Single Sign
-
On


Security Factors

Protection from phishing attacks


Online SSO with smartcard authentication:


Yes
, as long as done correctly


SSL with PKI
-
client authentication provides full protection
against phishing (even man
-
in
-
the
-
middle)


We show why this is the case later on


Online SSO with password authentication:


The connection to the server may be vulnerable to phishing


Even passive (standard) phishing can catch the user’s password
that is used to authenticate to the SSO server


Smartcard and software SSO:


Good protection (phisher needs to fool software, not the user)


Software can check URL and other factors

a l a d d i n . c o m

Single Sign
-
On


Security Factors

Effect of Use on Untrusted Machine


Online SSO with smartcard authentication:


Resident malware can access user’s accounts while the user is
logged in


this is
inherent

in all SSO solutions


Nothing else is compromised


This is optimal!


Online SSO with password and software SSO:


Resident malware obtains user’s password and full access (for
online SSO, until password is changed)


Smartcard SSO:


User’s passwords can be stolen by resident malware


Effect can be limited by changing them regularly, or by having
the smartcard authenticate directly

a l a d d i n . c o m

Single Sign
-
On


Security Factors

Usability as a security issue


Online SSO (smartcard and password):


Requires the user to be online


Only applicable where online SSO works and so user still needs
to remember many passwords


For smartcards: requires device as well as above


Smartcard SSO:


Requires carrying a device


Provides great usability because all user’s password woes are
solved (even at home)


Software SSO


Without a device, lack of portability


With a device, identical to smartcard SSO (on this issue)

a l a d d i n . c o m

Single Sign
-
On


Other Factors

Ease and cost of deployment


Online SSO (smartcard and password):


Requires online server


Requires modification of applications to work with the server


For smartcards: requires a device as well as above


Smartcard SSO:


Requires a device


All applications can remain unchanged; very easy deployment


Software SSO


Cheap, trivial to deploy

a l a d d i n . c o m

Single Sign
-
On


Other Factors

Ease of management, including recovery


With smartcards:


Needs smartcard management


Without smartcards:


Only a single password needed so less helpdesk calls for
forgotten passwords


Can be devastating in the case of a lost password (without
backup)

a l a d d i n . c o m

Single Sign
-
On


Other Factors

Applicability


Online SSO (smartcards and passwords)


Needs the user to be online


Can only work with some applications


Smartcard and software SSO


Can be used for any application where passwords are used


No modification needed

a l a d d i n . c o m

Summary


SSO

Online SSO with smartcard authentication


Strongest security


Best against phishing and use on untrusted machine (although latter is
still a problem)


Weak on other factors


Limited applicability, costly deployment

Smartcard SSO


Good security


A little weaker on an untrusted machine, otherwise strong


Strong on other factors


Best applicability, reasonable cost, easy deployment, great usability

Online SSO with password authentication


Reasonable security and weak in other factors

Software SSO


Weak security, great in other factors (except recovery)

a l a d d i n . c o m

Smartcard Authentication


A smartcard is used in the authentication process


Typically, this involves a PKI and smartcard public
-
key
operations


Applications


Web authentication: SSL with client authentication


User signs on SSL handshake messages to prove its identity


Network authentication


Smartcard logon


Laptop protection


Directly use smartcard to encrypt files as well


Key observation


PKI
-
based authentication is always stronger than passwords!


The secret key never leaves the smartcard


The secret key cannot be guessed with any reasonable probability

a l a d d i n . c o m

SSL (Secure Socket Layer)


Two phases


Handshake protocol: set up a secret key
between the client and server


Record layer: communicate securely using
the secret key



Modes of handshake


Server authentication:


The client is certain of the server’s identity


The server learns the client identity “later”


Client and server authentication:


Both client and server learn each other’s
identity

Client

Server

Time

a l a d d i n . c o m

SSL (Secure Socket Layer)


Server authentication:


The client encrypts a random value under the
server’s public
-
key (obtained from the server’s
digital certificate)


Only the legitimate server can extract that value


The server computes a cryptographic function
(HMAC) using the key


Only the legitimate server can do this



Client authentication:


The client signs on
all
of the messages of the
handshake protocol


The server verifies the signature (using the
public
-
key obtained from the client’s certificate)


Only the legitimate client can sign

Client

Server

Time

a l a d d i n . c o m

Phishing Attacks


In a phishing attack, a user is fooled into visiting a rogue
site that impersonates the real one


There are two types of phishing attacks


Passive attacks:

a user goes to a website, following an email
for example, and gives up his or her password


Active (man
-
in
-
the
-
middle) phishing:

a user goes to a website
that actively impersonates the target website and acts as a
bridge between the user and site



Smartcard authentication and
passive


phishing


The user gives up no authentication



information to the site and so nothing




is lost

a l a d d i n . c o m

Smartcard Authentication and Active Phishing


Can the attacker obtain a valid SSL session with the
server, with the client’s “help”


The client receives the
attacker’s certificate

(otherwise the
attacker won’t learn the secret value sent by the client)


The attacker can try to get the client to sign the SSL messages


Key observation:


The client signs on the server certificate as well!


In this attack, the “server certificate” is actually the attacker’s


Conclusion: the server will not accept the client authentication

a l a d d i n . c o m

Smartcards


Security Factors


Vulnerability to attacks


Highly resilient


Multiple factors of authentication


Can (and should) be used in combination with a password


Protection from phishing attacks


Strong protection (with SSL, it’s resilient to all such attacks)


Effect of use on untrusted local machine


No damage (only smartcard password is stolen, but it’s useless
without the smartcard)


Usability as a security issue


Requires a device (downside)


Can remember a short PIN rather than a long password

a l a d d i n . c o m

Smartcards


Other Factors


Ease and cost of deployment


Requires user devices (cost plus physical deployment)


Requires a server to manage server
-
side authentication


Requires changing interface for authentication


Ease of management, including recovery


Loss of device needs to be taken care of


Applicability


Can be easily used for all SSL web authentication and network
logon


Has many other applications (e.g., laptop protection)


Usability


Requires carrying a device


Summary:

best security
, excellent for untrusted
machines, wide applicability

a l a d d i n . c o m

Summary


All authentication methods require user education


User cooperation is improved when they “like” the
method


What about devices?


Users don’t always like carrying devices


This can be solved by providing additional functionality to the
one device


Proximity for entering the building


Built
-
in flash drive

a l a d d i n . c o m

Summary


Different devices fair differently in different scenarios


Security factors to consider are


Vulnerability to attacks


Multiple factors of authentication


Protection from phishing


Effect of use on an untrusted machine


Usability


Other factors to consider are


Ease and cost of deployment


Ease of management


Applicability

a l a d d i n . c o m

Summary


Single sign
-
on provides an excellent solution, but should
be used only on trusted machines


Smartcard
-
based gives wide applicability and easy deployment


Smartcard PKI
-
based authentication is by the far the
best from a security perspective, but is limited in
applicability


Should be used wherever possible


There is a distinct advantage to devices that can work in
multiple modes

a l a d d i n . c o m

An Ideal Suite


An ideal setup for obtaining high security in an
organization


Smartcard logon is used to logon to local computers within the
organization, for connecting to the VPN, and for web
authentication (where possible)


Single sign
-
on is used for authenticating to applications and
websites when at work (or when working from a computer owned
and protected by the organization)


One
-
time passwords are used for authenticating to the
organization over the web for email access and the like
(especially from untrusted computers)


It is possible to use smartcard
-
based single sign
-
on and
have one device do all of the above (and more)

a l a d d i n . c o m

© Copyright 2007 Aladdin Knowledge Systems Ltd. All rights reserved.


Aladdin, Aladdin Knowledge Systems, the Aladdin Knowledge Systems logo, eToken and eSafe are trademarks

of Aladdin Knowledge Systems Ltd. covered by patents www.aladdin.com/patents; other patents pending.


You may not copy, reproduce (or the like), or use in any other way whatsoever, whether directly or indirectly, any
of the materials represented and/or disclosed herein without the express written consent of Aladdin.


Some of the information contained herein may be proprietary information of Aladdin or third parties and all text,
images, graphics, trademarks, service marks, logos, trade names and other materials which are part of this
communication are subject to intellectual property rights of Aladdin or third parties. The information herein is
provided “as is” without any warranty, express or implied (by statute or otherwise), of any kind whatsoever.
Aladdin does not undertake any obligation to update the information herein and it does not assume responsibility
for errors or omissions.

a l a d d I n . c o m

Legal Notice

a l a d d i n . c o m

Thank You

a l a d d i n . c o m

Password
-
Only Authentication


This is the simplest and most well
-
known method


For this reason, I will focus on one issue that is often ignored


I will ignore the all
-
important discussion on password quality etc.



There are two main attacks on password
-
based
authentication


Online attacks


Offline dictionary attacks

a l a d d i n . c o m

Attacks on Password Authentication

Online attack


Try to authenticate multiple times by just guessing the
password (the most basic attack)


Applicability


Any password
-
based authentication mechanism


Very easy to implement


Countermeasures


Retry counter


Increasing delays



Note: countermeasures are not as simple as they look


Retry counter makes for an easy denial of service attack


Increasing delays is better but can be annoying


Neither presents an “across the board” attack

a l a d d i n . c o m

Online Guessing Attacks


Should we be concerned about online guessing attacks?


With a reasonable delay, it takes a very long time to guess even
mediocre passwords


Nevertheless…


Some users use terrible passwords (the passwords
admin
,
login
,
pass
,
passwd
,
password

are very popular)


Sometimes an attacker doesn’t care which user is compromised


Even a low
-
level user can provide a foot in the door


For subscription services, it doesn’t matter which user is broken into


Can online attacks be prevented or slowed down?


In most cases, an automatic agent carries out the attack


CAPTCHAs can be used to prevent these attacks

a l a d d i n . c o m

CAPTCHA


The aim: Force a human to be involved in the
authentication process


Mass online guessing attacks are all carried out by computers
who continually attempt login with new passwords


Use a problem that is easy for a
human

but hard for a
computer


One such problem is distorted text recognition


a l a d d i n . c o m

CAPTCHA Example

In the spaces below, type three (3) different English words appearing in the picture above.

BEAUTIFUL

STEM

QUIET

Submit

a l a d d i n . c o m

CAPTCHA Pros and Cons


A good CAPTCHA prevents automated widespread
password guessing


A bit annoying for the user, but is reasonable (at least it doesn’t
require remembering anything)


As with everything, there is a
tradeoff

between making the task
easy for a human, without making it too easy for a computer


CAPTCHAs can be made easier or harder, depending on what is
needed

a l a d d i n . c o m

Using CAPTCHAs

When should CAPTCHAs be used?


Highly recommended for pages used infrequently


E.g., automatic website for password recovery (e.g., based on
personal question only the user should know)


After a number of incorrect password guesses, a
CAPTCHA can be presented


When a system detects an “across
-
the
-
board attack”, it
can use CAPTCHAs to stop it


This inconveniences users, but is OK if it doesn’t happen too
often

a l a d d i n . c o m

Attacks on Password Authentication

Offline dictionary attack


Given some
function

of the password (e.g., a hash or
encrypted file), guess the password, recompute the
function and compare


Typically very effective (can check millions per second)


Applicability


Any mechanism that allows an attacker to obtain a function of the
password


CHAP: attacker receives <
challenge, H(
pwd
,challenge)>


Password logon: password file contains
H(
pwd
)


File encryption using a password as a key:
ENC
pwd
(file)


There exist effective tools; e.g.,
L0phtCrack


Countermeasures


Use repeated hashing and salt to slow down attack


Use a long truly random password (unrealistic)

a l a d d i n . c o m

Password
-
Based Encryption Example

a l a d d i n . c o m

Using Passwords

An important rule:


Passwords should
never

be used when offline dictionary
attacks can be carried out


Encrypting files


Protecting laptop (logon + file encryption)


CHAP


Bluetooth 2.0 pairing protocol


In some cases offline dictionary attacks
cannot

be carried
out and the use of passwords
may be reasonable


Authentication to smartcards


Web authentication over SSL

a l a d d i n . c o m

Password Authentication


Security Factors


Vulnerability to attacks


Severe vulnerability to offline dictionary attacks


Severe problem due to use of weak passwords


Multiple factors of authentication


NA


Protection from phishing attacks


None


extremely vulnerable


Effect of use on an untrusted local machine


A stolen password can be used undetected


Usability as a security issue


The need to remember many passwords is a usability issue with
severe security ramifications

a l a d d i n . c o m

Password Authentication


Other Factors


Ease and cost of deployment


Very cheap


Easiest deployment


Ease of management, including recovery


The cost of forgotten passwords can be very high if a help desk is
needed to recover from a forgotten password


Otherwise, easy management


Applicability


Highest


Usability


Excellent for few passwords, but today with the abundance of
passwords, usability is low and user frustration is high



Summary:
low security and usability, wide applicability and easy
deployment

a l a d d i n . c o m

One
-
Time Passwords (OTP)


The basic idea


Users are provided with a device that outputs a different
password “each time”


Software
-
only OTPs are much less secure


Each password is valid only once, so:


Stealing a password after it has been used is inconsequential


Stealing a password before it has been used constitutes limited
damage

a l a d d i n . c o m

One
-
Time Passwords


How are the passwords generated


A
secret cryptographic key

is stored in the device


A unique value is “encrypted” each time with the key (using a
standardized algorithm like AES or HMAC)


The unique value can be the current time (time
-
based) or an
index that is incremented each time a button is pressed
(sequence
-
based)



Randomness of the one
-
time passwords


When properly implemented (using AES or HMAC), it is
infeasible to predict future passwords from previous ones!


a l a d d i n . c o m

One
-
Time Passwords


Security Factors


Vulnerability to attacks


Stealing one
-
time passwords is hard to do (need access to
device) and provides very limited damage


Multiple factors of authentication


Yes (can require PIN as well as one
-
time password)


Protection from phishing attacks


No direct protection, but the damage is limited to a single access
(mediocre protection)


Effect of use on untrusted local machine


Damage is limited to a single access (this is optimal!)


Usability as a security issue


Requires a device (downside)


Can remember a short PIN rather than a long password

a l a d d i n . c o m

One
-
Time Passwords


Other Factors


Ease and cost of deployment


Requires devices (cost plus physical deployment)


Requires a server to manage server
-
side authentication


Application/web interface remains unchanged


Ease of management, including recovery


Users need to remember only a single password, so less password
resets are necessary


Loss of device needs to be taken care of


Applicability


Can be used for applications and websites that use passwords, but
requires some change on the server side


Cannot be used to encrypt files and is problematic for laptop logon


Usability


Very good


Summary:

good security, excellent for untrusted machines,
reasonable applicability

a l a d d i n . c o m

Biometrics

Authentication using human identifying factors


Fingerprints



Well accepted methodology


Long
-
used in law enforcement


Hand prints


More complete picture than fingerprint


Retina patterns


Unique but difficult and invasive


Requires a powerful scan


Iris patterns


Not so unique (but somewhat so)


Voice recognition



Can be fooled by recording someone’s voice


Face recognition


Still difficult today and requires human intervention

a l a d d i n . c o m

Fingerprints


What’s the Problem?


Fingerprints have been used for decades in law
enforcement and are considered very reliable


What’s the difference here?


In law enforcement a
person

compares the
fingerprints


In biometric authentic
-
ation, the comparison is
carried out by a
machine


In law enforcement a
match is only a match
when it is
very close


In biometric authentic
-
ation, regular users must
almost always succeed, so
reasonable matches

must
also be accepted

a l a d d i n . c o m

Biometrics


the Ultimate Problem


False positives


Allow an unauthorized user in


False negatives


Deny access to authorized users



For biometric authentication to work, both false positives
and negatives must be
low


This is very difficult for computer automated verification

a l a d d i n . c o m

Fingerprints


A Deeper Study


To understand the difficulties of biometrics, we will study
fingerprint authentication in greater detail


Fingerprint authentication is secure if we can be sure
that there is a person standing behind the fingerprint


This may seem obvious, but it’s not


People leave their fingerprints everywhere


what stops
someone picking up a user’s fingerprint and using it?


Reader reliability


The reader must ensure that a person stands behind the
fingerprint (use texture, temperature, moisture etc.)


The computer receiving the print must be sure that it

comes from the reader (need reader authentication)

a l a d d i n . c o m

Attacks on Fingerprint Authentication


Physical attacks

on fingerprint
-
based authentication


In March 2005, car thieves chopped off the finger of a car
-
owner
in order to bypass the car’s fingerprint recognition system


The car was an expensive Mercedes and had an immobilizer
that could not be bypassed


It’s best to be able to bypass the system when necessary!


Fault attacks

on fingerprint
-
based authentication


These attacks rely on
faults

in the reader


Example:


Spray some material on the reader surface that makes the present
fingerprint image stand out


Press a smooth finger (or something else) on the reader


Some readers accept this as the valid print already there

a l a d d i n . c o m

Gelatin Liquid

Drip the liquid

onto the mold

Put this

mold into a
refrigerator to
cool, and then
peel carefully

Attacks on Fingerprint Authentication


Cloning attacks:

construct a clone of someone’s finger


This is possible because people leave their fingerprints
everywhere











Works on a large number of readers

a l a d d i n . c o m

Fingerprint Security

When Should Fingerprints be Used?


For

mild security needs
, they can be excellent


Keep children out of your account and out of inappropriate web
accounts


They can be used as an

additional factor

of
authentication together with a password


If a
person is present

next to the reader (like a reader
that is used to enter a building that is guarded at all
times), then cloning attacks are very difficult

a l a d d i n . c o m

Fingerprints


Security Factors


Vulnerability to attacks


Vulnerable to cloning attacks (other attacks also exist)


Multiple factors of authentication


Can (and should) be used in combination with a password


Protection from phishing attacks


NA


Effect of use on untrusted local machine


NA


Usability as a security issue


Requires a device (downside)


Can remember a short PIN rather than a long password

a l a d d i n . c o m

Fingerprints


Other Factors


Ease and cost of deployment


Requires devices (cost plus physical deployment)


Requires a server to manage server
-
side authentication


Requires changing interface for authentication


Ease of management, including recovery


Users need to remember only a single password, so less
password resets are necessary


Loss of device needs to be taken care of


Applicability


In principle, can be used widely, but difficult to do so


Usability


Very good, as long as false negatives are low


Summary:

medium security