EYEdentityOnline.com

In my humble, but accurate opinion, the answer to the question posed in the subject line is… Yes. Definite oxymoron and no, I’m not calling you names, gentle reader.

That nice Michael Berman fella over at Grok Security posted up my response from last week on his web site (basically the content from my last post if you want to go get caught up), but dangled a question at the end in regard to TriCipher’s ID Tool To Go: “If I insert my USB key into an 0wned system, can that system rip the token from the key and log my password?”. You gotta know I can’t leave such a tantalizing question alone. Heck, there’s a whole bunch of ideas this question kicks the door open onto. So here goes:

This question comes up in probably 90% of all discussions of strong authentication for wide consumer use. Why? First, I think that the TriCipher story is so strong, that people want to poke holes in it and this “mythical gotcha” scenario is expected to stop me in my vendor tracks and bring me to my knees begging forgiveness for my arrogance. Second and less cynically, it isn’t so mythical and I would counsel you the same as I do my friends and family… Don’t use kiosks to do anything you wouldn’t want to print out and leave lying at the workstation when you are done, including the contents of every field, screen, transaction, etc. Actually, I generally shorten this advice to: don’t use kiosks, period. Need to do some banking find an ATM “kiosk” or call your bank. Ditto for your broker, airline, etc. You walk into an internet cafe where folks have been playing World of Warcraft and drinking Bawls all day and log into your bank, you kinda nearly deserve what’s comin’.

Why do I then refer to this case as “mythical”? Because though this is a valid concern at a kiosk, in truth there is nothing that can protect someone on an “0wned” kiosk PC. For argument’s sake, let us attach a retina scanner to the kiosk for biometric authentication. Does this make the user on an “0wned” machine secure? No, the attacker merely waits for you to authenticate and then gathers all the data they need and hijacks the session for their own purposes. In another example, there are challenge response mechanisms using detached cards and card readers such as the EMV CAP systems in minimal deployment in Europe that can adequately protect a transaction, but not all of the data in the session or even every conceivable session “transaction”.

So now like a good magician having distracted you with my off-hand, I’ll answer Michael’s question . Yes, just as an owned system can thwart invasive biometrics and expensive out-of-band challenge response schemes or even smart card deployment, an owned system could rip the pertinent contents off the USB housing our ID Tool To Go and of course keylog the password. However, bear in mind that as with all TriCipher 2-factor deployments of which ID Tool To Go is only one, we offer a range of other powerful functions to protect users and their credentials. I’ll try to be brief (yet having reread this, I fail… just a heads up):

Kiosk mode: Yep, we actually take into account the kiosk situation from a couple of angles. Primarily, in many kiosk situations you can’t attach a USB or other device and can’t run applications that aren’t already installed. We permit issuers and relying parties the ability to allow users to login with only their password and either, a) limit the user’s rights so that an owned system would then not have a fully privileged credential to perform costly mischief or, b) use one of our secondary authentication mechanisms to gain a second factor.

Secondary authentication: These are useful for a wide variety of situations ranging from password resets to device registration when “roaming” to a new PC to standing in as an alternate 2nd factor in Kiosk Mode. Of course the typical Q&A scenario (KBA, knowledge based authentication) is supported as is out of band SMS, e-mail and various challenge response scripts using the user’s telephone (typically mobile phone of course).

Key “rolling”: An approach to make theft of the portable device contents as difficult as possible is to change the pertinent bits on the removable device at every login. What does this buy you? Two scenarios: 1) The attacker copies the device, but the victim logs in again before the attacker. The attacker has an out of date set of bits that are useless to him and thus, thwarted. 2) The attacker logs in before the victim next logs in. The victim is apprised that their device is out of synch and that they should take immediate action with the issuer to revoke the credential and investigate for fraud. To our knowledge, this makes this solution the only proactive notification of possible credential compromise available on the market of any kind, let alone in the digital certificate-based credential space.

Last, bear in mind that the ID Tool To Go is just one of many 2-factor mechanisms all served up from a single, centrally deployed and managed system. The end-user has a powerful, fully functional digital certificate-based credential enabling powerful, true, two-way, mutual SSL authentication in a convenient, multi-use form-factor and all for pennies on the dollar of other traditional OTP and smart-card players such as RSA, Verisign, ActivCard, Entrust, etc.

Is ID Tool To Go perfectly invulnerable? No, it is just one of many TriCipher multi-factor form-factors running within the matrix of security vs. cost vs. usability.

Thanks to Michael Berman over at Grok Computer Security for the mention Friday, following the announcement of ID Tool ToGo. Also a nice article over at Dark Reading “Authentication Goes USB Route“.

I thought I’d respond here to Michael Berman’s comments and provide a couple confirmations and clarifications:

Yes, we use two authentication “stores”. In the TriCipher solution (our name alludes to our 3-key technology) set, we use public key crypto, but instead of having a single private key and public key, each user has 2 private keys and a public key. A private key the user controls and a second private key kept on the TriCipher ID Vault appliance. Of course, then there is a 3rd key, the public key.

For our “USB key” feature, the USB device serves as the 2nd “what you have” factor and of course works in conjunction with the user’s password. These two components are used to recreate what is best to think of as the “user’s key”. Note that loss or theft of the USB key provides an attacker no attack vector to guess or work backward to the password. Same with theft of the password. Whether phished, pharmed, keylogged or social engineered in any way, possession of the password alone is useless without the USB key.

The “user’s key” is used in conjunction with the other private key for that user kept on the ID Vault (ID Vault key). To properly authenticate both the user’s key and the ID Vault key are used to co-sign, if you will, and consequently create a standard, x.509 certificate based, verifiable signature for any client-SSL enabled relying party site. A decent analogy is going into a bank to open a safety deposit box where the bank manager has a key and you have a key. The safety deposit box can only be opened when both parties are present and perform their function.

Couple important points:

• Relying party needs no TriCipher code to accomplish this standards-based function.
• The two private keys for each user are never recombined anywhere to be compromisable in a single location.
• The user’s private key is never stored anywhere, ever.

While an understandably confusing point, no, we do not get in the middle between authenticating sites and users. We utilize the true two-way, mutual authentication SSL mechanism built into both the server and client ends. All our “magic sauce” briefly described above is done between the client and the TriCipher ID Vault directly. It is pretty accurate to think of the connection between the client and the ID Vault as forming a secure, virtual smart card. Certainly as far as all the client code is concerned, the signature is performed by a local, smart card as we again use the existing standards for signing procedures, CAPI and PKCS11.

Of course, there is a lot more to tout about the benefits of our solution, but I’ll restrain myself to hopefully clarifying a couple points this particular product function raised.

As a vendor in the strong authentication space I feel that my criticism of certain practices that competing vendors live and breathe on are not only not taken seriously, but nearly completely discounted. To be honest, this is completely understandable, but consequently, I am happy when 3rd party sources point out various shortcomings and problems. Recently, the following bulletins were pointed out to me and I thought I would mention them here too buttress points made in earlier posts. In this case SiteKey / Passmark is called out, but I would generalize these problems to many offerings in the “strong authentication” space. I put “strong authentication” in quotes as most of these approaches are not actually strong and never were, but were pitched as such. Let’s review them in order as listed on the NIST National Vulnerability Database. I hope readers will perform their own searches and comment on other pertinent situations back here.

Warning, this post contains blatant compare and contrast content about TriCipher’s offering in context of these three vulnerabilities. I’ll try not to do this too often, but I believe these are valuable touchpoints to discuss fully and removing my own vendor hat doesn’t seem particularly useful for this post.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7199
“EMC RSA Security SiteKey allows remote attackers to display the correct image via a man-in-the-middle (MITM) attack in which an attacker-controlled server proxies authentication data to and from a legitimate SiteKey server.

“This vulnerability basically points to what I’ve generally referred to as the “device registration man-in-the-middle (MITM) problem. In this attack users are drawn to a false site which proxies the actual site. The proxy of course doesn’t have the cookie that the user does and consequently walks the user through the source site’s “register your device” screens. This happens whether the user actually has the 2nd factor cookie or not. Given that users have now been conditioned to go through this process many times such, that it isn’t an exception event worthy of concern, they complete the process. The attacker now ends up with the password and a legitimate cookie and off they go with the user none the wiser.

The “vendor disputes” note points to the fact that everyone acknowledges this is a weak system and that backup monitoring is necessary. This is why so many solutions that originally touted themselves as a “two-way, two-factor” solution moved much more strongly into the fraud detection space such that the detection offering became the true value of their products. Passmark (which is what Bank of America’s SiteKey is) and Bharosa are two examples of this. See my earlier post “Pictures and fraud detection” for more. All solutions using such light touch, as in no-client-touch solutions are vulnerable to this simple attack, even the lowest part of the TriCipher solution utilizing cookies / device markers. Vendor pitch alert: Fortunately for us, we have many more secure offerings off the same platform such that as risk and attacks rise, our customers have somewhere to go without a new implementation.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7200
“EMC RSA Security SiteKey issues challenge-bypass tokens that persist forever without a cancellation interface for end users, which makes it easier for attackers to bypass one stage of authentication by stealing and replaying a token.”

This one is pretty simple and straightforward. Cookies are planted and except when deleted, are persistent and consistent across all registered machines. The Passmark system apparently doesn’t know which machines are registered and does not have the ability to unregister devices. To be honest, I’m pretty surprised they haven’t fixed this as it was, and apparently still is, a nice competitive differentiator for us at TriCipher.

Vendor pitch alert: We mark each device independently and provide an interface such that users can name each device for their own ease of use. We then provide the interface for users to unregister single devices or if in a real moment of paranoia, can unregister all devices. Seemed like prudent and obvious practice to us and the fact Passmark hasn’t fixed this indicates they truly are focused on the back end detection, best-guess approach to supposedly strong authentication.

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7201
“EMC RSA Security SiteKey does not set the secure qualifier on the SiteKey Flash token (aka the PassMark Flash shared object), which might allow remote attackers to obtain the token via HTTP.”

To be honest, this is a nice technical callout by the folks at NIST, but given the simplicity of the attack in CVE-2006-7200, not sure adding this secure qualifier would buy much. Sure, this “secure qualifier” attack is rated higher, presumably because authentication is not required to exploit, but it still does require the victim’s voluntary interaction with the attack mechanism. Certainly something nice to fix from an “attention to security detail standpoint”, but addressing the “device registration MITM” attack seems to buy more.

Vendor pitch alert: Of course, moving up TriCipher’s Authentication Ladder would buy significantly more protection across the board.

So there you have some 3rd party call-outs of issues with the light touch, pictures and cookies approach. While I’m tempted to apologize for the strong TriCipher pitch content in this post, I believe it is important to discuss not only these vulnerabilities, but the entire “light-touch, make the user feel safe, but not actually make them safe” approach.

I did a few searches on one time passwords, OTP and MITM, but didn’t find anyentries on the Vulnerabilities database calling out the known and real world implementation attacks against OTP systems. I’ll keep looking and report back here should I find them or not.

Needless to say, I’ve been busy regardless the lack of activity here on on the blog. I’ve crisscrossed the U.S. several times and the Atlantic twice as well. Once on business and once more for pleasure.

For my first post after such a long gap, I’m going to chat quickly about two events I attended that tie most directly to this blog. The FTC: ID Proof Positive event in Washington, DC on April 23-24 and the Online Game Developers Conference in Seattle May 10-11.

The FTC event as you can imagine was a bit dry, but I’d like to share one positive line of thinking I heard and one negative.

First the positive. Several speakers actually reiterated an important point: The threat to user confidence is at least as, and probably more, important than the direct $$ losses to online attacks. There is a big disparity between speaking to user communities under constant assault from a dizzying array of attacks and press coverage of millions of user’s identities being compromised on one hand. On the other hand then speaking to financial institutions that point to their “very manageable fraud loss rates”. Indications from the past holiday cycle point out that while total spending was up, the number of folks doing that spending didn’t grow much. Looks like confidence is down except for those already “in”. But if loss rates are still low, there’s no incentive for anyone to get too concerned.

Really? Are we digital life people just so insulated from the rest of the real world that we believe everyone is on the e-bandwagon? Check around you. I’m constantly surprised by the number of people in high-tech sectors that won’t transact online on a dare. The majority of my non-high-tech friends also are very skitish about transacting online. Seems everyone on the e-field should be anxious to get those spectating from the stands to join us and bring their e-money.

Now to the negative. There was a panel late on the 23rd roughly titled “FFIEC 4 Months In”. I almost felt sorry for the FFIEC guidance representative on the panel. Clearly I’m not the only one who believes the latest guidance was so loose as to accomplish almost nothing for consumers, though admittedly it was a boon to us vendors . Here’s a couple interesting high points I noted:

1. When asked about what was and wasn’t actually suitable for online banking he indicated “anomaly detection alone does not satisfy the guidance” [undoubtedly a paraphrase, I’m not that great a note taker]. Wow. It will be interesting to get back with some banks that placed their entire guidance compliance in the hands of anomaly detection. While I am clearly a strong authentication kinda guy, am I against fraud detection? Of course not. I believe in defense in depth as much as any competent security practioner in the virtual or real world, but as the sole security layer of supposed multi-factor authentication, no way.
2. When asked about where things should then next head for MFA, he actually mentioned OTPs as the next big thing for moving up in security levels. Now I can understand why an FFIEC guy (or gal) wouldn’t be up on the cutting edge of security attack vectors, techniques and cracks, but doesn’t he read his own industry press? Citibank wasn’t the only publicly compromised OTP last year. Heck the FFIEC is mentioned specifically in this article, though don’t get me started on the non sequitur of the last line from Mr. Lam.
3. Given #1 and #2 above and that one smart tech guy on the panel had already rained on most of the rest of the FFIEC guidance items as broken and busted, I could hardly spit out my question, “So if this guidance is already full of measures that are compromised, when can we expect FFIEC-2?”. There was a lot of hemming and hawing, but basically the direct answer was, [paraphrased] “The FFIEC doesn’t want to create confusion and pain for the financial institutions. Our last note on these lines was in 2001, sooo…”. Seriously, I swear to you he trailed off. Clearly then it will be years before they step up, if the same gap holds true, they won’t come back with something till 2009. Will other regulators step in? Will they also seriously undershoot the already demonstrable threat level in 2009?

So now onto a more pleasant topic, online gaming. The OGDC was very interesting both from a professional and personal standpoint. When there weren’t direct security or infrastructure sessions, I sat in on a few of the more creative sessions. It was very interesting to listen to some “inside baseball” discussions from those that take technology, story and interfaces to deliver entertainment and that ever elusive “fun”.

Not as much to report there. Couple points pretty well sums it up.

1. Several sessions reported on a data showing that a compromised World of Warcraft (WoW) account is worth twice as much ($10) than a compromised credit card ($5) on the black market.
2. I chatted with a senior developer about his MMO’s need to strengthen authentication against phishing and other social engineering attacks that we gamers increasingly hear about. He indicated that his company preferred to deal with these theft cases as a customer support issue. Should a user’s account get compromised and they login to find all their hard earned loot sold out from under them, the support folks will investigate the logs and try to validate the “supposed victim’s story”. If the story seems true, the stuff can be reinstated. Good luck proving a customer did or didn’t share the account and just get taken by “friendly fraud”.

Now, that is certainly a feasible approach, but I’d be one irritated user as what would stop this from happening again? Especially if the attack was launched with a keylogger just waiting to do it to me again? Doesn’t seem like customer care to me, but then I’m biased, cuz I’m a vendor trying to sell the MMO something, right?. True enough, but doesn’t mean that as a gamer I’m not seriously peeved at this attitude.

Curious as to others thoughts about why a WoW account is so much more valuable than a credit card. My quick and dirty analysis is thus:
* Check the prices online for purchase of a top level character. Looks like starting prices are around $454 running up to $749 for some of the quick searches I ran on this site.
* What do you think will get the FBI or other law enforcement’s attention more: “Our merchant database of 200,000 credit cards was stolen” or “200,000 had all their Shadoweave Robes and other virtual stuff stolen”?

Seems like the old risk / reward equation makes this seem pretty self explanatory, but maybe I’m oversimplifying.