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. -- 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
