Evaluating Strong Authentication Systems

{LANG_NAVORIGIN} Authentication
Nick Owen 02/25/2005

Introduction & Goals

The purpose of this document is to provide the information required for you to evaluate the WiKID Authentication System on its financial, technical and operational merits.

There are a number of drivers for adopting strong authentication: risks are increasing, the number of connected systems is increasing, the number of users requiring remote access is increasing, and regulations such as Graham-Leach- Bliley, HIPAA, and California’s SB1386 are affecting more companies. Authentication is a key pillar for secure systems and enterprises are more and more aware that passwords are not a strong enough form of authentication. They have looked at hardware-based tokens and other solutions, but have not significantly adopted strong authentication.

There are three reasons why hardware tokens have failed to significantly penetrate the authentication market: convenience, extensibility, and cost. Users tend to dislike having the carry the additional hardware. If it’s lost or left at home, it is very inconvenient. Further, tokens are a micro-point solution: they are only good for one authentication system at one enterprise. They cannot be used across multiple enterprises, nor are they very extensible inside the enterprise.

The WiKID Authentication System address these concerns with a new patentpending approach built for today’s authentication needs. The WiKID Authentication System is the first and only authentication system capable of 100% end-user selfservice. In most cases, it generates immediate cost savings. It is easy to implement and maintain and it is highly extensible. It is the first authentication system to handle both strong authentication and password resets out of the box.

Two-factor Authentication

There are three factors of authentication: something you know, something you have and something you are. Weak authentication only requires one factor, strong authentication more than one. Passwords are the most dominant form of weak authentication. ATM cards, the most ubiquitous two-factor system, require both knowledge of the PIN and possession of the card. WiKID Systems has developed a unique, patent-pending architecture that dramatically simplifies two-factor authentication and creates an extensible platform for future needs.

Historically, there are three types of strong authentication architectures for readerless single-purpose hardware devices (“tokens”):

• Challenge-response – A challenge is issued and the response must match the expected response.
• Time-synchronous – The passcode changes periodically and must match the expected passcode. The system must deal with clock drift, usually by allowing multiple codes to be valid at any given time, reducing security. Time-synchronous soft-tokens are vulnerable to the generation of future valid-codes by moving the device clock forward.
• Event-synchronous – A counter on the device generates the next valid passcode, which must match the expected passcode on the server. The server must be able to “hunt” for a future valid passcode in case the counter on the device is moved ahead of the counter on the server.

While these solutions were acceptable in their day, they are expensive, costly to set-up and maintain, and not extensible for today’s authentication needs. The WiKID Authentication System is based on a “request-response” architecture. When the user wants to login to a service, they enter a PIN into the device; it is encrypted and sent as part of a request to the WiKID Authentication Server. The WAS checks the encryption, validates the PIN and if the account is active and enabled, responds with an encrypted passcode. The device decrypts the passcode and the user enters it into, say, their VPN service, which in turn validates it with WAS. If the code matches, the user is granted access. When the client doesn’t have Internet access such as when a cell phone is out of coverage, the client falls back into a challenge-response mode.

Development & Security Philosophy

Our goals in developing the WiKID Authentication System are as follows:

• The system should be as secure as existing two-factor authentication solutions
• The system should be easier to use, maintain and administer than existing two-factor authentication systems
• The system should be less expensive in TCO than existing authentication systems – either passwords or tokens, relying on self-service as much as securely possible
• The system should be highly extensible, addressing multiple authentication needs as they arrive

It is our belief that a company can increase security while simultaneously reducing costs. We have designed and developed our system with these goals in mind.

The WiKID Architecture

The WiKID Authentication System consists of the WiKID Authentication Server (WAS), the WiKID Client and various protocol modules that connect to network clients such as a RADIUS server, firewall, LDAP directory, NT Domain server, etc.

The WiKID Authentication Server

The WiKID Authentication Server is a hardened Linux appliance running the WiKID Authentication server. The WAS handles requests from network clients (while a network client may be a server, it is a client to the WAS), authentication (passcode) requests, logging, reporting, user management, certificate management, WiKID Domain creation, protocol module management and administrative preferences.

The WAS is running a firewall and is not accessible via Ping.

WiKID Domains

Each instance of the WAS runs under a particular security domain. The security domain is intended to segregate users with respect to access and services. For example, Intranet access may be provided with one domain, partner Extranet access with another and public Internet (Website) access with a third. Separate security policies can be provided for each domain and access can be granted on a device/individual user basis. The security policy includes PIN length, max bad PIN attempts, max bad passcode attempts, passcode lifetime, and max number of consecutive offline challenge-response logins. Upon creation, each domain generates a key pair for encryption within the passcode request/passcode reception process.

Each domain is represented by a 12-digit code, which represents the zero-padded IP address of the server (or zeropaddedipaddress.wikidsystems.net). The domains have both a device name and a server name, so that the Client can have a domain that is “VPN” on the client but refer to “Executive VPN” on the server.

The WiKID Client

The WiKID Client runs on a PC or Internet-enabled wireless device (Blackberry, J2ME phone, BREW phone, Palm device or PocketPC). The client generates the public/private key pair and maintains the domain connection information. It does not store the PIN (PINs are stored on the WAS). The client can add new domains, delete domains and select domains for passcode requests. Unlike other two-factor systems, the WiKID client for each domain is the same, whether the domain is on the same WAS or for a completely different company. This capability makes WiKID perfect for cross-enterprise strong authentication, which is increasingly important for today’s extended supply chains.

Protocol Modules

The WAS communicates to various network clients (VPN concentrators, firewalls, servers, etc) via protocol modules. Currently, WiKID supports LDAP and RADIUS and we provide COM and EJB object interfaces for custom application integration. The EJB interface is known as the “WAUTH protocol” and it is used to provide payload and transport encryption. WAUTH must be enabled on all WiKID Authentication Servers as it is used for all local host protocol modules.

Network Client

Network clients are simply the devices on the network responsible for granting access to the users: RADIUS servers, VPN concentrators, firewalls, routers, switches, applications, etc. They accept the username and passcode from the user, send the passcode to the WAS, and, if the WAS validates the code, they grant access.

For a network client to be active on a security domain, it must be registered on the WAS.

Below is a sample diagram of a fully configured WIKID System:


Example Scenario

In this scenario, Bill Jones, an employee of a telecom company, is the administrator of several systems within the company’s headquarters building. Bill requires VPN access to his systems late at night and on the weekends from home. Bill has a Java-enabled phone and a personal computer at his house. In this scenario, the components of the system are as follows:

• The WiKID Authorization Server is, as always, the WAS.
• The Protocol Module is RADIUS. It is important to note that RADIUS is used on a trusted network in this case.
• The domain is the telecom’s corporate admin VPN.
• The Wireless Devices is Bill’s Java Phone.
• The Network Client is the corporate VPN service (provided by a Cisco device).
• The Terminal Service is Bill’s home computer equipped with a modem.
• The additional devices provide access (the wireless gateway, the communication server) and security services (the firewalls).

Operational Considerations

One of the reasons why two-factor authentication has failed to deeply penetrate the authentication market is due to the operational hassles of hardware tokens. WiKID Systems has eliminated the largest aggravations in deploying, managing and using strong authentication. By enabling employee self-service to the fullest extent possible, deploying a WiKID Authentication System is easy, cost-effective and secure.

Deployment & Initial Validation

The WiKID Authentication System is the only solution where initial validation can be completed automatically – 100% self-service by the end-user. The WiKID Client as shipped contains no security information, only the ability to create the public/private key pair, so this client can be installed anywhere by anyone. (Many devices now support over-the-air download, making software deployment incredibly simple.) It is not until after the key pairs are exchanged between the WiKID Client and the WiKID Server and after that exchange has been validated through a second, trusted channel that a security relationship has been created.

Below is a diagram of how the initial validation can work in full self-service mode:

• The user enters the 12-digit WiKID Domain identifier. The WiKID Client creates the public/private key pair and sends its public key to the server requesting a configuration file for the domain.
• The WiKID Server responds with the configuration file and its public key, encrypted by the Client’s public key.
• The User is prompted for a PIN and told the minimum PIN length for that domain. The PIN is encrypted and sent to the Server.
• The Server decrypts the PIN and stores it. It returns a one-time registration code. The account has now been created, but is not validated. In order to validate the account, the WiKID Server must receive the same registration code from a trusted Network Client over a second channel.
• The end-user logs into the trusted Network Client, perhaps using an existing hardware token or, more likely, they log on their LAN (a trusted network) using their existing LAN credentials. WiKID will supply ASP scripts that run on IIS using NT/Active Directory credentials. The user logs into the IIS server and enters the registration code.
• The registration code is sent to the WiKID Authentication Server and the account is activated.

Alternatively, the administrator can manually enable the user. Please note that the end-user can re-initialize the same way should they forget their PIN.

With hard-tokens, the device must be associated with the user on the server and physically delivered to the user, a process that costs $15 or more.

Management
The web-based interface of the WiKID Authentication server is intuitive and easy to use. Security professionals will appreciate working on security, rather than the logistics of token management.

The WiKID Client is easily replaceable. There is no box of hardware tokens with limited lifetimes locked up in the administrator’s office. If a device is lost, it is much easier to replace software.

WiKID developed the system with an eye toward ongoing management. Updates to the system will be available via a secure download process or via a shipped CD.

Convenience & Ease of use

WiKID Systems is committed to ease-of-use for the end-users and the administrators.

Employees dislike having to carry additional hardware, such as hardware tokens. Most employees tend to like self-service applications and to dislike calling helpdesks. WiKID automated initial validation system is simple for employees to use. Our ability to reset LAN passwords is a perfect self-service application.

Portability – works anywhere

A key requirement for mobile workers is to be able to log in from any location, even from a kiosk or other non-company owned PC. WiKID provides the online requestresponse mode and falls back to the challenge-response mode when out of wireless coverage. It requires no reader and works everywhere.

Extensibility

Counter-based and time-synchronous tokens have a one-to-one relationship with their authentication server. The WiKID Client, can have relationships with multiple WiKID Servers. This extensibility can save money internally and increase security externally.

WiKID 2.0 will include the ability to add a domain that handles password resets for NT and Active Directory domains. As noted below, password reset calls are expensive and all too frequent. WiKID users can have a domain for remote access and one for resetting LAN passwords.

Increasingly, companies are opening up their networks and applications to suppliers, vendors, consultants and other 3rd parties. While these tight ties have increased productivity and smoothed supply chains, they have also increased security risks. Do your vendors use strong authentication to log into your network? Do your employees use strong authentication when they log into your vendor’s networks? The ease of deployment and low price-point of WiKID makes it practical to deploy strong authentication through the whole supply chain. Moreover, endusers can use the same client for both companies. Your vendors will see the same financial benefits as you do, increase the value of the entire chain.

Scalability

Each request and response on the system is a mere 251 bytes. This small transaction size allows the server to handle a huge number of users. Multiple servers are more for fault-tolerance than scalability.

Future capabilities

Already WiKID Systems is the first authentication system to combine two-factor authentication with a password reset capability out of the box. The WiKID architecture provides for robust future flexibility through new clients, new protocol modules, new network clients and new technologies. As an example, we can add location as a 3 rd factor once the wireless carriers publish location-based information. As more wireless devices include short-range wireless connections such as Bluetooth, we can add proximity too.

Security/Technology

There are many flavors of two-factor authentication, some more secure than others. We believe that relative security is a very central factor in choosing an authentication solution. While cost savings, extensibility and manageability are important, without security, you don’t want to create a false sense of security.

Relative Security Analysis Chart

Item	Notes
Two-factor	The combination of PIN and device is very strong
Passcodes random	There is no way to predict the passcodes or to brute-force attack the server
Passcode length random	Randomizing the passcode length protects against a race attack/man-in-the-middle attack on a fixed length response system (future release).
Only one passcode valid at any moment	Passcode lifetime can be set per domain by the administrator, which can’t be done with a time-synchronous system.
Eliminates shoulder surfing, keyboard sniffers, Trojans	Passcode is only used once.
PINs and passcodes never sent over network together	In some systems, the PIN is appended with the passcode, which increases the risk of PIN compromise. With WiKID, the PIN and passcode are never transmitted together and are always asymmetrically encrypted.
Published algorithm	WiKID uses only published algorithms, increasing the security of the system through peer-review process.
Risk from loss	Users more likely to keep wireless device separate from laptop, decreasing risk of combined loss. Tokens are often kept with laptop. A lost or stolen token is a nuisance. A lost cell phone is a financial risk for the user, aligning incentives.
No password file for attackers to target	Password files are the gold mine for attackers. WiKID removes that target.
PIN stored on server	There is no way to brute force attack the PIN as it is stored safely on the WiKID Authentication Server. Certificates protected by passwords are subject to cloning and brute-force attacks on the password.
Network clients require a WiKID Server Certificate	Prevents a Denial-of-service attack from un-approved Network Clients.
Domain Security Options	Maximum bad PIN attempts Maximum bad passcode attempts Maximum consecutive challenge-response logins PIN length configurable Passcode lifetime
Cross-enterprise security	There is no reduction in security when multiple domains are created making cross-enterprise strong authentication viable for the first time. This capability fits well with Single Sign-On efforts such as Liberty Alliance.
Logging	Complete logging and reporting. Integration via Syslog is available.

Financial Considerations

Potential Cost Savings

The Request-Response architecture provides a flexible, extensible platform that significantly increases the cost savings potential from implementing the WiKID Authentication System. Wherever possible, WiKID has enabled self-service and automation and we have attacked the costs associated with authentication.

The Costs of Passwords

Companies are aware that passwords are neither secure nor inexpensive. Employees seek to choose passwords that our easily remembered, which makes them easy to guess. The IT department wants a strong password policy – 8 to 12 characters, no words, alphanumeric and changing every 30-60 days. The result is calls to the helpdesk to reset forgotten passwords that cost $15-30 each. The average employee will call 4-5 times per year! For a 30,000 employee Fortune 500 company, that means $1-3,000,000 per year! For smaller firms the cost per call is higher. Moreover, most small and medium sized businesses (SMBs) don’t have 24x7 helpdesks. So if you’re an attorney billing $300 per hour and you’re locked out of the network after 5:00 PM, you’ve lost some serious money.

The cost of hardware tokens

The vast majority of companies still rely on usernames and passwords for remote authentication. Some companies have deployed one-time passwords systems, especially time-synchronous, hardware based tokens, but the majority of deployments are very small and the total penetration is minimal. Each token costs money; it is expensive (and an administrative hassle) to distribute tokens; the tokens have a limited life; the authentication servers are expensive both upfront and in ongoing costs.

They also do not address the issue of password resets, failing to provide a key value to the enterprise. Below is a breakdown of total authentication costs for two companies, a large Fortune 500 company and a medium-sized service firm. By analyzing their authentication costs, we can see how WiKID can save any firm money.

	F500 Company	Medium Service Co.
Password Costs
Number of employees	30,000	3,000
Password reset cost	$15	$30
Total Calls per year	120,000	12,000
Password Costs	$1,800,000	$360,000
Hard Token Costs
Number of Tokens	30,000	3,000
Cost of each Token per Year	$18.50	$23
Distribution Cost per Year	$7.50	$10
Server Software per Year	$160,000	$32,000
Server Maintenance per Year	$86,400	$17,000
Hard Token Cost per Year	$1,026,400	$148,000
Combined Authentication Costs	$2,826,400	$508,000

Here is a breakdown of authentication costs after WiKID has been deployed:

	F500 Company	Medium Service Co.
WiKID Password Costs
Number of employees	30,000	3,000
Password reset cost	$15	30
Total calls per year	12,000	1,200
Total Password Costs	$180,000	$36,000
WiKID Strong Authentication Costs
Number of WiKID Clients	30,000	3,000
Cost per WiKID Client per year	$12.00	$20
Distribution cost per year	$1	$1
WiKID Server cost per year	$9,500	$6,000
Server maintenance per year	$0	$0
Total WiKID cost per year	$399,500	$67,000
Total Authentication Costs	$579,500	$103,000
Savings WiKID vs Hard Tokens	$2,246,900	$405,000
Savings per employee	$74.90	$135.00

This analysis does not include the potential lost productivity for employees that cannot get a password reset after hours nor do they include the potential savings from averting an attack. However, they should provide enough information and guidelines for an analysis of a company’s own potential savings.

By combining strong authentication, password reset capabilities, self-service and automation into a secure authentication platform, WiKID Systems can save an enterprise money while increasing security.

Conclusion

More than ever, companies are seeking to get more for their money. Security traditionally has been viewed as a cost center that mitigates risk primarily. WiKID Systems takes the approach that there are always ways to improve systems to eliminate costs that can also improve security. The WiKID Authentication System embodies this belief by attacking authentication costs and risks simultaneously and providing automated self-service capabilities that eliminate the overhead of typical strong authentication systems. The WiKID Authentication System improves upon traditional authentication systems operationally, in security capabilities and in financial terms.

WiKID is the first company to provide a password-reset tool as part of a strong authentication system, the first to create a fully automated, self-service initialization solution; the first to deliver a two-factor authentication system that is capable of easily and securely handling cross-enterprise strong authentication without requiring a reader. We intend to continue this level of innovation.

More Authentication tutorials and guides














Your IP address will be sent with this e-mail

From e-mail to e-mail