{"id":1004,"date":"2008-08-13T12:09:52","date_gmt":"2008-08-13T20:09:52","guid":{"rendered":"\/?p=1004"},"modified":"2008-08-13T14:22:48","modified_gmt":"2008-08-13T22:22:48","slug":"crypto-flaw-bad-practices-need-for-governance","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1004","title":{"rendered":"Crypto flaw + bad practices = need for governance"},"content":{"rendered":"

Speaking of issues of governance, the Register just brought us this report <\/a>on a recent\u00a0“archeological investigation”\u00a0by Ben Laurie<\/a> and Richard Clayton<\/a> that revealed how a Linux security flaw left\u00a0a number of\u00a0OpenID sites vulnerable to attack:<\/p>\n

“Slipshod cryptographic housekeeping left some OpenID services far less secure than they ought to be.<\/p>\n

“OpenID is a shared identity service that enables users to eliminate the need for punters to create separate IDs and logins for websites that support the service. A growing number of around 9,000 websites support the decentralised service, which offers a a URL-based system for single sign-on.<\/p>\n

“Security researchers discovered the websites run by three OpenID providers – including Sun Microsystems – used SSL certificates with weak crypto keys. Instead of being generated from billions of possibilities, the keys came from a a set of just 32,768 options, due to a flaw in the random number generation routines used by Debian. The bug, which has been dormant on systems for 18 months, was discovered and corrected back in May.<\/p>\n

“Keys generated by cryptographically flawed systems still needed to be replaced even after the software was upgraded. But recent research by Ben Laurie of Google reveals that 1.5 per cent of certificates he looked at contained weak keys. Three OpenID providers (openid.sun.com, xopenid.net and openid.net.nz) were among the guilty parties.<\/p>\n

“To exploit the vulnerability, malicious hackers would need to trick surfers into visiting a site impersonating a pukka OpenID provider. But faking digital certificate alone wouldn't do the trick without first misdirecting surfers to these bogus sites. Dan Kaminsky's recent discovery of a DNS cache poisoning flaw made it far more plausible to construct an attack that sent surfers the wrong away around the net's address lookup system, potentially to a bogus Open site posing as the real deal.<\/p>\n

“The security flaw meant that even cautious users who check SSL certificates were at risk of handing over their OpenID credentials as part of a phishing attack. Such an attack would take a lot of effort to pull off and would only yield OpenID login credentials, which aren't especially useful for hackers and are difficult to monetise.<\/p>\n

“Going after online banking credentials via a site that makes no attempt to offer up fake SSL certificates is a far more reliable moneyspinner, a factor that leads noted security researcher Richard Clayton to describe the attack as the “modern equivalent of a small earthquake in Chile”.<\/p>\n

“Sun has responded to the issue by generating a new secure key, which reduces the scope for mischief but still leaves potential problems from the old key.<\/p>\n

“More thoughts on the cryptographically interesting – though not especially life-threatening – flaw can be found in Clayton's posting on Cambridge University's Light the Blue Touchpaper blog here. A security advisory by Laurie and Clayton explaining the issue in greater depth can be found here.”<\/p>\n

I tip my hat to Ben and Richard for doing what I\u00a0think of as\u00a0“system archeology” – looking into the systems people actually leave behind them, as opposed to the ones they think they have built.\u00a0 We need a lot more of this.\u00a0 In fact,\u00a0we\u00a0need to\u00a0have full time archeologists\u00a0rigorously exploring what is being deployed.<\/p>\n

This said, I have to question the surprisingly opportunistic title of Richard's piece:\u00a0 An insecurity in OpenID, not many dead<\/a>.<\/p>\n

Let's get real.\u00a0 None of what went wrong here\u00a0was\u00a0in any way\u00a0specific to\u00a0OpenID.\u00a0\u00a0The\u00a0weakness would have\u00a0struck any application that relied on crypto and was built on Debian Linux and operated in the same way.\u00a0 This includes SSL, which for some reason doesn't get singled out.\u00a0\u00a0And it applies to\u00a0SAML, WS-Trust\u00a0and PKI\u00a0 (e.g. any of the security-based identity protocols).\u00a0 Is\u00a0OpenID a convenient straw man?\u00a0<\/p>\n

In fact there were\u00a0really two culprits.\u00a0 First, the crypto flaw itself, a problem\u00a0in Linux.\u00a0\u00a0Second, the fact that although the flaw had been fixed,\u00a0new keys and certificates had not been obtained by\u00a0a number\u00a0of the operators.\u00a0<\/p>\n

So we are brought right\u00a0back to the issue of governance, and in all fairness, Richard makes that point too.\u00a0\u00a0Given the improper operating practices, and the fact that OpenID imples no contractual agreement, how would anyone have been able to sort\u00a0out liability\u00a0if\u00a0the flaw had resulted in a serious breach?<\/p>\n

Clearly,\u00a0timely patching of\u00a0one's operating system\u00a0needs to be one of the host of requirements placed on any identity provider.\u00a0\u00a0A system\u00a0of governance would make this explicit, and\u00a0provide a\u00a0framework for assigning liability should the requirement not be met.\u00a0 I really think we need to move forward on a broadly inclusive governance conversation.<\/p>\n

And finally, just so no one thinks I have gone out of character, let's all note that any user who employed an Information Card\u00a0to authenticate to the OpenID provider would NOT have\u00a0had her credentials stolen, in spite of\u00a0the vulnerability\u00a0Ben and Richard have documented.\u00a0 \u00a0<\/p>\n

\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

Timely patching of one's operating system needs to be one of the host of requirements placed on any identity provider <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[63,10,22,61,44],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1004"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1004"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1004\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1004"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1004"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1004"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}