{"id":1005,"date":"2008-08-13T18:32:39","date_gmt":"2008-08-14T02:32:39","guid":{"rendered":"\/?p=1005"},"modified":"2008-08-13T18:51:27","modified_gmt":"2008-08-14T02:51:27","slug":"1005","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1005","title":{"rendered":"Clarification"},"content":{"rendered":"

In response to\u00a0my post earlier today<\/a> on some OpenID providers who did not follow proper procedures to recover from a bug in Debian Linux,\u00a0a reader wrote:<\/span><\/span><\/span><\/p>\n

\u00a0<\/p>\n

“You state that users who authenticated to the OpenID provider using an Information Card would not have their credentials stolen.\u00a0\u00a0 I assume that cracking the provider cert would allow the bad guys to tease a password out of a user, and that InformationCards require a more secure handshake than just establishing a secure channel with a cert. But it still seems that if the bad guys went to the effort of implementing the handshake, they could fool CardSpace as well. Why does that not expose the users credentials? <\/span><\/span><\/span><\/p>\n

\u00a0<\/p>\n

I'll try to be be\u00a0more\u00a0precise.\u00a0\u00a0I should have stayed away from\u00a0the word “credential”.\u00a0\u00a0It confused the issue.<\/p>\n

\u00a0<\/p>\n

Why?\u00a0 There are two different things involved here that people call “credentials”.\u00a0 One is the “credential”\u00a0used when a user authenticates to\u00a0an OpenID provider.\u00a0\u00a0To avoid\u00a0the “credential” word, I'll call this\u00a0a\u00a0“primordial” claim:\u00a0a password or a key that isn't based on anything else, the “first mover” in the authentication chain.<\/p>\n

\u00a0<\/p>\n

The other thing\u00a0some call\u00a0a\u00a0“credential” is the\u00a0payload produced\u00a0by the OpenID provider and sent to the relying party.\u00a0 At the minimum this payload\u00a0asserts that\u00a0a user\u00a0has a given OpenID URL.\u00a0\u00a0Using\u00a0various extensions, it might say more – passing along\u00a0the user's\u00a0email address for instance.\u00a0 So I'll call these “substantive” claims – claims that are issued by an identity provider and have content.\u00a0 This differentiates them from primordial ones.<\/p>\n

\u00a0<\/p>\n

With\u00a0this\u00a0vocabulary\u00a0I can express my\u00a0thoughts\u00a0more clearly.\u00a0 By using a self-issued Information card like I employ with my OpenID provider<\/a>\u00a0– \u00a0which\u00a0is based on\u00a0strong public key cryptography – we make it impossible to steal the primordial claim using the attack described.\u00a0\u00a0That is because the secret is never<\/strong> released, even to the legitimate provider.\u00a0\u00a0A proof is calculated and sent – nothing more.<\/p>\n

\u00a0<\/p>\n

But let's be clear:\u00a0 protecting the primordial claim this way doesn't prevent a rogue identity provider who has guessed the key<\/strong> of a legitimate provider – and\u00a0poisoned DNS\u00a0\u00a0– from tricking\u00a0a relying party\u00a0that depends on\u00a0its substantitve claim.\u00a0\u00a0 Once it has the legitimate provider's key, it can “be” the legitimate provider.\u00a0 The Debian Linux bug made it really easy to guess the legitimate provider's\u00a0key.<\/p>\n

\u00a0<\/p>\n

Such a “lucky” rogue provider has “obtained” the legitimate provider's keys.\u00a0 It can then “manufacture” substantive claims that the legitimate provider would normally only issue for the appropriate individual.\u00a0 It's like the\u00a0difference between stealing someone's credit card, and stealing a machine that can manufacture\u00a0a duplicate of their credit card – and many others as well.\u00a0<\/p>\n

\u00a0<\/p>\n

So my point is that using Information Cards would have protected the primordial claim from the vulnerability described.\u00a0 It would have prevented the user's keys from being stolen and reused.\u00a0 But It would not have prevented the attack on the substantive claim even in the case of PKI, SAML or WS-Federation.\u00a0 A weak key is a weak key.<\/p>\n

\u00a0<\/p>\n

The recently\u00a0publicised wide-scale DNS-poisoning exploits do\u00a0underline the fact that\u00a0OpenID isn't currently appropriate for high value resources.\u00a0 As I explained in more detail here<\/a>\u00a0back in February:<\/p>\n

\u00a0<\/p>\n

My view is simple.\u00a0 OpenID is not a panacea.\u00a0 Its unique power stems from the way it leverages DNS – but this same framework sets limits on its potential uses.\u00a0\u00a0Above all,\u00a0it is an important addition to the spectrum of technologies we call the Identity Metasystem, since it facilitates\u00a0integration of the \u201clong tail\u201d of web sites into an emerging identity framework.\u00a0<\/p>\n

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

Let's avoid the word “credential”. It has so many meanings as to be confusing <\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[63,37,2,7,22],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1005"}],"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=1005"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1005\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1005"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1005"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1005"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}