Monday, November 12, 2012

RSA Distributed Credential Protection: Solving the Wrong Problem?

Recently, RSA Distributed Credential Protection (DCP) was announced by RSA Security.  I’ve read the literature, sat through a presentation by an RSA sales representative, and watched the YouTube videos. And most of all, have formed an opinion.

Being a crypto geek of sorts, I’ll be the first to admit that this seems like a really cool and interesting application of secret splitting.  But, as much as RSA makes it sound like the most innovative thing since sliced bread, I believe that is fundamentally a solution to the wrong security problem. Let’s have a look at why.

As I’ve written many times, security is fundamentally about ensuring trust and managing risk. When attempting to lower risk, there is always a cost / benefit balance that needs to be studied. Just as one would not spend $10,000 for a home safe only to store $1000 in it, IT is not going to spend six figures on a solution that will not reduce the perceived cost of the risk at least that much. (Note that while I am not certain of the pricing of RCA DCP, it is not farfetched to think that an enterprise rollout would be near the six figure range.)

RSA advertises DCP to be transparent to the end users, and so it is. However, that is not the only thing that is important here. Another major factor that only came out during the live presentation by RSA was that any application wishing to take advantage of DCP needed to change their application to adapt to its API. This means of course if you have N applications all authenticating users to an SQL database (or perhaps an LDAP directory store, if the API works with that), all N of those applications need to be changed. If you fail to change one application, then you still need the user’s stored in a single data store where DCP is not applied and consequently still remain unprotected. So take the cost of licensing the RSA DCP software and add to it the cost of each of your N applications integrating the DCP API and you will have something closer to the total cost of deployment. Of course, the operational costs are also likely to increase somewhat as well. Whereas before you had but a single data store for said credentials, now you have two. The end result is that the total cost to incorporate RSA DCP into your environments is likely to exceed the six figure level even if the software licensing costs is nowhere near that amount.

Well, still, that might be OK, right? After all, if the perceived benefits greatly exceed the total costs of mitigation, we still have a security win.

So what benefits does RSA DCP bring to the enterprise? According to the RSA press release as well as this YouTube video, the threat that RSA is trying to prevent is the “smash-and-grab” of credentials by an attacker. Specifically, DCP is designed to make it more difficult for an attacker who has infiltrated your company network and has managed to get direct access to your database server to obtain credentials (either plaintext or hashes).  DCP also would likely mitigate a rogue DBA doing a “smash-and-grab” of your company’s credential data as well, as long as care was taken to provide separation of duties and not give a single administrator a DBA role on both DCP servers.

So we still need to answer this question: Is this a common way for an attacker to gather user credentials?  In my opinion, it is not. By far, the biggest attack vector for adversaries stealing credential material is via SQL (or possibly LDAP) injection attacks. Will DCP do anything to mitigate SQLi attacks? The answer would appear to be “no” (at least according to the RSA sales rep that we talked to). In fact, given that one has to bolt new DCP API code into one’s application to use DCP, there is a chance that new SQLi vulnerabilities may be introduced as developers change the application code.

So is there a place where using RSA DCP would make sense? I believe so, but I think it is a niche market rather than the broad market RSA Security would like it to be.  RSA DCP could be very valuable where you have an extremely high-value target (credentials or otherwise) that are difficult to upgrade. The perfect example that comes to my mind is protection of the RSA Security SecurID seeds. Compromise of those SecurID seeds required RSA to replace all the hard token SecurID devices.  In fact, it is not unreasonable to speculate that this product came directly out of researching ways to protect those high-value credentials from the smash-and-grab type of direct attacks resulting out of that breach. If RSA Security wishes to broaden the market for their new DCP product, I believe that the best approach is for them to integrate DCP seamlessly in with their other products, starting with RSA Access Manager. If you are going to make a believer of us security folk, you first have to be willing to eat your own dog food.

However, in the meantime, for your regular user passwords, salting with a sufficiently long random salt, enforcing password complexity rules when users select their passwords, and enforcing account lockout are likely to be sufficient protection for your customer passwords.  If doing those things is not sufficient, you seriously need to consider whether passwords are a strong enough form of authentication for your users.

Note that the views expressed herein are wholly my own and do not represent those of my company, of OWASP, nor any other organizations with whom I am associated.




  1. By the way, I've contacted someone at RSA Security and have invited them to comment on this post. I'm interested in hearing their perspective.

  2. Hi Kevin,

    A SQL Injection is an application-based attack used to change database content or dump the entire database (including databases containing password files). This is one possible attack vector that can lead to server-side password breaches. But when RSA Distributed Credential Protection is deployed, a SQL Injection would hit the application database (where only usernames and secret IDs may be stored) but the passwords are no longer in that application database. With RSA DCP, the passwords are removed and stored in new servers (which we call the Active/Blue and Passive/Red). A SQL Injection attack that dumps the application database would not result in password compromise any longer, as long as RSA DCP is deployed.

    Liz Robinson, RSA Product Marketing

    1. Hi Liz! Appreciate your responding. It is all well and good that using RSA DCP will eliminate the possibility of exfiltrating passwords or password hashes via SQLi attacks. I would expect and demand nothing less. But I think this is really missing the point. SQLi attacks are extremely simple to prevent by using parameterized statements (e.g., PrepareStatements in Java), and since one needs to change one's application code by replacing (say) JDBC calls with calls to the RSA DCP API, one could just as well make changes to ensure that SQLi is not possible. (In fact, such changes are likely to be easier and certainly cheaper as it does not involve licensing RSA DCP.) Therefore, I think I am correct in my statement about the only significant attack vector that RSA DCP efficiently provides protection against are smash-and-grab attacks by rogue DBAs or other privileged DB users. Hence, in effect, I still believe that RSA DCP is solving the wrong problem. While I hope that DCP succeeds, I contend that at best it will have a niche market only for extremely high value targets.