Q: What was stolen from RSA? (based on Art Coviello's blog) and What is the current risk for SecurID users?
A: RSA says "..extracted information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation..." This is boiling water and everybody is trying to reverse engineer this statement.. What does RSA mean by reduced effectiveness? Without the full disclosure, all interpretations will be semi fictional.. Information sources are limited when RSA is silent. A very important sign of RSA's response is "RSA SecurID Authentication Engine Security Best Practices Guide" document which was published in March 17.
Here are the 2 interesting statements from the March 17 Guide:
1 - "RSA recommends a defense-in-depth approach for protecting token data stored in your environment. RSA strongly recommends that your storage systems encrypt the token data with a separate key in addition to the encryption provided by RSA SecurID Authentication Engine. Using two separate keys maximizes the protection of stored token data."
My interpretation: Do not trust RSA authentication server's built-in encryption, use yours.This means 3rd party who "extracted information from RSA" has a good understanding of how RSA obscures token data on the authentication server...It is usually possible to access stored encryption keys since they have to be accessed for operation anyway. So if source code is lost, this may happen faster..Risk: You had to secure auth server anyway, now the risks are higher but this specific risk does not require you to replace every single token in the field until your own auth server is hacked.. And believe me when your authentication server is hacked you have other serious problems as well (BTW I'am not sure how auth server will work if I encrypt token data with my keys at file level)
2- "Never give the token serial number, PIN, tokencode, token, passcode or passwords to anyone."
My interpretation: Let's analyze this one in-depth.. When you use SecurID, you enter passcode as your password. A passcode is made up 2 pieces on RSA, a pseudo-number (that is dynamically generated on the token a.k.a. tokencode) and your PIN..
The beauty of multi-factor dynamic password tokens is that if I know your PIN I still need the tokencode (so the token).. If I steal your token, I still need the PIN... No attacks are effective until you get token for that specific 60 seconds+PIN combo.(in theory ; ).... The scary part of the warning above is the "token serial number", a number on the back of the token usually used as a subfactor for enrollment and password resets... Directly losing ""token serial number" shouldn't have mattered . if it did, it was not supposed to be imprinted on the back of the token..So the hypothetical risk is that the guys who extracted data from RSA can generate a tokencode from the serial number.. I do not think this is the possibility since that eliminates the whole idea for the need for the token seeds..Hopefully RSA token's private algos are not that simple (serial number generates the seed). Same argument is valid for tokencodes.. If I have to hide my tokencode where is the advantage of using a dynamic code generator?
 |
| Back Image with Token Serial Number |
I will keep covering this topic until we have a conclusive answer.