On Thu, Dec 10, 2009 at 2:08 PM, Andrew Arnott <[email protected]> wrote: > Why do OPs have to use passwords? Someone using myvidoop.com or InfoCards > for example would have a harder time sharing their credential with someone > else.
Obviously neither OPs nor anyone else has to use passwords. However, mostly they do, presumably because usability of other options sucks. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Thu, Dec 10, 2009 at 12:20 AM, Ben Laurie <[email protected]> wrote: >> >> On Thu, Dec 10, 2009 at 2:44 AM, John Bradley <[email protected]> wrote: >> > PS, >> > If you use your email account for account recovery your email provider >> > can >> > get access to all of your other accounts. That is one of the largest >> > security problems. >> >> Surely the problem is not that the provider can do it (yes, they can, >> but how often do they?), but that anyone you give your password away >> to can do it. >> >> > John B. >> > On 2009-12-09, at 8:53 PM, Shearer, Charles Dylan wrote: >> > >> > John & Andrew, >> > >> > That you both for your interesting responses and pointers. >> > >> > Andrew, you said: >> > >> > your question moves past the security issues associated with the >> > protocol >> > and addresses trust issues in the ecosystem. As John indicated, at the >> > current assurance levels and resulting appropriate usage scenarios, >> > OpenID >> > deployment and the trust levels associated with OP's are probably >> > sufficient. >> > >> > >> > And John said: >> > >> > Given that openID is only secure enough as a protocol for ICAM LoA 1 >> > (pseudonymous protecting no PII) the most practical path is to provide >> > more >> > trustable OP/IdP. >> > >> > I think you both are saying that, for what OpenID is intended to do, it >> > works. In other words, OpenID can be used if we can assume that the >> > supported identity providers are honest. I cannot understand why we >> > should >> > have to make that assumption at all. There are well-supported >> > technologies >> > like PKI that provide identification, authentication, and even >> > nonrepudiation without forcing us to put a very large amount of trust in >> > a >> > 3rd party. >> > >> > Indeed, my point is that OpenID forces us to put a lot of trust in the >> > identity provider: we trust them with the ability to access our RP >> > accounts, >> > and we trust them with the knowledge of the fact that we use these RP >> > services. Just like most attacks, the probability that a provider (or >> > employee thereof) will behave dishonestly is low (but certainly not >> > negligible) --- but I should not have to take that chance. >> > >> > You might counter that we already put a lot of trust in organizations >> > (that >> > is, potential RPs) --- for example, banks --- so why shouldn’t we also >> > trust >> > an identity provider? That is true, but there is a difference. When I >> > trust bank A, my trust is limited to the cash I give it and the credit >> > accounts I have open with it. When I trust bank B, my trust covers only >> > the >> > accounts I have with that bank. When I trust Amazon.com, I trust it >> > only >> > with the information of one credit card. When I trust my email >> > provider, I >> > trust them only with the email associated with that account. The risk >> > is >> > limited in each case. Now, imagine that I use OpenID to log into all >> > four >> > of those services: I am now trusting my identity provider with all four >> > aspects of my life. >> > >> > Charles >> > >> > >> > On 12/9/09 8:18 AM, "Nash, Andrew" <[email protected]> wrote: >> > >> > Charles, >> > >> > your question moves past the security issues associated with the >> > protocol >> > and addresses trust issues in the ecosystem. As John indicated, at the >> > current assurance levels and resulting appropriate usage scenarios, >> > OpenID >> > deployment and the trust levels associated with OP's are probably >> > sufficient. >> > >> > The operating principals, policies controlling activities and personnel, >> > audit trails and verifiable operation by third parties are all aspects >> > to >> > resolving the question you address. IFF you are dealing with low >> > assurance >> > credentials and low value transactions, then as David identifies it >> > probably >> > matters less and their are many alternative problems you could face from >> > your ISP. However, for higher assurance levels, higher value >> > transactions, >> > more sensitive information or whatever, then you need to establish a >> > trusted >> > Identity Services Provider - hopefully using transparent mechanisms >> > rather >> > than just marketing spin, but heh. >> > >> > However, you should be aware that in the area you seem to be addressing, >> > there are corresponding requirements and issues about how a relying >> > party >> > will treat the information that is provided to it and a need to verify >> > (at >> > higher assurance levels) that correct usage and protection of that >> > information takes place. This is an issue that I raised several times in >> > the >> > context of the Federal Govt that Mary Rundle has taken up in the open >> > trust >> > frameworks discussion. For large scale operation this relying party >> > assurance equivalent will not likely consist of audits, but probably >> > will >> > need to rely on relying party agreements (no pun intended :) ). >> > >> > The Kantara Initiative have done some good starting work on Identity >> > Assurance models (based on earlier work by NIST et al). It needs lot >> > more >> > work and does not address a range of deployment challenges, but is worth >> > taking a look at. >> > --Andrew >> > >> > >> > >> > ________________________________ >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of John >> > Bradley >> > Sent: Tuesday, December 08, 2009 3:34 AM >> > To: Shearer, Charles Dylan >> > Cc: OpenID Security Mailing List >> > Subject: Re: [security] Nonrepudiation, and Trusting OpenID Providers >> > >> > Charles, >> > >> > It is true that almost all assertion based protocols require that a RP >> > and >> > user have some trust in the OP/IdP. This is equally the case for SAML >> > and >> > managed Info-Cards. >> > >> > Some thing like PKI and personal info-cards allow the user to have >> > complete >> > control over the authenticator. >> > >> > There are two basic options: >> > 1 increase the trustability of the OP/IdP >> > 2 Use multiple IdP simultaneously and prey. >> > >> > I don't personally believe that option 2 is all that practical or gives >> > much >> > more security for the average user. >> > >> > Given that openID is only secure enough as a protocol for ICAM LoA 1 >> > (pseudonymous protecting no PII) the most practical path is to provide >> > more >> > trustable OP/IdP. >> > >> > That said, with some of the v.Next changes openID will become >> > appropriate >> > for higher LoA. >> > >> > I don't think Gov or Banks are going to be comfortable with multi Auth >> > solutions. They are going to insist on trusted OP/IdP. >> > >> > You can have a look at the ICAM site to see where the US Gov is going. >> > http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV >> > >> > I can see binding more than one openID to a RP to allow for recovery, >> > however that needs to be balanced against doubling the attack surface. >> > >> > Regards >> > John Bradley >> > >> > On 2009-12-07, at 9:47 PM, Shearer, Charles Dylan wrote: >> > >> > >> > I have some concerns about OpenID, and I would like to see what those >> > involved think about them. >> > >> > It seems to me that, regardless of how OpenID is deployed, it is always >> > possible for an OpenID provider itself to authenticate with a relying >> > party >> > as any user by forging a request to authenticate using the user’s >> > identifier. This is because a relying party cannot tell the difference >> > between a user attempting to log in using his or her identifier, and >> > the >> > user’s OpenID provider spoofing that user to gain access to whatever >> > services the relying party provides to that user. This seems to >> > require >> > that both users and relying parties put a lot of trust in OpenID >> > providers: >> > for example, if I used my OpenID identifier for online banking and >> > email, >> > my OpenID provider could easily access my email and bank account. >> > >> > Additionally, even if we assume that OpenID providers will not log into >> > users’ accounts, I still cannot see how OpenID could provide >> > nonrepudiation >> > regarding messages sent to a relying party by an authenticated user: >> > for >> > example, if I authenticate with my bank using my OpenID identifier and >> > then >> > use the bank’s “bill pay” service to pay a bill, there’s no way the >> > bank >> > can prove that I ordered that payment because it is possible that >> > someone >> > working for my OpenID provider logged in as me and ordered it. >> > >> > Does anyone disagree with my analysis? >> > >> > Dylan >> > _______________________________________________ >> > security mailing list >> > [email protected] >> > http://lists.openid.net/mailman/listinfo/openid-security >> > >> > >> > >> > >> > _______________________________________________ >> > security mailing list >> > [email protected] >> > http://lists.openid.net/mailman/listinfo/openid-security >> > >> > >> _______________________________________________ >> security mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-security > > _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
