MultiFactor | Security Blog

SecureAuth®, “Virtual Certificate Authority” Solution for Secure Authentication

noreply@blogger.com (MultiFactor Corp) — Tue, 22 Jul 2008 00:06:00 +0000

By Garret Grajek, CISSP
COO, MultiFactor Corp.

A Deployable X.509 Authentication Solution for Networks and Web Applications

MultiFactor SecureAuth offers the enterprise the unique ability to utilize strong X.509 authentication without costly overhead.

The value of X.509 private/public key authentication is well known to security professionals, but it can be less intuitive to the security novice. In simple terms the X.509 authentication provides an algorithmically proven method for end-users (clients) to confirm that they are communicating with legitimate servers and not attacker sites (See Figure 1). The recent DNS flaw Dan Kaminsky, a well respected security industry expert, made known to the IT world via bug fixes by Cisco, Microsoft and others, makes this type of “left hand side” or client authentication more relevant than ever.

Figure 1 - Clients are vulnerable to attacks that lure them to illegitimate sites instead of the target (destination) site.

An X.509 v3 public/private key pair allows an enterprise to utilize “bi-lateral” (client <-> server) authentication. In this matter, the client confirms the legitimacy of the server, before passing important credentials e.g. account password or transactions like asignature or financial activity. It is exactly this type of bi-lateral authentication that nullifies DNS attacks like the one recently reported.

So why are more enterprises not utilizing X.509 authentication?

(2) Main reasons:

Cost
Complexity

Security personnel have been aware of X.509 bi-lateral authentication since the 90’s. However, cost has prohibited its widespread use (See Figure 2).

Figure 2- The complexity of a “classic” X.509 infrastructure is too daunting for most enterprises

Key costs include:

Hosting a Certificate Authority
Tracking both the served and revoked certificates

SecureAuth® eliminates the high-cost and complexities of managing X.509 certificates via a “Virtual Certificate Authority”

SecureAuth:

Removes the cost of deploying certificate servers
Removes the cost of tracking deployed/revoking certificates
Removes the cost of out-of-band (SMS, Telephony) registration systems
Removes the cost of converting current web servers to C-SSL authentication

SecureAuth® uniquely utilizes a “drop-in” authentication server ,a virtual machine or hardware server, that becomes a trusted resource which is able to:

Connect to MultiFactor’s hosted C.A., SMS servers, and telephony servers
Serve up private/public key pairs unique to an enterprise
Create/install Trusted Root Pairs that map directly to your enterprise

A key to SecureAuth is its ability to utilize the enterprise native data store, allowing it to avoid a costly and insecure replication of data. SecureAuth’s authentication server connects directly to the enterprise's existing data store to create X.509 certificates that map directly to data in the local store (See Figure 3).

Figure 3- The SecureAuth “Authentication Appliance” solution alleviates the cost and complexity of X.509 authentication. (Click to enlarge)

For the enterprise the addition of the SecureAuth authentication component is key. The deploying enterprise configures its web application to trust SecureAuth authentication via .NET Forms for Microsoft authentication, or SAML assertions for non-Microsoft applications. The SecureAuth appliance is factory-configured to securely utilize the MultiFactor hosted certificate, SMS and Telephony services.

The Enterprise is delivered a unique identifier that allows them to securely utilize MultiFactor’s hosted web services. In addition, certificates granted from the web services are embedded with identifiers that are uniquely registered to that enterprise. The identifier is stored in the end-user’s private certificate, in the “OU” field (See Figure 4).

Figure 4- The enterprises is assigned a unique OU that is utilized in both certificate delivery and validation, only enterprise-unique certificates are validated.

This unique ability to issue and validate certificates for an enterprise, without the enterprise ever hosting a certificate server, makes SecureAuth® powerful. SecureAuth® can be deployed in a days which makes it a deployment-must for the enterprise needing a secure solution for their application and network needs.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth Can Secure End Users Against DNS Attacks

noreply@blogger.com (MultiFactor Corp) — Tue, 15 Jul 2008 05:26:00 +0000

SecureAuth Secures End Users Against DNS Attacks the Enterprise may Incur.

By Garret Grajek, CISSP
COO, MultiFactor Corp.

In early July, Dan Kaminsky reported that a serious flaw exists in DNS software. Despite the bad news, Dan remained scrupulous and worked behind the scenes with Microsoft, Cisco, Sun, CERT and others before publicly disclosing the flaw on July 9^th, details of which will be revealed in August. Patches have been made available by various vendors.

The question enterprises have to ask themselves is, are they comfortable with the public DNS system being their only line of defense in assuring that their END-USERS are actually connected to their site? (e.g. When the end-user clicks http://www.ubank.com/ is the end-user going to the site hosted by “Ubank,” or is the end-user being rerouted to a fictitious site)? (See Figure 1)

Figure 1 - The hacker utilizes a DNS attack as one of the methods to lure the Internet user to the attacker site.

The key to addressing this solution is to provide the end-user with a secondary mechanism that ensures he or she is at the correct site. As the Kaminsky report reveals, DNS alone is not 100% reliable, and it should not be the only mechanism utilized for resource-valued sites.

A mechanism that does ensure an end-user’s connection to the legitimate site is client-side SSL (C-SSL). C-SSL technology utilizes public/private key cryptography to conduct a bi-lateral authentication that affirms the proper identity of not only the client, but also the server.

Figure 2 - A deployment utilizing PKI can thwart this type of DNS attack by utilizing public/private key technology to verify the site’s address.

The issue has been implementing this technology on two sides:

Client side
Server side

Historically, PKI has been too difficult to implement on the client-side due to end-user education. Equally difficult, certain components have made implementation and maintenance too burdensome on the server-side. MultiFactor SecureAuth addresses both of these issues. (See Figure 3)

Figure 3 - SecureAuth addresses client-side and server-side complexities to allow bi-lateral, X.509 authentication. (Click to enlarge)

MultiFactor SecureAuth resolves PKI issues for the client

SecureAuth is 100% browser-based. It uses the browser to:

Store the Private/Public Key Pair
Retrieve the proper end-users’ key pair
Validate the proper end-users’ key pair

The end-user requires no knowledge of storing, revocation, or porting of certificates. SecureAuth’s unique, click-through registration method handles all the complexities for end-users.

MultiFactor SecureAuth resolves PKI issues for the Server

SecureAuth handles the X.509v3 authentication and validation without C-SSL; this saves an enormous amount of complexity for end-users. SecureAuth’s uniqueness is a self-contained X.509 validation mechanism that enables the validation of end- users’ X.509 credentials by utilizing standard server-side certificates. (E.G. SecureAuth utilizes the certificate that enables SSL encryption for a site, such as https://www.company.com/).

Figure 4 - SecureAuth utilizes its own technology to validate the client-server authentication, thereby validating both parties. This greatly reduces overhead and deployment cost to the X.509 solution. (Click to enlarge.)

In summary, enterprises wishing to provide secure sites are concerned about authenticating servers and end-users accessing the targeted sites. MultiFactor SecureAuth is an excellent solution that securely validates both parties, in a deployable manner.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others

SecureAuth® for Microsoft SharePoint (WSS 3.0) and MOSS

noreply@blogger.com (MultiFactor Corp) — Tue, 08 Jul 2008 02:32:00 +0000

SecureAuth is the most Secure, Integrated Authentication Solution for Microsoft SharePoint

By Garret Grajek, CISSP
COO, MultiFactor Corp.

The most Secure, Integrated Authentication Solution for SharePoint

MultiFactor SecureAuth is the only tokenless, non-phishable authentication solution for Windows SharePoint Server (WSS 3.0) that strongly authenticates the end-user AND the server, in an easy-to-deploy manner. SecureAuth is ideal for the growing number of SharePoint deployments that host secure data, including:

• Financials
• Sensitive internal and partner documents
• PCI/FFIEC/GLB regulated materials
• Government and Health Care information

The key to SecureAuth is its integration to the enterprise’s existing SharePoint installation and existing data store. (See Figure 1)

Figure 1 –SecureAuth® Integration into a Microsoft SharePoint Deployment (Click to enlarge)

Microsoft SharePoint is an Important Tool in Today’s Businesses

With Windows SharePoint Services 3.0, IT professionals can tailor or extend the Windows SharePoint Services foundation to create new, efficient, Web-based tools. Enterprises can:

Manage business documents more easily
Build rich, flexible, and scalable Web-based applications and Internet sites
Expand platform services and common framework for document management to offer enterprise-wide functionality for records management, search, workflows, portals, personalized sites, and more.

SecureAuth utilizes native SharePoint Forms-Based-Authentication

MultiFactor SecureAuth is designed to work with the data connector and authentication components native to the Microsoft SharePoint installation. Unique for an X.509v3 authentication product, SecureAuth® can utilize the native ASP.NET forms based authentication, thus greatly simplifying the integration for the SharePoint administrator. (See Figure 2).

Figure 2 - SecureAuth® utilizes native SharePoint Forms Authentication (FBA) (click to enlarge)

SecureAuth Provides the Complete Solution for Enterprises to Secure SharePoint

Using a combination of a web server module and web services, SecureAuth provides a turnkey solution to deliver an algorithmically proven method to thwart man-in-the-middle and phishing attacks (See Figure 1).

The SecureAuth solution features out-of-band self-registration that automatically delivers X.509 certificates seamlessly to end-users (See Figure 3). The solution eliminates the need for administrator resources to deploy software, install upgrades, or train end-users on complex, remote access procedures.

Figure 3 – SecureAuth has built-in, secure, out-of-band registration (click to enlarge)

SecureAuth Distinct Features:

Utilizes SharePoint native Windows Forms Authentication
SharePoint installation does NOT require code modification
Utilizes secure C-SSL authentication without modifying the existing web server
Full protection from man-in-the-middle, phishing attacks

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth solves X.509 Portability for Authentication

noreply@blogger.com (MultiFactor Corp) — Tue, 01 Jul 2008 20:46:00 +0000

SecureAuth solves X.509 Authentication Mobility

By Garret Grajek, CISSP
COO, MultiFactor Corp.

A breakthrough in the SecureAuth authentication solution is what MultiFactor calls "PKI-Free" mobility of the X.509 v3 credential.

Classic PKI solutions require end-users to understand how to export, transport and import their authentication credentials. MultiFactor's unique approach is to provide simple self-registration process. (See steps 1-4 below).

MultiFactor solves this mobility issue, by:

Providing integrated secure mobile registration, via:

Telephony OTPs (One-Time-Passwords)
SMS/Text Messaging OTPs
E-Mail OTPs

Configurable Short and Long Term Certificates

Short Term:

10 minutes to 48 hours

Long Term:

2 days to 10 years

Mangeable from a simple web-GUI

No PKI-knowledge needed by administrator
NO C.A.'s required to be installed

Require "AAA+Certificate" authentication

PKI credential is just one factor
User must have a valid account in the enterprise data store
SecureAuth utilizes the enterprise data store
SecureAuth has no data store of its own

Thus when a user utilizes a different machine (kiosk mode) the user simply re-registers and a new, valid credential is crated for that user. The user doe NOT need to:

Understand private/public key technology
Carry a device
Transport the credential
Import any credential or new device

The user self-registration process is self-explanatory and requires no help desk support. Here is a step-thru of the process: (click each image to enlarge)

Image #1: User enters his/her UserID to begin Self-Registration Process
(Note: Site can be public or private - the user chooses for better security)

Image #2: The user self-registers by selecting from a (enterprise-configurable) list of options

Image #3: User enters One-Time-Registration Code via Java Keypad

Image #4: User inputs his enterprise (AD, LDAP MS-SQL, etc) password
(Note: This is stored at the enterprise and not duplicated by SecureAuth)

Image #5: SecureAuth registers the User's Browser
(Note: Browser can be FireFox, Internet Explorer or Safari)

Image #6: Lastly the user is redirected back to the ASP.NET/SharePoint Application

The portability and ease-of-use for end users, make MultiFactor SecureAuth the ideal solution for:

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

MultiFactor SecureAuth® Delivers an Efficient, Inexpensive Solution for Enterprises to Become PCI Compliant for Remote Access

noreply@blogger.com (MultiFactor Corp) — Mon, 23 Jun 2008 22:28:00 +0000

SecureAuth, Remote Access and PCI DSS Compliance

By Garret Grajek, CISSP
COO, MultiFactor Corp.

PCI DSS compliance has become a driving factor in the security of many organizations.

Not only has PCI become a requirement by the payment card industry, but it has become and example to all organizations of how practical security can be implemented and business continuity maintained. For many years the concern over the cost of implementing solutions securely has outweighed concern over the impact of failed security. Over the last few years, growing headline breaches have created an atmosphere of awareness of the damages a breach can cause to an organizations financial structure and reputation.

The key PCI DSS requirements for an authentication solution that proposes to aid in compliance are:

This article will address both of these key requirements - as they relate to remote access. Specifically for networks utilizing MultiFactor SecureAuth authentication for Cisco remote access.

Requirement 8: Assign a unique ID to each person with computer access

PCI DSS Requirement 8.1: Identify all users with a unique username before allowing them to access system components or cardholder data

SecureAuth for Cisco VPN authentication is designed for enterprises to easily meet the requirement of distributing individual user IDs to end-users. SecureAuth provides a methodology of user self-enrollment, to securely distribute PCI-compliant authentication credentials (X.509 credentials are PCI compliant, see PCI DSS Requirement 8.2).

PCI DSS Requirement 8.2: Employ authentication, in addition to unique identification for all users

SecureAuth for Cisco VPN creates a secure user credential which is mapped to an enterprise-mapped UserID. The SecureAuth credential is utilized by the Cisco VPN appliance to securely identify and authenticate the user. The UserID is in the SecureAuth credential presented to the Cisco VPN appliance upon attempted access by the end-user. (See Diagram #1)

Figure #1 – SecureAuth creates and utilizes a unique ID per user (click to enlarge)

PCI DSS Requirement 8.3: Implement two-factor authentication for remote access to the network by employees, administrators, and third parties

SecureAuth is a two-factor authentication solution that utilizes the SecureAuth X.509 credential and the enterprise-stored password.

SecureAuth for Cisco VPN authentication works in conjunction with the

Cisco appliance to authenticate a user with the securely delivered SecureAuth X.509 credentials. (The SecureAuth X.509 credential meets the 8.5 PCI DSS requirement for “individual certificate”) . The Cisco VPN is set to utilize “AAA + Certificate” authentication, thus enabling “true” 2-factor authentication: the user must have both the SecureAuth certificate and input the password associated with the user’s account. (See Figure #2)

Figure #2 – The Cisco VPN is set to utilize both “AAA + SecureAuth Certificate” authentication (click to enlarge)

SecureAuth differentiates itself in the marketplace by providing the easiest to deploy certificate solution to meet the 8.3 PCI DSS requirement.

PCI DSS Requirement 8.4: Encrypt all passwords during transmission and storage, on all system components

MultiFactor SecureAuth for Cisco VPN authentication does NOT have its own user credential and password datastore. MultiFactor utilizes the directory (AD, ADAM, LDAP) that the Cisco VPN is using natively. (See Figure #2)

This helps the enterprise meet PCI DSS Requirement #8.4. The enterprise does NOT have to create sync and encrypt a new set of data information.

Figure #3 – SecureAuth utilizes the native user store the enterprise has connected to the Cisco VPN. (click to enlarge)

PCI DSS Requirement 8.5: Ensure proper user authentication and password management for non-consumer users and administrators, on all system components

The MultiFactor SecureAuth appliance is administered via a secure GUI. All administrators are required to authenticate via strong 2-factor SecureAuth authentication. (Certificate plus UserID/password) . (See Figure #4)

Figure #4 – SecureAuth Administrators must uniquely authenticate utilize secure 2-factor X.509 authentication. (click to enlarge)

PCI DSS Requirement 8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects

SecureAuth administration accounts are uniquely created and associated with individual accounts, therefore configuration modifications are associated with specific administrators, as outlined in PCI DSS requirement 8.5.1.

PCI DSS Requirement 8.5.2: Verify user identity before performing password resets

SecureAuth requires end-users to perform a 2-factor authentication, “certificate + password” before they are allowed to modify their passwords. The PCI DSS 8.5.2 requirement is met by forcing users to strongly authenticate before modification of their password.

PCI DSS Requirement 8.5.3: Set first-time passwords to a unique value for each user and change immediately after first use

SecureAuth works in conjunction with the Cisco ASA to reset passwords on first usage. The Cisco ASA sees the “must change password” attribute set in the data store, and gives end-usesr the appropriate screens to change their passwords.

PCI DSS Requirement 8.5.4: Immediately revoke access for any terminated users

MultiFactor SecureAuth is unique in X.509 authentication solutions by providing instant revocation. By removing any terminated individuals on the data store of record, SecureAuth facilitates one-button revocation (See Figure #3)

SecureAuth for Cisco VPN Authentication requires the end-user to have both a valid SecureAuth certificate and authenticate with a valid password. (See figure #2). If the user is removed from the data store, Cisco VPN, utilizing SecureAuth authentication, will not grant access to that terminated user.

PCI DSS Requirement 8.5.5: Remove inactive accounts at least every 90 days

An enterprise can set the SecureAuth credential to be valid for 90 days or less, thereby forcing users to re-authenticate every 90 days.

PCI DSS Requirement 8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed

MultiFactor SecureAuth has a configurable certificate length that can be set in accordance to security and resource requirements. Enterprises are asked, by PCI DSS requirement 8.5.6, to create credentials that are time-configurable. SecureAuth offers this feature.

PCI DSS Requirement 8.5.7: Communicate password procedures and policies to all users who have access to cardholder data admin

MultiFactor SecureAuth is a user self-enrollment product that “walks an end-user through” an easy process, to obtain a secure credential. Additionally, the product utilizes the enterprise datastore and thus the password policies around these IDs.

PCI DSS Requirement 8.5.8: Do not use group, shared or generic accounts and password

SecureAuth for Cisco VPN authentication makes this requirement obtainable for enterprises. Users share accounts because of the pain in distributing unique authentication to individuals. SecurAuth’s unique self-enrollment for X.509 credentials makes compliance to this requirement possible.

PCI DSS Requirement 8.5.9: Change user password at least every 90 days

SecureAuth is an effective tool in meeting PCI DSS Requirement 8.5.9. The requirement requires an enterprise to change the password every 90 days. SecureAuth requires the end-user to change his or her security credential every 90 days (Or whatever time the enterprise determines). The SecureAuth authentication credential can be set from 1 hour to 10 years. SecureAuth enables an enterprise to meet the requirement today, and adjust accordingly, should the requirement change. (Figure #5)

Figure #5 - Enterprises can select the length of the certificate for their end-users. (Click to enlarge)

PCI DSS Requirement 8.5.10: Require a minimum password length of at least seven characters

SecureAuth utilizes the enterprise’s Datastore (See Figure #3); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).

PCI DSS Requirement 8.5.11: Use passwords containing both numeric and alphabetic characters.

SecureAuth utilizes the enterprise’s Datastore (See Figure #3).; therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).

PCI DSS Requirement 8.5.12: Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

SecureAuth utilizes the enterprise’s Datastore (See Figure #3). ); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment (See Figure #2).

PCI DSS Requirement 8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts

SecureAuth for Cisco VPN authentication has a lock-out feature for registration. The default for this configurable feature is (3) attempts.

PCI DSS Requirement 8.5.14: Set the lockout duration to thirty minutes or until administrator enables the user ID

In accordance with requirement 8.5.14, accounts can be locked out by configuring the data store from which SecureAuth is pulling data (See Figure #3).

PCI DSS Requirement 8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal

The SecureAuth/Cisco VPN solution relies on the Cisco VPN settings for session duration and session idle enforcement. This setting is set in the Cisco VPN, to enforce session idle.

PCI DSS Requirement 8.5.16: Authenticate all access to any database containing cardholder data. This includes access applications, administrators, and all other users

SecureAuth does not have its own data store; therefore the effort that the enterprise puts into securing access to the “data store of record” can be used by SecureAuth; no additional work is needed, given that there is no additional data store. (See Figure #3)

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth Deploys Secure X.509 Authentication in Less Than a Day

noreply@blogger.com (MultiFactor Corp) — Tue, 17 Jun 2008 22:27:00 +0000

MultiFactor SecureAuth uniquely enables enterprises to rapidly deploy non-phishable authentication.

By Garret Grajek, CISSP
COO, MultiFactor Corp.

SecureAuth for Microsoft and Federated Web Authentication is the non-phishable authentication solution that can be deployed in less than a day’s effort.

Enterprises are looking for authentication solutions that actually address the issues of phishing, identity-theft, man-in-the-middle and man-in-the-browser attacks. Unfortunately – solutions such as one-time-passwords and web-picture solutions simply do not address these problems, because the end-user is not authenticating the server. (See Figure #1)

Figure 1 – End Users are vulnerable to attacks where the end server “impersonates” the legitimate target

Security engineers know the solution to this dilemma. What needs to be enacted is a solution that:

Authenticates the end-user
And... Authenticates the server

The 2^nd part of this equation has been the most difficult. A methodology that has been algorithmically proven to solve this “bi-lateral” authentication dilemma – is Public Key Infrastructure. Unfortunately – the infrastructure to deploy a working PKI infrastructure has been beyond daunting. (See Figure 2)

Figure 2 – Standard PKI Infrastructure is far too complicated for a standard enterprise to deploy

The SecureAuth solution is unique, in that it abstracts the complexities of a PKI and PKI registration from both the end user and the deploying enterprise. With SecureAuth an enterprise can deploy the SecureAuth solution into its infrastructure in less than a day. For VPN authentication the integration is simply a matter of integrating the SecureAuth appliance with the enterprise network device. (See MultiFactor SecureAuth for Cisco VPN Authentication.)

For web authentication, enterprises usually desire more customization than a drop in appliance. For this reason, SecureAuth offers SecureAuth for Microsoft Applications and SecureAuth for Federated Applications.

A key value and differentiator for the SecureAuth solution is its ability to be deployed rapidly into the existing infrastrure – in fact, the product is designed to be deployed in less than a days effort.

The product has (4) basic installation steps, all designed for web programmers to work with existing data and applications integration mechanisms.

The (4) steps to a MultiFactor SecureAuth integration are:

1. Install the SecureAuth Web MSI module on an IIS server
2. Connect SecureAuth with your datastore
3. Redirect your application to the SecureAuth URL
4. Link SecureAuth to MultiFactor’s Web Services

1. Install the MultiFactor SecureAuth MSI

This is a trivial step where the enterprise simply clicks through the SecureAuth MSI. The installation executable creates a SecureAuth virtual directory with the necessary account privileges to execute all of SecureAuth’s enterprise side functionalities, including data connector commands, certificate inspection and web service calls.

Estimated Deployment Time:

1-2 hours by Web Admin

Figure 3 – SecureAuth installs with a simple MSI executable

2. Connect SecureAuth with your DataStore

The SecureAuth solution utilizes .NET classes to connect to the existing datastore. SecureAuth can take advantage of the largest set of data connectors in the world: The .NET library of membership and profile classes. (See figure 4).

Estimated Deployment Time:
2-4 hours to Microsoft AD or MS/SQL by ASP.NET data programmer

Figure 4 – SecureAuth utilizes .NET Membership and Profile Classes

3. Redirect the application

The key to the SecureAuth solution is its ability to abstract the authentication process from your application. SecureAuth utilizes native .NET target/redirect authentication methodologies (documented in this Microsoft tech note, titled Forms Authentication Across Applications.)

The key to the solution is to utilize the forms section in target application's web.config to redirect an authenticated user.

SecureAuth is designed to integrate into standard ASP.NET infrastructure, thereby taking advantage of cross-application authentication. SecureAuth can be integrated on the web server that the application resides – or it can be hosted on a separate web server.

Estimated Deployment Time:
1-2 hours by ASP.NET programmer

4. Connect to MultiFactor Web Services

The SecureAuth license includes usage of seamless integration with MultiFactor’s integrated web services, including:

• SMS text messaging service
• Telephony (Speech-to-text) service
• X.509 v3 Certificate service

These services are hosted in MultiFactor Corporation’s high availability, co-located SAS 70 compliant facility. They become a part of the authentication process without requiring additional servers or software. (See figure #6)

Communication between the SecureAuth web component and the web services is established over a secure WSE 3.0 connection. The solution saves the enterprise thousands in maintenance and personnel fees, while providing the functionality needed for the most secure bi-lateral authentication available.

Estimated Deployment Time:

1-2 hours by ASP.NET programmer

Figure 5 – MultiFactor has hosted web services that work seamless with the SecureAuth solution.

Summary:

MultiFactor SecureAuth offers the only non-phishable, tokenless authentication solution that is able to be deployed in less than a day of work.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

MultiFactor Facilitates Secure Cisco IPSec -> Cisco SSL VPN Migration

noreply@blogger.com (MultiFactor Corp) — Tue, 06 May 2008 13:31:00 +0000

"SecureAuth® facilitates a secure transition from Cisco IPSec to SSL VPN"

By Garret Grajek, CISSP
COO, MultiFactor Corp.

One of the vexing issues facing enterprises today – is how to realize the administrative cost savings and increase user functionality of Cisco’s ASA SSL VPN offering. The user advantages of SSL VPN have been documented and discussed, and thus this article will not delve into the “why’s” of SSL VPN deployments.

The key issue, has been, how to implement a solution:

That facilitates the transition TO a “SSL VPN” solution FROM a tradition IPSec-based solution.
Ensures Secure User Authentication in the process – that is port a secure authentication for the present IPSec clients to the new SSL VPN base.
Is deployable to both the enterprise and end user

MultiFactor SecureAuth® provides such a solution.

Step #1 – Original State, Non-X.509 Authentication for the Cisco IPSec VPN

Let’s start with the initial state, Diagram #1, IPSec VPN tunneling via the Cisco IPSec client and a Cisco IPSec supporting appliance (VPN 3000 Concentrator, PIX Firewall, Cisco Routers, etc).

Diagram #1 – Original State: An IPSec User VPN Deployment (Click to Enlarge)

In the original state, the user is deployed with a Cisco IPSec client and is utilizing authentication other than secure X.509 bilateral authentication.

In addition to the authentication being insecure – the organization is also at risk with a “Shared Authentication” key being utilized for encryption. This means that even if the organization is utilizing tokens (hard or soft) for authentication – the encryption is still a mere password – and thus vulnerable to attack. (See Diagram #2)

Diagram #2 - IPSec Client Configured to use a shared “Group Authentication” key (Click to Enlarge)

Step #2 – Secure X.509 Authentication/Encryption to Cisco IPSec via SecureAuth®

The next step in this scenario is to:

Add a Cisco ASA and a MultiFactor SecureAuth appliance into the enterprise
Utilize SecureAuth to enroll users with X.509 Certificates and a new user IPSec profile
Enable X.509 Authentication on the Cisco IPSec appliance with the new certificates and user profiles. (See Diagram #3)

Diagram #3 – Utilizing the Cisco ASA/SecureAuth® solution to distribute X.509 Credentials and new IPSec Profiles. (Click to Enlarge)

In this step, the enterprise deploys new X.509 credentials and new IPSec user profiles via the MultiFactor SecureAuth appliance. One of the advantages here – is that the enterprise, at this time, does not need purchase a large Cisco ASA SSL VPN license – a simple 2 to 25 user license – will suffice. The enterprise simply utilizes the ASA for the deployment of SecureAuth X.509 credentials and new IPSec user profiles.

The MultiFactor SecureAuth® appliance is designed to plug into the enterprise in a matter of hours. The “rocket science” of Certificate creation, SMS Text Messages and Telephony OTPs is handled via secure and world-unique set of MultiFactor-hosted, WSE 3.0 Web Services.

In addition to the user now being secured via valid X.509, bilateral authentication – SecureAuth® also creates a new user profile for the user that utilizing the new X.509 credential. (See Diagram #4.)

Diagram #4 – New User profile deployed by SecureAuth via User-Self enrollment. Note the usage of the X.509 certificate for encryption. (Click to Enlarge)

It is important to note – that the end state of this step – is that the user is now conducting secure bilateral X.509 authentication AND encryption to the Cisco IPSec. This is a vast security improvement over both username/password and one-time-passwords.

Step #3 – SecureAuth X.509 Authentication to the Cisco ASA SSL VPN

In this step the enterprise switches from an IPSec deployment to a full SSL VPN deployment. The same URL that was utilized to deploy the SecureAuth X.509 credential – can now be utilized for the Cisco ASA SSL VPN connection. In addition, the same X.509 credential issued by SecureAuth in Step #2 above, is utilized for the Cisco ASA SSL VPN authentication. (See Diagram #5)

Of course, for the ASA SSL VPN roll-out in this step, a larger Cisco ASA SSL VPN license is needed to handle the concurrent connections. But the advantage is, now users no longer need to have the Cisco IPSec client and profiles on their machines to connect. And because the SSL VPN authentication is through SecureAuth’s secure X.509 registration system, which can utilize both SMS Text Messaging and Telephony OTPs for registration – the enterprise can be assured that the SSL VPN users are verified.

Diagram #5 – SecureAuth X.509 Authentication to the Cisco ASA SSL VPN (Click to Enlarge)

Summary:

Enterprises have been searching for a methodology to migrate from tradition IPSec VPNs to the nimbler and more-user friendly SSL VPN solutions. The SecureAuth authentication system provides this solution that is:

Secure
Deployable
And User and Enterprise “friendly”

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

MultiFactor SecureAuth for Google Apps

noreply@blogger.com (MultiFactor Corp) — Thu, 01 May 2008 05:49:00 +0000

"SecureAuth® can be utilized to established trusted authentication into Google Apps."

By Garret Grajek, CISSP
COO, MultiFactor Corp.

Google has offered enterprises a unique opportunity to reduce the IT cost via the offering of hosted applications, such as messaging, calendaring and document sharing. As with any hosted service, Google Apps introduces a new set of responsibilities associated with a secure establishment of identity to hosted applications.

Fortunately, Google has created a secure “trusted authentication” system via their support of SAML 2.0 for identity establishment. Google Apps has built-in ability to not only redirect the user from Google Apps to the resource holding the credentials (the identity provider) but to also trust the authentication via a cryptographically-strong model – the SAML 2.0 assertion. (See Diagram #1)

Diagram #1 – How Google Apps Accepts a SAML Assertion for authentication
(click to enlarge)

Enterprise Should Take Advantage of Google SAML 2.0 Authentication

The Google ability to accept a SAML 2.0 assertion means that enterprises can:
- Retain the identity credentials of their users
- Provide their own authentication methods

These are both very important concepts in todays regulated IT market. For regulatory measure such as Gramm-Leach-Bliley, PCI DSS and FFIEC, enterprises must not only be able to document that identities are securely retained and administrated – but often that the access to the resource is done is certifiable secure manner. This second regulatory function – is where MultiFactor SecureAuth can greatly help the enterprise.

SecureAuth® Secures Google Apps for the Enterprise

As stated, Google provides the ABILITY for enterprises to keep their own user credentials and to implement their own authentication – but the choice of the authentication tool – is up to the enterprise.

This makes the decision for the enterprise a little more complicated. Not only does the enterprise have to find an authentication solution that solves the issues resulting in Web Authentication, including:

Phishing/Pharming
Key Logger
DNS Attacks
Man-in-the-Middle/Replay

The enterprise must also find a solution that works in Google’s SAML 2.0 authentication model – that is where the authentication solution:

Can be exposed to Google Apps as a URL (See Diagram #2)
Can create a SAML 2.0 Assertion for Google Apps to accept (See Diagram #1)

MultiFactor SecureAuth® for Google Apps is this solution.

Diagram #2: Configuring Google Apps to Utilize SecureAuth® for Authentication (click to enlarge)

SecureAuth® provides the enterprise a solution that:

Is “Exposed” to Google Apps via a public URL
Can create the session ticket needed, after authentication
Connect to the enterprise native user store

This last item is key. Because SecureAuth® connects to the enterprise user store the enterprise has the ability to retain identities “in-house” – and thus put in all the necessary administrative tools and practices in place to meet the relevant regulations (PCI DSS, GLB, FFIEC, etc.) In short, the enterprise keeps the user’s data in place – under “lock and key” – as if the application was in-house.

This is truly the beauty of the federation model and how SecureAuth® integrates. Regulations are pretty much determining that enterprises not only maintain user accounts – but also put in extensive practices to insure their safe keeping. The application itself can be hosted at another site – as long as the enterprise can prove:

The identity credential is securely stored
The session for the authentication/authorization is secured

Because Google Apps has chosen to utilize SAML 2.0 for federation, the 2nd requirement is met. What is left to the enterprise is to insure that the authentication can create a secure SAML ticket and actually authenticates the user in secure manner. MultiFactor SecureAuth meets both of these requirements.

Diagram #3 – MultiFactor SecureAuth Integration into a SAML 2.0 environment. (click to enlarge)

SecureAuth® Enables Minimal Installation Cost

Another important component to the SecureAuth®/Google Apps solution is that the enterprise can achieve advanced functionality (SMS Text Messaging, Telephony OTPs and Certificate distribution) all without installing the infrastructure. This is because the server web plug-in that the enterprise deploys has fully functional and secure WSE 3.0 client stubs to MultiFactor’s webservices that provide these secure services. This saves an immense amount of cost on deploying and maintenance of these services. (See Diagram #4.)

It is important to note – that these web services are only needed during registration of a new browser to a user – subsequent authentications these services are not utilized. (See Diagram #3)

Diagram #4 – MultiFactor SecureAuth® WebServices (click to enlarge)

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth® Authentication and SAML 2.0 Federated Architectures

noreply@blogger.com (MultiFactor Corp) — Fri, 18 Apr 2008 02:27:00 +0000

"SecureAuth® - An Ideal Authentication Solution for the Authentication of SAML 2.0 Federated Architectures."

By Garret Grajek
COO, MultiFactor Corp.

Now that SAML 2.0 Federation is becoming a more common place consideration on how to trust an identity across an intranet and extranet, especially with the introduction of Google Apps - the question is how to authenticate the user for this federation?

There is much confusion in this space - not only on how to federate - but on how to conduct the authentication. For example, some experts on the subject feel that a secure federation should be done by setting up X.509 PKI trust across the federated sites. (Authentication, PKI and SAML by Anil John)

Though Anil made several excellent comments in his blog, including this comment:

"...I consider authorization to be separate and distinct from the authentication."

At MultiFactor we agree strongly with this principal and have sought out and successfully implemented solutions to enterprises, both in the network and application arena, where MultiFactor SecureAuth provides the identity to the enterprise and lets the enterprise authorize the user according to the established roles and permissions.

But there is one aspect which where we disagree with Anil's post. In Anil's article he implies that if a relying party wants to enjoy the security benefits of a PKI, it should install its own PKI accepting infrastructure, namely be able to accept C-SSL certificates.

At MultiFactor we feel that PKI is very compatible to SAML and should be seen as integral component to a secure SAML federated model - not as a replacement. As long as the PKI is done in a easy to deploy manner and used to establish the identity of the user. (See Diagram #1)

Diagram #1 - SecureAuth® integrated into a SAML 2.0 Architecture
(click to enlarge)

This is exactly what MultiFactor has executed in its Google Apps integrations.

In this scenario, a site host MultiFactor SecureAuth® authentication and the original identities to become a trusted IdP (Identity Party) and the Google Apps site is the SP(Service Provider). The authentication is conducting by MultiFactor SecureAuth® with a valid X.509 authentication occurring. (MultiFactor has many patents-pending on the uniqueness of the ability to deploy via WebServices the necessary PKI infrastructure and distribute the X.509 certificates to end users - but for that's for another discussion. See: Diagram #2)

Diagram #2 - SecureAuth® Simplifies X.509 Delivery into a SAML 2.0 Federated Architecture (click to enlarge)

What is germane here is that a valid bi-lateral, X.509 authentication is conducted by an IdP (Identity Party) that is hosting the identities and SecureAuth® for authentication. The IdP in turn, creates a SAML 2.0 assertion which is trusted by the Relying Party - and thus the end user achieves a secure log-on into the target application.

In this model - only the IdP needs to have a trusted PKI "infrstructure" - ideally an easy to deploy SecureAuth® authentication module.

Thus, it is MultiFactor's believe that SAML and PKI (if PKI is deployed simply and manageably via SecureAuth®) are compatible and in fact inseparable in a trusted, scalable, federated environment.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

If You are Using Tokens for IPsec VPNs – Why You are NOT Secure

noreply@blogger.com (MultiFactor Corp) — Mon, 14 Apr 2008 03:18:00 +0000

"Best Practices for IPsec Security is to utilize X.509 cryptography for BOTH the Authentication and Encryption."

By Garret Grajek
COO, MultiFactor Corp.

Common practice for “secured” IPsec VPNs is to :

(a) Issue One-Time-Password “tokens” to users

(b) Encrypt the channel with a “Shared” encryption key

This article will address the problem with (b), creating the encryption key with a “Shared Secret”.

As stated, standard practice is to go through the painful, laborious and unappreciated (by users) task of distributing and maintaining one-time-password tokens to end users. This process, by itself is not trivial – and is fraught with its own set of security issues. (Tokens, by themselves, do not increase the security factor of insuring the end-user is communicating with the appropriate server. They only add a security factor in ensuring the identity of the user. E.g. client side authentication versus mutual, bi-lateral authentication.)

What is not stated by the token-selling community (be it “hard” token or “soft” token”) is that the actual encryption channel is still a “manually” distributed “shared key”. The shared key is often distributed via an easily attackable channel such e-mail, FTP sites and/or a shared document repository. It is this manual process that makes the IPsec channel most vulnerable – that is not the fact that it’s a shared secret – but how the shared secret is distributed.

Once this shared secret is distributed – in most cases - the user manually inputs this “shared key” in the designated spot. (See Diagram #1)Diagram #1 – Shared Key Need for non-Certificate based IPsec encryption

OK, enough FUD. How does one set up a secure VPN channel, where the encryption channel is NOT trivially hacked?

The “best practice” solution is to utilize X.509 public/private key technology. This means distributing a PKI certificate to an end user and setting up the encryption using that certificate.

Now I just lost 90% of the readers, right there, by stating these (2) items need to be done:

1) Distribute a X.509 Public/Private Key

2) Have the end-user create a IPsec profile using the distributed key pair.

But wait – what if there was a system that can automate these (2) practices?

There is. It’s called “MultiFactor SecureAuth® for VPNs”.

MultiFactor SecureAuth® for VPNs has the ability to securely enroll the end-user and distribute the public/private key in a trivial user registration process. The end user receives the certificate after he/she has been securely registered using one of the many SecureAuth® registration methods. (SMS Text Messaging, Telephony One-Time Passwords, E-mail or Static PIN – see diagram #2)

Diagram #2 - Registration with MultiFactor SecureAuth®

Once the user successfully registers, the SecureAuth® client handles the insertion of the public/private key to where the VPN IPsec client can find the key pair. This key pair is stored, in the browsers natives key store (IE uses Microsoft key store, FireFox utilizes NSS keystore, and Apple Safari utilizes Apple KeyChain.)

But to truly make the process secure – we have to contend with informing the IPsec client how to create the encryption channel – with the X.509 key pair that was just created. Once again, MultiFactorSecureAuth® automatically handles this process – by creating a user profile that uses the key to create the encrypted channel.

Let me repeat, the MultiFactor SecureAuth® product, when the user successfully conducts a user-self-registration creates a Private-Public key pair AND an IPsec profile that automatically uses this key par. (Diagrams #3 and #4).

Thus, MultiFactor SecureAuth® both the two-sided coin of VPN authentication : authentication and encryption.

Diagram # 3 – SecureAuth® automatically creates a user profile

Diagram # 4 – And the Profile is set to use the user ‘s SecureAuth® Certificate.--

Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth™ Makes Tokens Obsolete for VPNs - with Web-Configurable Expirable Certificates

noreply@blogger.com (MultiFactor Corp) — Thu, 27 Mar 2008 02:10:00 +0000

MultiFactor SecureAuth's Configurable Expiration Security Tokens Enables Easier Deployment of VPN Authentication.

By Garret Grajek
COO, MultiFactor Corp.

One of the main pushbacks for VPN utilization of certificates has been the fear of leaving valid identity credentials (e.g., X.509 certificates) “behind” after a user utilizes a non-corporate machine.

In the real world this means:

“How does an enterprise grant a security credential to a VPN user when he is on a shared machine at an airport or on his brother-in-law’s laptop?”

Enterprises have for these purposes, been forced to deploy cumbersome and expensive solutions like hard tokens. (E.G., RSA SecureID and Vasco, VersiSign and other token-based solutions). At least with these solutions, the argument goes, nothing is left behind on the computer. The fact that these tokens are expensive, hard to deploy and an irritant to end-users, was, before now, just a pain that enterprises felt they had to swallow.

The day of “tolerating” this token pain is over.

MultiFactor has not only released a new version of SecureAuth™ that makes the certificate length as short as an hour – but has created a methodology to deploy these certificates to non-corporate assets.

The latest version of SecureAuth™ , 4.1, allows an enterprise to configure MultiFactor SecureAuth™ for (2) distinct lengths of certificates (See Diagram #1):

Long Term Certificate (2 days - 10 Years)
Short Term Certificate (1 hour - 48 hours)

Diagram #1 (Click on Image to Enlarge)

Not only is the ability to configure (2) lengths of certificates, unique – but it is the ease of implementation where MultiFactor SecureAuth™ also sets itself apart. SecureAuth™ exposes to the administrators a web GUI that allows an enterprise to configure:

- Which Registration Methods to utilize:

SMS
Telephony
E-mail
Static Pin

Which Directory to utilize for data storage/retrieval
What informational messages to utilize
Company logo and other “look-feel” options

Now in addition to these settings, an admin, with the click of his mouse, can choose the length of both short term and long term certificates. This is done with a simple web GUI administration to the SecureAuth appliance installed on site. (See Diagram #2)

Diagram #2

No configuration of the certificate servers is needed – THUS no specialized personnel are required to administrate the validity period of the SecureAuth authentication "token". (Try doing that with a hard token!)

The admin can choose the certificate to have an expiration of down to (1) hour. (See Diagrams #3 and Diagram #4)

<-Diagram #3
Diagram #4 ->
(Click on Image to enlarge)

Because this is configured by the admin at the enterprise, the user simply has to choose whether he will or will not be using the computer again. If the user will be using the computer again – he/she simply checks the:

__ “Click here if you will be using the computer again”

If the user chooses NOT to click this option, he/she is issued a short term certificate. (See Diagram #5)

Diagram #5 (Click on image to enlarge)

In summary, SecureAuth™ is a technological breakthrough where, now, enterprises can deploy secure, non-phishable, bi-lateral authentication that can be utilized on both corporate assets and non-corporate assets (kiosks).

Thus, there is no reason to deploy expensive and user-antagonizing one-time-tokens to end users – the new solution is here – SecureAuth™ for VPN and application authentication.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

SecureAuth™ Secures Reported "Phishing" Weakness in Safari Browser

noreply@blogger.com (MultiFactor Corp) — Mon, 17 Mar 2008 18:04:00 +0000

"Phishing" Inspection Automated by SecureAuth™ in Safari and other browsers, by Garret Grajek CISSP

In February 2008, PayPal released a list of recommended browsers for interaction with their e-commerce sites. (Source: Michael Barrett, PayPal’s Chief Information Security Officer).

PayPal notes lack of Safari support for a “builit-in” anti-phishing filter and lack of support for Extended Validation (EV) Certificates. These anti-phishing mechanisms are supported in browsers such as Microsoft's IE7 and IE8 and FireFox 2.0 and 3.0. The Extended Validation (EV) certificate mechanism is a web browser technology that turns the address bar green when the browser is legitimate Web Site.

It is important to note that both of these browser-based functionalities are designed to further educate and inform the user of a possible malicious hacker site “posing” as the legitimate SSL protected "target" site. PayPal accurately states that the Safari browser does not include these features.

It should be noted that neither the newer versions of IE (7.0 and 8.0) and FireFox (2.0 and 3.0) stop the user from progressing with the transaction. The user is simply given more information that the site appears to have technical incongruencies that could indicate a hacker site. E.G., the user informed - but still can proceed. (And often does - see the Microsoft/Standford study sited below.)

MultiFactor’s SecureAuth™ product, a webserver based software product that can be installed and utilized by e-commerce sites on their webservers, is designed to AUTOMATE this inspection. In fact in an authentication validated by SecureAuth™, the issue of education and improper usage is removed from the user via an automated process. SecureAuth™ by MultiFactor, includes a browser extension for Safari that automates the inspection of the endpoint. A bi-lateral key exchange is conducted by SecureAuth, between the legitimate web server and the end user. If a hacker site attempts to “phish” the user via a man-in-the-middle attack or some other replay mechanism – the authentication is automatically flagged by SecureAuth™ and the session is dropped. (See Diagram #1)Diagram #1 – SecureAuth™ Server and Web Components identify and automatically mitigate Man-In-the-Middle and other Identity theft attacks.

It is important to note that the SecureAuth™ plug-in, available to Safari users, provides a more secure internet e-commerce authentication than other browsers – regardless of their support of the “Anti-Phishing” bar or EV certificates. SecureAuth™ conducts the e-commerce authentication automatically and validates the bi-lateral session – without user knowledge or training.

SecureAuth™ also supports IE and FireFox browsers – thus users on all platforms can achieve this level of site validation – if the enterprise is wise enough to deploy MultiFactor SecureAuth™ for authentication.

NOTE:

It is important to note studies have shown that most browser “user education” mechanisms provide little to no value in the fight against on-line fraud. A study conducted by Stanford University and Microsoft revealed users, even after browser education, were still likely to judge all sites legitimate – regardless of whether the sites were fraudulent.

---------------
Garret Grajek is the president and founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

noreply@blogger.com (MultiFactor Corp) — Thu, 13 Mar 2008 20:38:00 +0000

MultiFactor SecureAuth Mitigates "Account Lockout Attacks" by Garret Grajek, CISSP

A re-occurring theme in discussions is how to address not only phishing and identity theft, but "Account lockout"

In short, this is the issue of malicious users or processes intentionally attempting false logons w/ invalid passwords to block out legitimate users.

(The topic is covered in depth by Michael Coates blog titled, "Distributed Account Lockout Attack"

"The old attack would involve a single user who wanted to lockout another individual or group of individuals by entering multiple unsuccessful passwords. The goal isn’t to guess the password, but to lock the account by sending multiple unsuccessful login attempts. Now, if this user was particularly malicious he could try to enumerate all of the usernames for an online system and then use a script to lock out all of the users.")

This attack is certainly a problem for authentication sites that utilize standard username/password authentication with a "failed logon attempts" check mechanism. The MultiFactor SecureAuth product addresses this type of attack.

In a scenario where the SecureAuth solution is utilized, the legitimate user or attacker is never even prompted for the password unless the user first can input:

a) A set of non-phishable, non-exportable SecureAuth browser credentials (Image #1)

(Image #1)

b) The user had first registered the browser, in a Secure out-of-band method (Image #2 and Image #3):

- Telephony (Cell Phone or Land) One-Time-Password (OTP)

- SMS Text Message OTP

- E-mail OTP

(Image #2)

(Image #3)

In effect, only a user that has establish a reasonable set of "credibility" is even allowed to input a browser. (E.G., be in possession of the user's cell or land line or have access to a non-exportable key on the user's browser.) Neither a hacker nor an automated bot - would meet this criteria.

Thus by deploying SecureAuth, an enterprise takes a large step in mitigating "Account Lockout Attack".

We encourage all security analysts and security professionals to run the demo on our public site:

http://www.multifa.com/demo.htm

---------------
Garret Grajek is the president and co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

noreply@blogger.com (MultiFactor Corp) — Wed, 12 Mar 2008 23:47:00 +0000

Beyond Standard Perimeter (FW-UTM-IDS-IPS) Security

Garret Grajek, CISSP
01-28-08
President and Chief Operating Officer
MultiFactor Corporation
http://www.multifa.com/

An issue that is not being addressed by traditional “fw-utm-ids-ips” infrastructure is identity theft and specifically identity theft that occurs in transit to the target application or resource.
This type of identity theft is characterized by a man-in-the-middle or replay attack. These attacks often utilize simple reverse proxies to “replay” the credential information to a particular web site or network resource.(Diagram 1) In this manner, the attacker does not have to build an elaborate web site or network page to create the “look-feel” of the target site – the proxy does the work for him.

Diagram #1

Traditional firewalls and/or IDS systems cannot trace or detect these types of attacks. The attacker is utilizing valid credentials to enter into the system resource. (Thus a standard signature or anomaly-based detection system will not detect this type of intrusion.)

These attacks are perpetrated by luring the end user to a different web or network resource than the legitimate target and then redirecting to the legitimate target, but with the sessioning information now replayed by the attacker. In this manner the attacker now has “hijacked” the session and can digest and modify the session in whatever method he wishes to utilize the communication. Often the session itself can be held and then replayed, with the attacker himself starting a new request; masquerading the identity of the originator.

The attacker lures the user to the attacker site through commonly used attacker methodologies, including mass-e-mail phishing attacks, DNS attacks… host file attacks and Trojans planted on the end users device. The commonality of all the attacks is that the user is directed to the attacker’s site with the user believing he/she is being directed to the legitimate target.

It is important to note that standard one-time-passwords, such as RSA, VeriSign or Vasco tokens do NOT solve this problem. These one-time-token codes can be replayed just as easily as a static password. (The 60 second time-out is a lifetime in today’s internet speeds.)

What is needed to protect against these attacks is a system or methodology that forces the end user to verify that the network device or the web server is the legitimate target. This is known as bi-lateral or mutual authentication. That is – it’s not enough for the user to authenticate to the site, but the site needs to authenticate to the end user.

Initially this type of 2-way authentication was supposed to be conducted by a public-key-infrastructure (PKI) system.(Diagram 2) In this scenario, the end user has a certificate that is chained to a root CA who also has issued a certificate to the destination host or network device. In this manner, the end system is validated by the 2-way trust system before the user conducts a transaction – thus mitigating the man-in-the-middle attack.

Diagram #2

The difficulty in this solution has been the delivery/storage/manageability of the certificate to the end user. These difficulties have been met by the Multi-Factor Authentication SecureAuth™ system (Diagram 3) which uses a patent-pending unique blend of:

· Off-site hosted web services
· Telephony/SMS out-of-band registration services
· Deployable client side certificate verification modules for the server side
· Light-weight client side certificate storage/retrieval modules

All deployed in a manner that does not use CRLs (Certificate Revocation List) or an Online Certificate Status Protocol (OCSP) infrastructure, which traditionally has been an obstacle to these solutions.)

Diagram #3

In summary, the Multi-Factor Authentication SecureAuth authentication system provides the bi-lateral authentication needed by enterprises today to thwart man-in-the-middle identity theft attacks. These attacks are not mitigated, today by the standard “fw-utm-ids-ips” security infrastructure, and can only be secured with an authentication system such as Multi-Factor Authentication’s SecureAuth.

(Garret Grajek is a certified security engineer and co-founder of MultiFactor Corporation, http://www.multifa.com/)

Please join the conversation at the MultiFactor discussion group.