January 07, 2006

RSA comes clean: MITM on the rise, Hardware Tokens don't cut it, Certificate Model to be Replaced!

In a 2005 document entitled Trends and Attitudes in Information Security that someone sent to me, RSA Security, perhaps the major company in the security world today, surveys users in 4 of the largest markets and finds that most know about identity theft, and most are somewhat scared of ecommerce today. (But growth continues, so it is not all doom and gloom.)

This is an important document so I'll walk through it, and I hope you can bear with me until we get to the important part. As we all know all about identity theft, we can skip to the end of that part. RSA concludes its longish discussion on identity theft with this gem:

Conclusion

Consumers are, in many respects, their own worst enemies. Constantly opening new accounts and providing personal information puts them at risk. Ally this to the naturally trusting nature of people and it is easy to see why Man-in-the-middle attacks are becoming increasingly prevalent. The next section of this e-Book takes a closer look at these attacks and considers how authentication tokens can be a significant preventative.

Don't forget to blame the users! Leaving that aside, we now know that MITM is the threat of choice for discerning security companies, and it's on the rise. I thought that last sentance above was predicting a routine advertisement for RSA tokens, which famously do not cover the dynamic or live MITM. But I was wrong, as we head into what amounts to an analysis of the MITM:

9. Offline [sic] Man-in-the-Middle attack

With online phishing, the victim receives the bogus e-mail and clicks through to the falsified Web site. However, instead of merely collecting rapidly changing passwords and contact information, the attacker now inserts himself in the middle of an online transaction stream. The attacker asks for and intercepts the userís short-time-window, onetime password and stealthily initiates a session with the legitimate site, posing as the victim and using the victimís just-intercepted ID and OTP.

Phishing is the MITM. More importantly, the hardware tokens that are the current rage will not stop the realtime attack, that which RSA calls "online phishing." That's a significant admission, as the RSA tokens have a lot to do with their current success (read: stock price). The document does not mention the RSA product by name, but that's an understandable omission.

Maybe, your pick.... But let's get back to reading this blurb. Here comes the important part! Heads up!

The need for site verification

The proper course is for the computer industry to create a comprehensive method and infrastructure for site verificationómutual authentication by both site host and user. Most authentication is about knowing who the user isóbut the user wants the same level of assurance that heís dealing with the right/trusted site. Site verification creates a two-way authentication process. Different security advocates have proposed a couple of alternatives to achieve site verification.

Host Authentication
In this method, the legitimate site host presents a value onscreen. The user must compare that value to whatís displayed on the token and ensure it matches....

Read it again. And again, below, so you don't think I make this shit up. RSA Security is saying we need a site verification system, and not mentioning the one that's already there!

SSL and certificates and the secure browsing system are now persona non gratis, never to be mentioned again in corporate documents. The history book of security is being rewritten to remove reference to a decade or so of Internet lore and culture. Last time such a breathtaking revision occurred was when Pope Gregory XIII deleted 10 days from the calendar and caused riots in the streets by people wanting their birthdays back. (Speaking of which, did anyone see the extra second in the new year? I missed it, darn it. What was it like?)

So, what now? I have my qualms about a company that sells a solution in one decade, makes out like bandits, and then gets stuck into the next decade selling another solution for the same problem. I wrote recently about how one can trust a security project more when it admits a mistake than when it covers it up or denies its existance.

But ones trust or otherwise of RSA Security's motives or security wisdom is not at issue, except for those stock price analysts who hadn't figured it out before now. The important issue here for the Internet community is that when RSA admits, by default or by revisionism, that the certificates in the secure browsing model need to be replaced, that's big news.

This is another blackbird moment. RSA wrote the rule book when it came to PKI and certificates. They were right in the thick of the great ecommerce wars of 1994-1995. And now, they are effectively withdrawing from that market. Why? It's had a decade to prove itself and hasn't. Simple. Some time soon, the rest of the world will actually admit it too, so better be ahead of the curve, one supposes.

Get the message out - RSA has dumped the cert. We still have to live with it, though, so there is still lots of work to be done. Hundreds of companies are out there pushing certificates. Thousands of developers believe that these things work as is! A half-billion or so browsers carry the code base.

Without wishing to undermine the importance of RSA Security's switch in strategy, they do go too far. All that certificate code base can now be re-factored and re-used for newer, more effective security models. I'll leave you with this quasi-recognition that RSA is searching for that safe answer. They're looking right at it, but not seeing it, yet.

Browser plug-in

With this method, a locally resident browser plug-in cryptographically binds the one-time password (or challenge-response) to the legitimate siteói.e., the actual URL, rather than the claimed site name. This means that the password is good only for the legitimate site being visited.
This is an implicit level of site verification and is a far better approach than token-based host authentication and can prevent man-in-the-middle attacks. There are drawbacks and vulnerabilities, however. First, a browser plug-in presents all of the attendant issues of client software: it must be successfully loaded by the customer and updated, supported, and maintained by the site host. And, if the PC has been compromised through some form of co-resident malware, it remains vulnerable to subsequent exploitation.

Huh. So what they are saying is "we see good work done in plugins. But we don't see how we can help?" Well, maybe. I'd suggest RSA Security could actually do good work by picking up something like Trustbar and re-branding it. As Trustbar has already reworked the certificate model to address phishing, this provides the comfortable compromise that RSA Security needs to avoid the really hard questions. Strategically, it has everything a security company could ever want, especially one cornered by its past.

I said that was the last, but I can't resist one more snippet. Notice who else is dropped from the lexicon:

In the end, trust is a human affair and the right technology foundations can create a much stronger basis for forming that trusted relationship. As consumers and vendors continue to respond to new and emerging threats to identity theft, it will be essential for them to bear these principles in mind. For more information about any of the issues raised in this document please visit www.rsasecurity.com or contact:

If anyone can send me the URL for this document I'll gladly post it. All in all, thanks to RSA Security for coming clean. Better late than never! Now we can get to work.

Posted by iang at January 7, 2006 03:45 PM | TrackBack
Comments

Why don't you just post it? Seems like fair use to me.

Posted by: adam at January 8, 2006 11:13 AM

How could you tie the OTP to the website using Trustbar? I see that Trustbar can solve the SSL problem of host identification, but I don't see how it could meet RSA's goal.

Posted by: nick owen at January 10, 2006 05:35 PM

Nick,

I think there are some plugins that just manage passwords on a per-site basis. Whereas Trustbar manages names on a per-cert/site basis. I.e., Trustbar doesn't manage the user-auth-to-site leg, just the site-auth-to-user leg.

This is all open to question and interpretation of course, but I think in terms of their claim that "the user wants the same level of assurance that he's dealing with the right/trusted site" this is an area that the petnaming concept covers well.

Posted by: Iang at January 11, 2006 03:50 AM

TrustBar can help the user identify the real, SSL/TLS protected site, thereby sending the password - or OTP - securely and preventing the threat.

The solution that RSA described, using the site's URL as input to the challenge-response device, will work for OTP devices but not for passwords (which will still be subject to dictionary attacks). BTW, the binding should preferably be to the site's public key, imho, and not (just) to the URL, to protect against DNS poisoning and other MITM attacks (e.g. on shared media LAN such as wireless). But if you enter your password (or - better yet - OTP / response from gadget) into an SSL/TLS protected site using the correct public key, as assured by TrustBar, this is even better.

OTOH, TrustBar still depends on users noticing spoofed site. It is much easier to detect spoofed site with TrustBar, which displays your chosen name or logo for the trusted site (or at least the certified site's name or logo and identity of CA). But, many users may still fail to notice the spoofing. We hope this will substantially improve with our new version, which will try to implement my new moto: `defend, don't ask`. When user clicks on his bookmark for his sensitive sites (bank, etc.), we'll take him to that page - but only if it is the correct page. This will also protect users of these shameful unprotected login pages.

Posted by: Amir Herzberg at January 11, 2006 07:53 AM

Good point, Ian. I vaguely remember now seeing something about a passkeep extension? I'll have to research. And I agree that petnames/trustbar assure the users that they are at the right site.

Amir: We bind to the public key by downloading a hash of the sites cert from the the OTP server along with the OTP. The token client then gets the cert from the internet, hashes and compares the two. We then launch the browser to the correct website for them and provide the link with an OK message. So, we also work for OTPs, but only our own and not passwords. We don't have a browser plug-in, yet ;).

As for shameful: in testing, I entered https://www.bankofamerica.com into the test server. Everything worked great, the browser launched to https:/www.bankofamerica.com, and was then redirected to the http page for login!

Posted by: nick owen at January 11, 2006 08:59 AM

I would really like to see form-based authentication go to the deepest pockets of hell, where it really belongs. HTTP AUTH is an existing better alternative, except that browsers do not distinguish between BASIC AUTH and DIGEST AUTH. The former must be disabled by default an be visually different even when enabled.
Further authentication mechanisms, such as SRP and RSA-signature of requests with password-derived private keys could be added to futher improve security.

Posted by: Daniel A. Nagy at January 11, 2006 09:14 AM

There's nothing wrong with entering login information into a form on an HTTP page provided the underlying Javascript submits the data to a HTTPS URL (as does the Bank of America site).

I agree though, to the untrained eye it would appear to be an insecure login prompt. My bank has two login pages; one page that does this and another that provides the form from an HTTPS URL. I prefer the latter.

Posted by: Piers Bowness at January 11, 2006 11:55 AM

Piers,

I'm afraid there is something wrong with entering the info into an unprotected HTTP page! It is not with that immediate session but with future sessions that the problem arises.

In short, using unprotected HTTP pages is training the user to be phished. If I can get you onto a page that is unprotected and looks like your bank, then when you enter you username and password, it matters not what happens after - You've still been phished.

(Don't worry, this wasn't obvious to me until we'd beaten it around with 10 or 20 loud emails :)

(And, the fact that this site permits you to post comments on both HTTP and HTTPS is training for phishing... luckily the details you enter in aren't as valuable!)

Posted by: Iang at January 11, 2006 12:25 PM

The company called RSA is really the old Security Dynamics business rebranded. They have a big base in OTP deployments and have made negligible impact on the PKI market despite their name. They are currently seeing their margins eroded as their patent portfolio expires and the tokens are becomming a commodity.

Although RSA regularly features highly in the Netcraft CA vendor surveys these certificates are actualy sold by VeriSign, not RSA. The certificates sold by RSA are actually issued off a GeoTrust root.

Posted by: Phill at January 11, 2006 05:05 PM

I think you're misreading the white paper. RSA just bought Cyota, a company that makes systems for authenticating end users. They offer products that authenticate users and web sites without using OTPs or certificates. It looks like this is more of a rebranded white paper from the Cyota folks (which would, of course, badmouth OTP and certificate based systems) than a large change in RSA's position.

Posted by: Joe at January 11, 2006 05:12 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.