Adventures of an Eternal Optimist » Information Security (this is for you RSA)

Axel’s Challenge

Pamela — Fri, 16 Oct 2009 15:47:31 +0000

Axel says he’ll fetch you a beer at IIW if you can decrypt the token he has made publicly available on his blog: crypto doubters in the crowd, this is your big chance! As someone who was recently burned while copying and pasting encrypted tokens off of a web page and trying to decrypt, I would be careful of the white space though, I bet if you ask really nice he’d even send you a file version.

My Case is MADE

Pamela — Sat, 12 Sep 2009 17:37:57 +0000

I wrote not long ago about the HSBC Canada banking site, and its odd and frightening ways of dealing with access control. Their fanciful notions of authentication proved to me that passwords were being stored in a retrievable format rather than in a format where the password can be verified as matching but not retrieved and examined.

This exact same issue has come up on the OSIS list with respect to privatepersonalidentifiers – some have argued that it is perfectly safe to store raw ppid and modulus information at the RP, and I cannot tell you how STRONGLY I disagree with that idea.

Luckily, Gunnar has pointed me to the perfect example: apparently the HSBC France banking site has been hacked, and guess what? They are storing their customer’s passwords in clear text too (surprise surprise). And a handy little SQL injection attack gives the hacker everything he needs to log in as anyone he can think to query for.

Had the HSBC stored their passwords in some kind of encrypted format, the same attack would have netted the hacker a fraction of the value, because there would still be a significant and likely cost-ineffective amount of time and work necessary to turn the data into a set of credentials that could be used for actual authentication. This is why encryption of passwords is an industry best practice, and why you will and should be laughed out of this community if you can’t get such a simple mitigation right.

If an RP stores the ppid and modulus of a self-issued information card in clear text, and that RP becomes the victim of a SQL injection attack, a hacker has everything they need to get in the front door too. The data must be stored in a way that mitigates this danger, period. I consider this to be identity 101 for information cards, and anyone who writes an RP should consider this to be a best practice.

Guidance

Pamela — Mon, 20 Jul 2009 19:10:46 +0000

In researching a few products for a client, I came across an e-book on Managing Linux & UNIX Servers by Dustin Peryear. I managed to get access to a chapter without registering, and I liked what I saw so much that I had to have the whole book.
The thing that is remarkable about this book to me, is that it is NOT a book about technology, commands, program execution or coding. It is a book about what to get done and why. There are so few of these kinds of books – the ones that assume that once you have a comprehensive plan for getting things done, finding out how is the easy part. The books that get that the mapping works better from the top down than the bottom up: all the man pages in the world will not help you if you don’t have the context to know which of them you should be reading, and what the end result should be when you apply that knowledge. It is the guidance that makes the difference.

I very badly want a book like this for information card Relying Parties, specifically the PKI functionality of an RP. I have work to do on my RP: right now I know I’m missing several critical checks to ensure integrity and non-repudiation for the messages I’m accepting and trusting. But how do I know that I have covered all the bases? I have this list of interoperability issues. I have a set of api calls into security libraries like xmlseclib and openssl that could possibly solve my issues. What I do not have is guidance. I feel like I’m assembling an entertainment unit from IKEA, and I have detailed engineering information on every screw and every panel in the entire IKEA inventory: thousands of weights, heights, screw thread pitches, you name it. While I technically have access to everything I could possibly need to assemble my entertainment unit, it is left up to me to figure out which and how many of the inventory items I need, how they fit together, and what order they must be assembled.

I suppose what I’m saying is we need to step above RTFM (Read the Fsking Manual) to KWFMTR (Know Which Fsking Manuals to Read).

(photo credit: http://www.flickr.com/photos/jonk/33283987/)

Security as Upsell

Pamela — Tue, 16 Jun 2009 21:54:51 +0000

Here is a philosophical question for you:

Many SaaS vendors currently only offer SSL support to clients who pay a premium. Users who don’t pay, can’t have the “extra” benefit of using SSL. What happens to the small companies and/or single users who wish to be secure, but do not need unlimited users or 2GB of file storage, or 10 project templates? Who in their right mind would pay $20 extra a month just to get SSL? And what possible justification is there for denying transport-level security to smaller customers?

Today we have this perception that only the largest corporations need to pursue security: the ones with CIOs and Enterprise Architects, the ones trading publicly or in a vertical where audits are mandatory. If you ask me, I think we could go a very long way if we stopped thinking like this and began to enable any person or organization, of any size to care about, understand, and pursue secure internet operation.

I know it isn’t as lofty a goal as Bob has put forth; but this issue, to me, represents a small part of the underlying systemic problem that Bob is trying to shed light on.

Am I an Accessory?

Pamela — Sun, 31 May 2009 23:21:05 +0000

I am stuck in an interesting dilemma.

I love my web hosting company, I think the people are great, the tools and support are top notch, and the price is right. I was, in fact, thinking of upgrading my service with them.

But I cannot ignore the fact that on my particular server, they haven’t updated their openssl libraries in 5 YEARS. Five. By my count, they are 20 revisions behind the current library version.

This means that there is a list of exploits as long as my arm that can probably be used against the various sites that I sponsor, including the Pamela Project and OSIS. The big problem is that I’m using a shared Apache infrastructure, and while I can recompile PHP and Curl to use up-to-date libraries, Apache does a lot of the heavy lifting when it comes to transport-level security, and as far as I know, I cannot affect the modules that load into that shared webserver environment.

Obviously there are actions that I can take to ensure my own security. I can change web hosters. I can upgrade to a server where I have access to my own apache configuration. The standard answer here is that if I don’t like what I’ve got I should leave.

But – what about the folks on my server who don’t even know they are at risk? Who are running shopping carts and who just assume that they are on a well-patched, secure server? By silently walking away from an insecure environment, am I in fact aiding and abetting the web hosting company in their terrible security practices?

I have in the past contacted support about updating SSL libraries when various remote holes were found. I won’t quote their answer because I don’t have the email to back up my recollection, I didn’t think to save them, but the version number speaks for itself: 0.9.7e. The current version is 0.9.8k. I’m not a big customer, and I know that by paying more I could become more secure — but must it follow that by paying less I have to be at risk? I already pay extra per month for SSL support, and also for the unique IP address that is a pre-requisite. Do I have to get hacked before I have a case?

So I ask you all — for the small number of us who know better — what’s the right way to proceed? Do I silently act to ensure that I myself am secure, leaving all those other poor uneducated suckers to continue in ignorance and risk? Do I make a stink? I doubt I have the clout to cause this very large company to do anything. Yet, if I don’t, who will?

Update: I received a response to my separately sent inquiry to the security team just now (told you they are responsive):

We run Debian Linux. Debian does not put new upstream releases, even point releases, into a stable distribution. What happens is that only the security fixes are backported into a package in stable. This minimizes the possibility for the stable release to be de-stabilized by new code introduced upstream.
So while the version of libssl0.9.7-sarge5, it should nevertheless incorporate all the security fixes present in 0.9.8k.

So, the good news is that I’m probably safe, and the team is on top of it. The bad new is that I simply have to trust it is so, I don’t see a way to easily independently verify.