FFIEC & Regulatory Recommendations


How does PhishCops® work?

FDIC & FFIEC Findings and Recommendations


Recommendation #1. Implement Multi-Factor Authentication (see: clarification re: "challenge question" / response approaches)
Recommendation #2. Implement Website Authentication
Recommendation #3. Limit the Use of Personal Information used in Authentication
Recommendation #4. Implement authentication methods which "cannot be collected by fraudsters"
Recommendation #5  Any considered approach should SPECIFICALLY address the risks of phishing, pharming, and malware

Industry & Government Recognition

Recommendation #1   Implement Multi-Factor Authentication



On Dec 14, 2004, the U.S. Federal Deposit Insurance Corporation (the FDIC) published a report presenting their findings on how the financial industry and its regulators could mitigate the risks associated with Phishing. In this study, the FDIC identified root causes for the problem of phishing.

    "User authentication by the financial services industry for remote customer access is insufficiently strong....the FDIC is of the opinion that financial institutions and government should consider a number of steps to reduce online fraud, including: Upgrading existing password-based single-factor customer authentication systems to two-factor authentication."


On October 12, 2005, the Federal Financial Institutions Examination Council (FFIEC) issued an updated guidance letter for banks and financial institutions which echoed the FDIC’s findings and made the following recommendation:

    "The agencies consider single-factor authentication, as the only control mechanism, to be inadequate...financial institutions should implement multifactor authentication"

Multi-factor Authentication Defined

The FFIEC defined multi-factor authentication thus:

    "Existing authentication methodologies involve three basic “factors”:

    • Something the user knows (e.g., password, PIN);
    • Something the user has (e.g., ATM card, smart card); and
    • Something the user is (e.g., biometric characteristic, such as a fingerprint).

    Authentication methods that depend on
    more than one factor are more difficult to compromise than single-factor methods."  (FFIEC) 

Multi-factor authentication is exactly what it sounds like. Instead of using only one type of authentication factor, such as only things a user KNOWS (login IDs, passwords, secret images, shared secrets, personal information, etc), two-factor authentication requires the addition of another factor, the addition of something the user HAS or something the user IS.

Two-factor authentication is not a new concept. You use two-factor authentication every time you visit your local ATM machine. One authentication factor is the physical ATM card you slide into the machine. The second factor is the PIN number you enter. Without both, authentication cannot take place. This scenario illustrates the basic parts of most multi-factor authentication systems; the "something you have" + "something you know" concept:

In their reports, the FDIC and the FFIEC defined multi-factor authentication as COMBINING "more than one factor". The FFIEC clarified this again in their August 15, 2006 FAQ Supplement:

    "By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category ... would not constitute multifactor authentication."

Challenge Question / Response Approach, by itself, is Insufficient
By the FFIEC's definition, multiple instances of the same type of authentication factor (i.e. multiple instances of "something you KNOW") would "not constitute multifactor authentication", even if they are used at different points in the authentication process. Using the customer's Login ID to lookup additional challenge questions (i.e. simply more of what the user "knows") "would not constitute multifactor authentication":

By the FFIEC's definition, equipping SOME customers with one authentication factor while equipping the REST of the customers with another authentication factor would also not constitute multifactor authentication since each customer would still be using only ONE type of authentication (one authentication factor):

The PhishCops® Advantage
PhishCops® follows the FFIEC's definition of multi-factor. PhishCops® users supply something they KNOW (their regular Login ID and Password), combined with something they HAVE (their internet-connected computer, PDA, web-enabled phone, or similar device).

PhishCops® converts the user's internet-connected device into a "virtual" token generator WITHOUT requiring the user to install any software or carry any hardware. The PhishCops® virtual token generator contains programming, but the programming resides on the organization's web server.  Only one key element remains on the user's computer. Without both parts, the programming is incomplete and the virtual token generator will not work, but when both parts are combined, the user has a complete token generator at their fingertips.

This patent-pending approach permits PhishCops® users to use their own personal computers as a virtual token generator, WITHOUT installing any software and WITHOUT carrying any additional hardware.



Recommendation #2   Implement Website Authentication

Multi-factor authentication is uni-directional, meaning users authenticate themselves to the website using "more than one factor".  As a result, multi-factor authentication alone will not prevent phishing (which results from a website's inability to authenticate itself back to the user). Even if an organization added 100 additional authentication factors to their login process, it would not prevent phishing. To prevent phishing, some form of "Website Authentication" is also recommended.

In their report, the FDIC identified a second root cause for the problem of phishing:

    "the internet lacks e-mail and website authentication"


In their guidance letter, the FFIEC also noted the lack of website authentication as a root cause of phishing and recommended financial institutions authenticate their web sites to their customers:

    "Currently, most financial institutions do not authenticate their Web sites to the customer before collecting sensitive information. One reason phishing attacks are successful is that unsuspecting customers cannot determine they are being directed to spoofed Web sites during the collection stage of an attack. The spoofed sites are so well constructed that casual users cannot tell they are not legitimate. Financial institutions can aid customers in differentiating legitimate sites from spoofed sites by authenticating their Web site to the customer."



Website Authentication Defined
Website authentication is a process where the Website proves to the user that it (the website) is genuine:


Most authentication approaches either fail to authenticate the website to the customer at all, or they resort to "shared secret" approaches, relying on weak images, watermarks, and pass phrases.  Associating an image, audio, or some other shared-secret information with a user's website account, and then presenting this secret back to the user during login, is one of the WEAKEST forms of website authentication.  The FDIC and the FFIEC have both commented on the vulnerability of shared-secret approaches to "man-in-the-middle" attacks, phishing, and malware. Symantec, CR-Labs, and numerous security experts have also issued public statements repudiating "shared secret" approaches for their weakness and vulnerability. Phishers can and do discover shared secrets with ease, using social engineering techniques, botnets, keylogging trojans, screen scraping, and many other methods.

REAL website authentication must use strong authentication techniques and must use them in a way that phishers cannot compromise.

The PhishCops® Advantage
PhishCops® doesn't resort to obscure filtering techniques, questionable "risk analysis", vulnerable public records, or replicatable images and watermarks. PhishCops® uses an unique patent-pending implementation of unbreakable mathematic authentication algorithms developed by the National Institute of Standards and Technology (NIST) and the Information Technology Laboratory (ITL) under the authority of the U.S. Department of Commerce.  



Recommendation #3   Limit the Use of Personal Information used in Authentication



Many authentication methods today resort to soliciting personal information from consumers in response to challenge questions.

One of the problems associated with such approaches is the simple fact that consumers do not wish to divulge their personal information.  After all, the whole point of the above authentication guidelines is to protect consumer privacy, not require consumers to disclose yet more personal information. In addition, such approaches are inherently weak. Anything a consumer KNOWS can be solicited by fraudsters on phishing websites as easily as it can be solicited by the genuine financial institution.



On Jun 17, 2005, the U.S. Federal Deposit Insurance Corporation (the FDIC) published a supplement to its earlier report in which it repeatedly cautioned financial organizations against adopting authentication methods that use personal information in the authentication process:

    "Although consumers are worried about phishing and the trustworthiness of e-mail messages from their banks, they are also concerned about the security of their personal information more generally."

    "When banks consider authentication methods for retail customers, they should be aware that these customers value security and the
    protection of confidential information... Consumers will require a clear explanation of any security mechanism and the use of any personal information required to implement that security mechanism."

    limitations on the use of personal information and the existence of privacy safeguards are important elements of consumer acceptance."

    "Consumers are also concerned about the risk associated with large databases of personal information and the potential for the information that is used by authentication methods to be compromised, copied, or imitated."


Many authentication vendors solicit personal information from consumers in the form of challenge questions. Unfortunately, fraudsters are soliciting the same information. Consumers are becoming increasingly uncomfortable with disclosing their personal information online for this very reason. "What is your mother's maiden name?"... "What are the last four digits of your social security number?"... "What is your account number?"... It sounds like a recipe for an account hijacking nightmare and consumers know it.  

Bank of America's Unhappy Experience
Bank of America reported fully 96% if its customers refused to sign up for Passmark Sitekey, another approach using solicited personal information, until the bank made it mandatory. Following its implementation, support calls to BofA's customer service lines increased by 25% and customers began venting their anger on a number of blogs and websites about SiteKey's requirement that they disclose their personal information in order to access their online accounts. Read more here.

State and Federal Regulators Weigh In
Because solicited personal information approaches to authentication are so widely mimicked by fraudsters to compromise consumer privacy, many states now strictly regulate, or even prohibit, the open solicitation of consumer personal information on commercial websites.  The FDIC has even supplemented its earlier guidance to specifically warn against the use of solicited personal information for authentication, citing its inherent weakness and growing unpopularity with consumers. In addition, the FFIEC has clarified that, simply soliciting MORE personal information from consumers does not meet its definition of "multi-factor" authentication.

The PhishCops® Advantage
PhishCops® does not use any personal information during authentication. During authentication, PhishCops® retrieves digital signature and key information from the user's computer and validates this against the user's connected device, satisfying the FFIEC's "what you have" factor.



Recommendation #4   Implement authentication methods which "cannot be collected by fraudsters"



In their supplement the FDIC also urged financial institutions to adopt authentication methods which "cannot be collected by fraudsters":

    "In the last stage, collected credentials are used to access the victim’s account. Financial institutions can mitigate this threat with a variety of tools to better identify who is accessing the account. This includes authentication methods which cannot be collected by the fraudster."

One of the problems with traditional authentication approaches is their reliance on user-supplied credentials and other information which can be collected and re-used by fraudsters. With traditional shared secret approaches, for example, 100% of the personal information (login IDs, passwords, "mother's maiden names", etc.) that is solicited by the genuine website can also be solicited by a phishing website.

With traditional hardware tokens, for example, anyone who steals the hardware device can use it.  Phishers can also trick hardware token owners into divulging their token values, which they can then supply to a waiting website. For a real world example of this vulnerability, read about Nordea Bank's experience here.

With software and client-side digital certificate approaches, for example, malware and other spyware programs can steal the codes and other information stored on the client-side computer and transmit these to fraudsters for re-use on their computer. 

The PhishCops® Advantage
With the PhishCops® "virtual" token process, there is nothing to be "collected" by fraudsters which can be re-used.  

The PhishCops virtual token generator itself exists "virtually" as "server-side" programming and cannot be lost or stolen.  This virtual token generator produces a unique type of one-time password similar to traditional hardware-based token approaches, but the PhishCops® virtual token is unique because this code is produced using machine-supplied keys which cannot easily be "collected by fraudsters".



Recommendation #5  Any considered approach should SPECIFICALLY address the risks of phishing, pharming, and malware


In their August 15, 2006 FAQ Supplement, the FFIEC states any considered solution should SPECIFICALLY address the risks of phishing, pharming, and malware:

    Q-5- Should the risk assessment specifically consider the risks of phishing, pharming, and malware?
    A-5- Yes, these are some of the vulnerabilities that are specifically mentioned in the guidance. 

The FFIEC and the FDIC have clarified in their guidance that, to mitigate phishing, website authentication is needed.  The FFIEC stated it in their original guidance letter this way:

    "Currently, most financial institutions do not authenticate their Web sites to the customer before collecting sensitive information. One reason phishing attacks are successful is that unsuspecting customers cannot determine they are being directed to spoofed Web sites during the collection stage of an attack. The spoofed sites are so well constructed that casual users cannot tell they are not legitimate. Financial institutions can aid customers in differentiating legitimate sites from spoofed sites by authenticating their Web site to the customer."

This echoes earlier guidance on this subject in the FDIC's report, when they identified one of the two root causes of phishing as being this lack of "website authentication".  (see Recommendation #2 above).

Hardware Tokens
Hardware tokens, smartcards, and other hardware approaches are incapable of mitigating phishing because they are physically disconnected from the internet. They are designed to authenticate USERS to websites, not websites to users. For recent examples of the inability of hardware tokens and similar hardware OTP approaches to mitigate phishing, and for a side-by-side comparison against PhishCops
, click here.

Software and Shared Secret Solutions
Challenge / Response approaches such as those employed by Passmark (RSA) Sitekey, Cyota, Business Signatures, and Digital Resolve are equally incapable of addressing these risks.  For example,
Passmark SiteKey CTO Louie Gasparini confirmed in an interview that a "big hole" in the Sitekey approach was its vulnerability to malware, trojans, viruses or worms. Said Gasparini, “If malware is on your machine, it's much more difficult for everybody.”

The PhishCops® Advantage
To address the risks of phishing, pharming, and malware is the reason PhishCops® exists. It is the reason it is named "PhishCops®". PhishCops® was SPECIFICALLY designed to deal with the issues of phishing, pharming, and malware from its inception.  Indeed, the United States government has recognized PhishCops® for its success in this area, twice naming it a semi-finalist for the Homeland Security Award.



Industry & Government Recognition

Real Authentication

#1 among competitive solutions for overall affordability, ease of deployment, and support





PhishCops® uses only traditional HTML and server-scripting to facilitate the entire authentication process. PhishCops® is hardware and software free. Our freedom from traditional hardware and software constraints means PhishCops® can be deployed in only minutes by any competent webmaster and requires only minimal support.

PhishCops® was recently rated #1 among competitive solutions for overall affordability, ease of deployment, and support. Read more here.

The U.S. government has twice named PhishCops® a semi-finalist for the Homeland Security Award. You may read the official press release here

PhishCops® also received InfoWorld's highest honor, the InfoWorld 100 Award for the "best use of technology to meet business goals".

Global Solution

PhishCops® can be implemented on EVERY website in the world and used by EVERY internet user in the world. It doesn't matter what server a website may be running on, and it doesn't matter what computers or browsers their customers may be using. "If they can get to the internet, they can use PhishCops®".

Future Supportability

10 years from now, when server architecture and computer operating systems have changed, other solutions will need to be upgraded. Not PhishCops®. As long as the internet continues to run, PhishCops® will continue to work.

You can compare PhishCops® with other authentication solutions here.
For a side-by-side comparison of traditional hardware tokens against PhishCops"virtual" tokens click here.



Home   |   Sitemap   |   Contact Us   |   Print this Page   |   Search 
© 2008 Sestus Data Company   All Rights Reserved. PhishCops® is Patent Pending.

Toll Free Tel. (800) 788-1927
California (San Francisco) Tel. (415) 963-4124    |   New York (Manhattan) Tel. (718) 841-7350