|
|
|
Features
< Back
Compliance : Sarbanes Oxley : Technology : Security
Zero-Footprint Solution to Combat Phishing
By
Andy Cottrell
|
|
Andy Cottrell
CTO
TriCipher
|
The ultimate solution to phishing is strong authentication, which
requires client software, usually in conjunction with a physical
token. However, widespread resistance to managing software and
handling physical tokens means that universal strong
authentication is not currently feasible. For users who cannot be
strongly authenticated, financial services companies are seeking a
zero footprint solution that not only provides some phishing
protection, but also provides a frictionless growth path to stronger
authentication in the future.
Why Passwords Are Vulnerable to Phishing
The main reason passwords are vulnerable is that they are shared
secrets. The user types the password into a web page and hits
submit. The password is sent over the Internet to the web server,
where it is validated against a "master password file." The number
of potential attacks against this system are myriad, but the ones
most relevant to phishing are:
? The user types password into fake web site, giving the
password to the phisher
? The user sends password in response to phishing email
? A Trojan or keystroke logger captures password at desktop
? A phisher sets up a proxy server, sits in the middle of the
session, and captures the password
The reason these attacks are so successful is that the phisher
needs only the password to authenticate as the legitimate user.
The web site (or any relying system) has no way of knowing
whether the person entering the password is the legitimate user or
an attacker. In addition, faking a URL or SSL lock is easy in the
browser, so the user can't tell they're on a phishing site rather than
the legitimate site. What's needed is something in addition to the
password that isn't a burden to the user, and a way for the user to
tell that they're on the legitimate web site.
How the Solution Works
The solution works by giving each user a second factor encrypted
in a cookie stored in the browser. It strengthens authentication in
both directions:
? The user has confidence they are on the correct site when they
enter their password, because they see information specific to
them that only the bank would know. This helps them
authenticate the server.
? The password and 2nd factor from the cookie are combined
server side to perform authentication. This helps the server
authenticate the user.
? The browser second factor that allows the display of this
information cannot be stolen by a rogue server and is non-invasive
to the user.
SERVER TO CONSUMER AUTHENTICATION
A web site is very easy for a phisher to copy. Toolkits are even
available on the web for would-be phishers to create a fake web
site quickly and easily, along with the fake, branded email they
need to lure victims. Users have a difficult time identifying visually
whether a site is legitimate or not, and many don't look for the SSL
lock or server certificate.
TACS uses the same widespread technology that greets you by name when you go back to a web site to allow a user to identify the legitimate web site. The web
server reads the cookie and pulls the welcome message from
TACS to show to the user. It can be as simple as the user's name,
the name of a stock in their portfolio, or some agreed-upon
greeting. This allows the user to better identify whether they are at
the legitimate site, or a phisher's.
CONSUMER TO SERVER AUTHENTICATION
When the consumer enters their user id and password, the server
should have some level of confidence in whether this person is
who they claim to be or is an attacker. A returning user with the
correct encrypted cookie has a high likelihood of being who they
claim to be. An attempted logon without the cookie may indicate
an attacker, which gives the server a chance to use out of band
communication or perform knowledge-based authentication to
confirm the user's identity. Although not foolproof, this protection
makes it more difficult for an attacker to impersonate a user.
LOGIN FLOWS
When a user goes to the web site to log in, the site needs to be
able to recognize the following possibilities:
1. New User: New user with no credential, but wishes to
obtain one.
2. User at Registered PC: Existing user logging in from a PC
with their cookie on it.
3. Roaming User: Existing user with no cookie wishing to
authenticate. A variety of reasons may cause the cookie
to be unavailable, ranging from a deleted or corrupted
cookie to a new machine where no cookie has ever
existed for that user.
New User
For a new user requesting a credential, the organization's existing
registration process need change only slightly. The only additional
step is activation, where the user logs in for the first time and the
cookie is set on the user's machine.
Steps:
1. User provides details necessary for identity verification
according to the existing registration process.
2. The organization verifies this information, again using the
existing process.
3. The organization then issues a TACS browser 2 factor
credential to the user. This credential needs to be
activated before it can be used (this will load the cookie
into the browser). Note that the user's password need
not change from what they are using today.
4. The organization communicates activation instructions to
the user. We suggest this take place in a separate band
(e-mail, snail mail, phone, etc.) though this can also be
done in real time online where desired.
5. The user accesses the activation page and provides their
username and activation code and chooses a password.
6. TACS crafts the cookie, and the web application plants
this cookie on the user's browser.
7. Once activation is complete, the user is automatically
logged in.
User at Registered PC
Most of the time, the user authenticates at a machine from which
they have successfully authenticated previously and which
consequently has a valid cookie in place. The web application will
use the TACS API to find and utilize the most recently used cookie
on the machine to present a personalized greeting to the user.
This provides assurance to the user that they are on the correct
web site, helping to authenticate the server to the user.
In addition, the web site can implement a link to help guide other
users of the same machine to identify themselves. This can be
done using a standard "if this isn't you, click here" link that will
guide the user through a user identification process.
For a user at a registered PC:
1. The user requests the login page.
2. The server reads the cookie, and presents the
appropriate welcome message that the user will
recognize. This authenticates the server.
3. The user is asked for their password only, since the
username is known based on the cookie.
4. Once the password has been provided, the server
decrypts the cookie. The server uses the password and
cookie to authenticate the user with TACS. If the cookie
has been altered or tampered with authentication will
fail.
a. If an incorrect password is entered, the system can
limit the number of unsuccessful tries. The policy
regarding the number of tries can be set either in
TACS or in the web application.
b. If a correct password is entered but the cookie
check fails, organization policy is enforced. Generally,
the relying system should assume that this attempted
login is from an attacker, and immediately suspend
the credential until further action can be taken.
However, a variety of policy steps can be set up to
determine whether the account has been
compromised and to issue new credentials where
necessary.
5. If the cookie verifies, the user is authenticated and
permitted into the application.
User with No Cookie
At times, users will need to login from a different machine,
perhaps because they bought a new computer, because their antispyware
application deleted all their cookies, because they're
traveling, or because they would like to access the online service
from more than one computer. In this case, the web system
doesn't find the cookie when the user tries to authenticate. The
server can't show the user the expected welcome message, so the
user may be unsure whether they are on the correct site. In
addition, the server now cannot fully authenticate the user, so
must ask for more information in order to create a cookie for later
use in this browser.
To verify the user and create a cookie for the current browser:
1. User provides the web application their username.
2. The web application verifies the username with TACS and
retrieves data on that user to perform a validation
process. The data can either be stored in the TACS ID
Vault (recommended for security) or can be obtained
from another system. The validation process can be
done in several ways.
TACS ID Vault User
a. Simple interactive knowledge-based authentication
via the web browser. In this case the user is asked
questions, and the answers are compared to the
data retrieved.
b. E-mail "out of session" communication.
i. An email is sent to the user that includes a URL.
This verifies that they have access to the email
account they originally used to create the
credential.
ii. Other types of "out of session" mechanisms
such as phone, IM, etc. can be used to deliver a
migration code.
c. The user can choose to:
? Register: If the user wishes to 'register' this new
machine for future use, an appropriate 2nd factor is
stored in a cookie on that machine.
? Use One Time: If the user is only using that machine
for the duration of this session, no cookie is created,
but the user can log on.
? Migrate: If the user wishes to switch to this machine
permanently, the old cookie is no longer valid. The
new cookie placed in the current browser becomes
the only valid cookie.
? Register Multiple Machines: If the user wishes to
register this machine also and policy allows it, a
cookie is placed in this browser, and the old one
remains valid.
3. Once identified, the user is asked for their password, and
the password is verified. At this point the new machine is
registered for the user and their cookie is placed on their
machine.
4. The user is authenticated and permitted into the
application.
Set up of the TACS ID Vault
The set up of the TACS ID Vault for this type of credential is easy.
Using the Management Tool, add a user accessible field to store
the required information (using XML format) and grant the user
read/write access to this field. The organization can also create a
separate administrator account with read-only access to this field.
Client Configuration
The login is designed to be as seamless as possible for the user,
and to work on a wide variety of platforms. The requirements for
using this type of authentication are very straightforward. The
user must have a browser capable of supporting cookies, and the
browser security policy must be configured to allow long-lived
cookies to be stored and retrieved. Any intermediaries that pass
HTTP traffic such as a web proxy or firewall must allow these
cookies to pass through without modifying them. Each user of a
particular client machine will have their own cookie, so several
cookies of this type may exist in the browser.
Other Security Options
The browser 2nd factor can also be used with a one time
password token or a browser-based certificate.
Long-Term Protection
Users with browser 2 factor credentials can be easily migrated to
stronger authentication types as new attacks arise or in response
to new regulatory requirements.
Summary
For large user bases where client-side software is not yet needed,
TACS browser 2 factor credentials provide phishing protection
without a client footprint. For higher risk users or applications,
TACS can issue a variety of credential strengths to balance
security, cost and usability across a range of different needs. In
addition, TACS is unique in its ability to allow you to migrate users
to stronger authentication as needed in response to new attacks
or regulation.
|
|
|
|
