IBM Software Group, Tivoli Software

New Alternatives in Strong Authentication

February 19, 2007

Jose Bravo
Tivoli Security Sales Leader East
jbravo@us.ibm.com

2007 IBM Corporation

IBM Tivoli Software

Strong Authentication: unresolved

As technology advances each day, we realise the true meaning of its a

small world after all. Internet and automation have brought about
revolutionary changes that do make our lives easy but at the same time,
cause sleepless nights as we fight to retain our privacy due to the
dependency on technology. With more dependency, more regulations come
into play and thats why, strong authentication is even more important
than it ever was.

The virtual list of confidential records is unending and keeps growing.

Medical records, credit history, property ownership, professional licenses,
birth records, social security numbers, bank accounts, stock market data,
DMV data and much more gets uploaded each day, every minute; providing
more feed for hackers.

Increase in data creates an equal amount of increase in cyberterrorism,

data assasins and hacking; which is a much more real threat than anything
today. We see a steady incease in hacking attacks and particularly from
eastern Europe where the hacker community remains untouchable.

So far, we have been relying on an old abstraction called userid. This has
and will work, as long as the userid truly represents an intended human
being, which requires a very strong authentication.
2007 IBM Corporation

IBM Tivoli Software

Authentication today

Passwords and passwords alone remain the main channel of authentication.

We have seen PKI, Hard Tokens, Soft Token, and Biometrics try to improve
authentication however, reality is that passwords still are the sole moats
that fortify most of our systems.

No matter what rules we follow to change passwords periodically,

synchronize or reset them; fact is, password can be guessed and passwords
are shared.

This makes passwords incovenient and when a security issue causes difficult
technological changes, people often reject it either by subverting or by not
using that technology.

If encryption with keys less than 128 bits is unacceptable, so is an eight

character password.

2007 IBM Corporation

IBM Tivoli Software

What has been the best security for many years?

Something that you have (a key) or,
Something that you know (a combination)

If you do not have the option of using a key, but still want it
secured, you would need a longer combination, changed frequently
for improved security.

Most people find this bothersome and thats how passwords can be
described today.

2007 IBM Corporation

IBM Tivoli Software

Password strength
Alpha

Alphanumeric

Mixed Alpha

Mixed Alphanumeric &

special

26

36

52

94

676

1,296

2,704

8,836

17,576

46,656

140,608

830,584

456,976

1,679,616

7,311,616

78,074,896

11,881,376

60,466,176

380,204,032

7,339,040,224

308,915,776

2,176,782,336

19,770,609,664

689,869,781,056

8,031,810,176

78,364,164,096

1,028,071,702,528

64,847,759,419,264

208,827,064,576

2,821,109,907,456

53,459,728,531,456

6,095,689,385,410,820

5,429,503,678,976

101,559,956,668,41
6

2,779,905,883,635,710

572,994,802,228,617,000

10

141,167,095,653,37
6

3,656,158,440,062,9
80

144,555,105,949,057,000

53,861,511,409,490,000,000

Length

2007 IBM Corporation

IBM Tivoli Software

Security and convenience

2007 IBM Corporation

IBM Tivoli Software

Passwords

2 out of 3 Web users use < 5 passwords for all access to

electronic information
 15% use a single password

Password is best described as a toothbrush. As rightly said

by Cliff Stoll, Treat your password
like a toothbrush. Dont
share it with anyone else
and get a new one every
six months.

2007 IBM Corporation

IBM Tivoli Software

Why passwords arent secure

Problems:
 Trivial passwords
Easy to remember easy to guess
 Yellow sticky pads
 Password cracking
Some crackers claim 30% success rate

OR D
W
S
P AS
RTY
QW E
2C3
B
1
A

2007 IBM Corporation

IBM Tivoli Software

Keystroke loggers

2007 IBM Corporation

IBM Tivoli Software

The end of passwords?

Passwords have reached the end of their useful life.

Today, they only work for low-security applications.
-- Bruce Schneier*

* The Curse of the Secret Question, ComputerWorld, 9 Feb 2005

2007 IBM Corporation

10

IBM Tivoli Software

Overburdened passwords
Remember the safe box model?

What we are missing is the key OR, are we missing something key?
If we find a way to combine what you know (password) with something
that you have, we can make strong authentication a convenient and
inexpensive reality!

2007 IBM Corporation

11

IBM Tivoli Software

Finding the key: PKI & Digital certificates

Very clever and strong
Very costly to deploy and maintain
Not conveniently portable (this is probably its main disadvantage)
Can be subverted if access to the workstation is obtained
Restricted (mostly) to web based applications
Has worked really well for server side Authentication (first phase of SSL
handshake)
Today very few companies use PKI in large scale implementations

2007 IBM Corporation

12

IBM Tivoli Software

Finding the key: Hard tokens

Very strong security
Very costly to deploy and maintain (replace)
Need to carry one of these per each authenticating entity (sometimes
they come ready for a true key chain)
No access if you forget them (this is probably its main disadvantage)
since, these are portable, but not wearable
Cost and convenience restrict hard token deployment

2007 IBM Corporation

13

IBM Tivoli Software

Subverting security

2007 IBM Corporation

14

IBM Tivoli Software

Main-in-the-middle: like many other technologies

Source Arcott protection against MITM Attacks

2007 IBM Corporation

15

IBM Tivoli Software

Finding the key: coordinate or Grid Cards

Stronger than passwords but, weak authentication
Quick answer to FFIEC requirement
A large number of keys/pins, the user is asked to look for one
specific key by giving him a coordinate (i.e.D3)
Not very convenient, since the card can be forgotten
Not very secure since the card can be photocopied
One card per authenticating entity
Too costly for SMB
Can be defeated with a man-in-the-middle attack

2007 IBM Corporation

16

IBM Tivoli Software

Subverting security

2007 IBM Corporation

17

IBM Tivoli Software

Finding the key: Soft token & challenge questions

Stronger than passwords but, weak authentication
More appropriate for password resets rather than stronger authentication
Quick answer to FFIEC requirement
Basically this replaces authentication based on just something-that-youknow with something-that-you-know and something-elsethat-you
know
Reduces security to the level of the secret question which:
 is easier to guess
 is easier to look up (e.g. genealogy sites)
 is probably stored elsewhere as the answer to another Web sites
secret question
The bypass mechanism should be harder not easier

* Bruce Schneier, ComputerWorld, 9 Feb 2005

2007 IBM Corporation

18

IBM Tivoli Software

Some additional alternatives (source Gartner)

Virtual Keypads
Knowledge Based Authentication (cognitive password)
Transaction Number List (one-time-pad)
Typing Rhythm
And more

2007 IBM Corporation

19

IBM Tivoli Software

What is Biometrics? Something that you are

Source: Automated Biometrics, Nalini K. Ratha, IBM Corp.

2007 IBM Corporation

20

IBM Tivoli Software

Comparing Biometrics
Effortless

Inexpensive

Non-intrusive

Finger
Iris
Voice
Face

From: Samir Nanavati

(Zephyr Analysis)
Accurate
Source: Automated Biometrics, Nalini K. Ratha, IBM Corp.
2007 IBM Corporation

21

IBM Tivoli Software

Biometrics: strengths and weaknesses

Strongest of them all (fingerprint reader, retina scan, palm
dimensions, voice, signature, etc)
Requires costly sensors and software to function, also requires
painful, lengthy and very costly deployments (requires a centralized
database with the biometric data)
But even when implemented right, people reject it, because
biometrics is more a form of identification than authentication (a
very fine line but equally important differentiation

2007 IBM Corporation

22

IBM Tivoli Software

More about Biometrics

Governmental security is a different issue but, not everyone would be
comfortable handing out fingerprints or retina scans at their financial
institutions that could be likely to change in future.
Difficult for large deployments since the collection of the biometric data
is hard to manage.
If for some reason the central database is compromised, one cannot
produce an alternative finger print.
Best when used in combination with physical security (to avoid remote
or replay attacks)
A lot of health care concerns are associated to Biometrics and a body
part like a finger can be considered as transmission vehicle for viruses
like HIV, tuberculosis and other easily transmitted diseases.

2007 IBM Corporation

23

IBM Tivoli Software

Gummy fingers, a funny note

http://cryptome.org/gummy.htm

2007 IBM Corporation

24

IBM Tivoli Software

Out of band mechanisms: authentication using caller id,

SMS, call back?
Caller-id on land line can be easily hacked. Restricted numbers would
not work in these instances.
Land lines number can and are forwarded (it is a feature not a
weakness). SMS can be easily spoofed and is not very personal in
nature.
SMS, while popular and free in Europe, it is not free not popular here.
Latency: Some SMS authentication requires a request and a reply to
the cell phone making it slow, cumbersome and therefore not suitable
for frequent authentication. Has been attempted in other countries like
New Zealand, without much success

2007 IBM Corporation

25

IBM Tivoli Software

Two factor authentication using any cell phone

Two Factor authentication involves something that you know (a

password) and something that you have like a hard token, or digital
certificate. The idea is to use the cell phone (arguably the most personal
gadget of the world) as a the something that you have in any scheme
where strong authentication is required. The objective is to prove that a
particular time you are in possesion of your very own cell phone.

This idea required the cell provider (i.e. Verizon, AT&T, Sprint) to be
involved in the process, by programming a new service (*88 in this
example) that receives requests from any authentication requester (a
Bank in this example) and replies when the strong authentication has
been completed. There is another approach where the company that
wants strong authentication requires an IVR with a number specified for
that authenticator.

This idea is protected under patent US 7,133,662,B2

The flow here shows a user being strongly authenticated to a Bank.

The user has previosly registered his cell phone with the Bank.

2007 IBM Corporation

26

IBM Tivoli Software

The customer has already entered his userid and password

and will now perform an operation that requires stepup/strong authentication
Banking
Application

Please input token using your

cell phone

Objective: Prove to the

Bank you are in
possession of your very
own cell phone

Customers
Browser

Users cell
phone
914-588-9992

Application at
the cellular
provider

Reply once 914-588-9992

inputs 6036

In this example, the Banking Application generates a four-digit pseudo random,

on-time token: 6036. And simultaneosly sends over https a message to the
customer and to an aplication at the cellphone provider

The message at the customers browser reads: Dear customer, please use your
cell phone to dial *88 followed by this one-time token: 6036

The message to the cell provider reads: please reply to this message once
cellphone 914-588-9992 inputs token 6036. The message has a message id
number as well as a expiration time.
2007 IBM Corporation

27

IBM Tivoli Software

Once the customer enters the one time token the strong
authentication is completed
Banking
Application

4
Customers Browser

2
Wireless
Core
Network

RAN

This can be implemented as

a EAI application to TAMeb

Application at
the cellular
provider (Web
service/SOA)

Users cell phone

914-588-9992

As instructed, the customer dials *88 ( + send/call) and then 6036. This is an
out-bound message traveling over the wireless network between the cell phone
and the cell that is serving him (no cell routing/roaming required, therefore
minimal delay is added to the transaction).

Immediately, the application at the cell provider detects that there is a match
for one of the requests it received and sends a reply back to the bank

The Bank knows the customer is in possesion of their cell phone. The strong
authentication has completed and the customer is authorized to perfom the
secure operation.
2007 IBM Corporation

28

IBM Tivoli Software

This idea is not restricted to a browser. In this case the customer is

required to authenticate during an ATM withdrawal above the
normal daily limit
Application at the
cellular provider

ATM
Application
1

Please input token using your

cell phone

User at an
ATM

Users cell phone

914-588-9992

1
Reply once
914-588-9992
inputs 2359

Like before, the customer reads on the ATM screen: Dear user,
please use your cell phone to dial *88 ( + send/call) and then
inmediatly input this one-time token: 6036

The message to the cell provider reads: please reply to this

message once cellphone 914-588-9992 inputs token 2359.

2007 IBM Corporation

29

IBM Tivoli Software

Once the customer enters the one time token the strong
authentication is completed
4

Banking
Application

This can also be

implemented as a EAI
application to TAMeb

Application at the
cellular provider
Users cell phone
914-588-9992

As instructed the user dials *88 ( + send/call) and then 2359.

Immediately the application at the cell provider detects that there is a match
for one of the requests it received and sends a reply back to the bank

The Bank knows the customer is in possesion of his very own cell phone. The
strong authentication has completed and the user is given the large amount
cash requested. Or even Point Of Sale.

2007 IBM Corporation

30

IBM Tivoli Software

This idea can also be used to authenticate employees when logging

in to the corporate intranet
Windows Login
application

1
User at his
desktop

Please input token using your

cell phone

Application at the
cellular provider

1
Reply once
914-5889992 inputs
6036

Users cell phone

914-588-9992

Like before the employee reads on the PC login screen: Dear employee, please
use your cell phone to dial *88 ( + send/call) and the immediately input this
one-time token: 6036

The message to the cell provider reads: please reply to this message once
cellphone 914-588-9992 inputs token 6036.

2007 IBM Corporation

31

IBM Tivoli Software

Once the employee enteres the one time token the strong
authentication is completed
4

Banking
Application

This could be implemented

as a TAMES Adapter

Application at the
cellular provider
Users cell phone
914-588-9992

As instructed the user dials *88 ( + send/call) and then 6036.

Immediately the application at the cell provider detects that there is a match
for one of the requests it received and send a relpy bank to bank

The Bank knows the employee is in possesion of his very own cell phone. The
strong authentication has completed and the user is allowed into the Banks
coorporate network

2007 IBM Corporation

32

IBM Tivoli Software

The customer has already entered his userid and password

and will now perform an operation that requires stepup/strong authentication (Similar as the first scenario but
Banking
using an IVR)
1

Please input token using your

cell phone

Application

Customers
Browser

Users cell phone

914-588-9992

1
1
1

IVR
programmed
at the cell
provider

This approach could be more

appealing to large banks and
organizations that can afford
subcontract an IVR service with
each major wireless provider

Once 914-588-9992 inputs

6036 an SSL message is sent
to the Bank that has the IVR
service subcontracted.

On this example the Banking Application generates a four-digit psudo ramdom, ontime token: 6036. The application waits for the IVR to send the cell phone number and
token entered
The message at the customers browser reads: Dear customer, please use your cell
phone to dial *myBank (*CITI) and the inmediatly after input this one-time token:
6036. The Bank subcontract a service with the 3 mayor carriers where *myBank
routes a message to the Bank passing on the number that dialed the service and the
one time password input.
When the application receives from the IVR that 914-588-9992 has input token 6036,
it detects a match and the strong authentication is completed
2007 IBM Corporation

33

IBM Tivoli Software

2007 IBM Corporation

34

IBM Tivoli Software

zz
z
z

z
z

Questions?
2007 IBM Corporation

35