For those of us already waiting for the latest update on guidance from the FFIEC on Internet Authentication, the news of the recent RSA SecurID breach complicates things a bit. One-time password (OTP) hardware devices (tokens and smartcards) are considered one of the most secure forms of the “something you have” element in complying with the multifactor authentication requirement. So let’s take a look at the RSA breach in the context of authentication guidance, and what you should do to respond.
When the FFIEC released its original guidance on Internet Authentication in 2005, they said this about tokens:
Password-generating tokens are secure because of the time-sensitive, synchronized nature of the authentication. The randomness, unpredictability, and uniqueness of the OTPs substantially increase the difficulty of a cyber thief capturing and using OTPs gained from keyboard logging.
And 6 years later, in the draft release of the FFIEC updated guidance, they said:
“OTP tokens have been used for several years and have been considered to be one of the stronger authentication technologies in use.”
And they are correct; in the last few years OTP tokens for authentication have proven to be very secure and have become very popular, and arguably the biggest player in that market is RSA. There are millions of RSA SecurID tokens in use today, many of them in financial institutions, and many of those authenticating Internet based financial transactions…perhaps for your customers.
So what exactly happened? Well, their Website is (strangely) completely silent on the event, and RSA customers I’ve spoken to say that information is slow coming to them, and extremely vague when it does, but according to what has been disclosed by the RSA, here is what we do know:
“…the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.”
So…according to the FFIEC, the security of the OTP is based on “randomness, unpredictability, and uniqueness”, but we don’t know if the “certain information” mentioned by the RSA included the main algorithm or some other critical information necessary to generate the OTP.
As a financial institution responsible (and liable) for the security of your customers’ Internet based transactions, you must err on the side of caution here if you utilize RSA tokens. I’ve got to believe that RSA will do the right thing here, and place their customer’s security ahead of their own business interests, but in the meantime it may be prudent to consider some additional measures, such as:
- Since multi-factor authentication relies on “something you know” in addition to “something you have”, encourage (require?) your customers to change their user names and passwords.
- Review (and possibly temporarily adjust) your built-in transaction monitoring metrics, such as dollar volumes, transaction frequency, ACH / Wire recipient lists, etc.
- Implement “Out-of-Band” confirmation for all high-risk transactions. In other words, temporarily require all transactions to be confirmed via a return phone call, fax, SMS, or similar method.
- Make sure your customers know exactly who they can contact if they suspect unauthorized activity, and most importantly, let them know under what circumstances (and what methods) you will contact them.
- Finally, consider an alternate token vendor. You may be at the mercy of your on-line banking software vendor on this, but there are 2 trust issues in jeopardy here…the one between you (or your vendor) and the RSA, and the much more important one between you and your customer. RSA may be able to fix whatever problems allowed the breach, and thereby repair the trust (or not) with their customers (your vendor), but the trust issue with your customers may not be repairable. Rightly or not, they may be reluctant to use anything with “RSA” printed on it.
All of these items (except the last) are best practices anyway, but the key is that you must be pro-active on this. Do not wait for RSA to release all the details (we may never know them anyway), because what we do know now is enough to justify additional security measures.
In conclusion, tokens and OTPs are still very effective as one element in one layer of a multi-layer, multi-factor, authentication process, but clearly the lesson here is that there is no fool-proof method. Indeed as we await the FFIEC update, this line from the draft release is almost prophetic:
“Since virtually every authentication technique can be compromised, financial institutions should not rely on any one authentication method or security technique in authorizing high risk transactions, but rather institute a system of layered security.”
Perhaps the only change necessary to that statement in the final release is to remove the word “virtually”.
