Re: Proposal: An anti-phishing compromise
Recordon, David wrote: I agree that things like age should be in an extension, though I think this single piece of data is useful in the core protocol. I'm sure the exact definition of phishing resistant will come back to bite us in sometime in the future, but lets deal with it then instead of not adding anything now. I really like the idea that there be one thing in the core spec which reaches out to each extension. I propose: openid.make_it_work=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
I chatted with Avery about this today. URIs for specific auth methods as well as ones for general seems to be the flexible approach. Per Kim's laws, the method of auth may not be needed, so is extra disclosure On 8-Feb-07, at 11:38 PM, Recordon, David wrote: Maybe laws are meant to be broken. I don't see why a RP knowing that I used a token as a second factor is a bad thing. If nothing else, the technology should support the OP providing that information and the OP's implementation can let me as the user decide if I want to. Just like the trust request, it isn't mandated by the spec but every worthwhile OP does it. My $0.02. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Sunday, February 04, 2007 11:42 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
Maybe laws are meant to be broken. I don't see why a RP knowing that I used a token as a second factor is a bad thing. If nothing else, the technology should support the OP providing that information and the OP's implementation can let me as the user decide if I want to. Just like the trust request, it isn't mandated by the spec but every worthwhile OP does it. My $0.02. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Sunday, February 04, 2007 11:42 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
I agree that things like age should be in an extension, though I think this single piece of data is useful in the core protocol. I'm sure the exact definition of phishing resistant will come back to bite us in sometime in the future, but lets deal with it then instead of not adding anything now. I really like the idea that there be one thing in the core spec which reaches out to each extension. - openid.identity - simple reg or profile exchange (on the basis that the URL is an attribute) - openid.phishing_resistant - AQE I think this is a good model to follow. From the AQE perspective, I agree with you that using URLs for authentication types makes sense, though profiling the entire document beyond that I think is overkill. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Monday, February 05, 2007 12:01 AM To: Josh Hoyt Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Hi Josh A few comments: 1) I think this should be an extension following previous arguments that AuthN Age should be an extension. (AuthN Age would be another good item in this extension) This allows an OP to advertise if it supports a specific security profile. 2) It would be future proofing to view a phishing resistance as one of many security profiles. Strong Authentication could be another one. 3) The RP should be able to request that one of more security profiles are used. Not all RPs will require a particular profile, so provides a nice security gradient. 4) The phishing resistant profile should be a URI, so that new ones can be created in the future. The profile would not state specifically how authentication was done, but would set a bar on what needed to be done to provide a level of assurance that the user had not been phished. As technology advances, new security profiles will likely be developed, which could then be deployed, advertised by the OP, and requested by RPs Summary of process: RP does discovery on OP to see if it supports the desired security profile. If the profile is not supported by the OP, then the RP may abort the transaction and provide the user with The RP expresses the desired security profile in the request. eg.: openid.sp.request=http://specs.openid.net/sp/phishing-resistant-A The OP executes on the desired security profile and states it has in the response. eg.: openid.sp.response=http://specs.openid.net/sp/phishing-resistant-A The RP checks the security profile in the response and proceeds accordingly. On 1-Feb-07, at 1:41 PM, Josh Hoyt wrote: Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis
RE: Proposal: An anti-phishing compromise
Rogue RPs can already go and find RPs out there and manually look to see which just use usernames and passwords. I don't see how providing this information actually makes the issue worse. I agree that it makes it more apparent, but I'd hope that it would scare users and get them to go use a better OP. An OP lying only hurts its users. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber Sent: Friday, February 02, 2007 5:01 AM To: specs@openid.net Subject: Re: Proposal: An anti-phishing compromise Recordon, David [EMAIL PROTECTED] schrieb/wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. What should the RP do with that flag? If they lock out users who are phishable, OP will simply start to lie about their non-fishability. The main problem, however, is that it actually adds to the phishing problem by providing rouge RPs valueable information about security risks. Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Per Kim's laws, how I authenticate to my OP is none of the RP's business. That I authenticated in a phishing resistant manner is. ie. we want the OP to make the statement that it followed certain anti-phishing guidelines. There is no certainty that the OP followed them, but the RP and user have recourse against an OP if the OP stated that it did follow the anti-phishing guidelines. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Recordon, David wrote: I think we all agree that talking about the method used is far more useful, though with this proposal we're really trying to balance it with simplicity in the authentication protocol itself. Maybe it is better to phrase the discussion around if the user provided a secret (password) to the OP or not to authenticate versus talking about phishing directly.?. If you were to define a URI for common authentication method values, could this value not be returned, simply, in the protocol? I'd hope that this parameter in the auth spec really helps bring the discussion around to the Assertion Quality Extension and that it be implemented to provide the more robust metadata such as what type of authentication was actually preformed. Agreed. If AQE is not mandated, however, I think that the original idea of allowing the OP to make a statement about the authentication method in the actual protocol is still a good one. If you start with a simple URI, returned directly in the protocol, can this not be linked to the equivalent statement in the AQE specification? - John --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of john kemp Sent: Thursday, February 01, 2007 7:13 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Granqvist, Hans wrote: Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Agreed. A statement as to the phishability or not seems to be too vague to be useful. A simple statement of the authentication method used would seem to give the same effect, while providing potentially useful information (assuming the RP trusts statements from the OP at all.) Benefits ... Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. How does the association step between OP and RP change the relationship between the OP and the user (agent)? I thought the attack we were considering is when a rogue RP directs the user agent to a rogue OP, who then steals the user's credentials? How is that affected by the rogue RP and rogue OP associating? - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Hi Josh, In addition to the protocol parameter that you have proposed, I'd hope that we can add something like what you wrote below as part of the security considerations section of the OpenID 2.0 Auth specification, as this text seems to capture quite succinctly the issues that RPs and OPs should be thinking about when attempting to deal with phishing: Josh Hoyt wrote: The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent It might also be helpful to add somewhere a specific definition of phishing, and the associated attack - that an OP can steal a user's credentials if they are passed to the OP. Mitigation can only really be performed by applying client-side changes that ensure that long-lived private information shared only between the OP and the user (such as a password) does not pass across the network. Regards, - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 7:05 AM, George Fletcher wrote: but I'm still not sure how this helps with the phishing problem. As you pointed out John, the issue is a rogue RP redirecting to a rogue OP. So the rogue OP just steals the credentials and returns whatever it wants. In this case, the rogue RP is not interested at in the the auth response from the rogue OP (or for that matter from the legitimate OP); just in stealing the user's credentials. The phishing field prevents the phisher to later use these credentials on a legitimate RP (which will be contacting the legitimate OP) to impersonate the user -- if the RP enforces phishable = no. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Johnny Bufu wrote: On 2-Feb-07, at 7:05 AM, George Fletcher wrote: but I'm still not sure how this helps with the phishing problem. As you pointed out John, the issue is a rogue RP redirecting to a rogue OP. So the rogue OP just steals the credentials and returns whatever it wants. In this case, the rogue RP is not interested at in the the auth response from the rogue OP (or for that matter from the legitimate OP); just in stealing the user's credentials. The phishing field prevents the phisher to later use these credentials on a legitimate RP (which will be contacting the legitimate OP) to impersonate the user -- if the RP enforces phishable = no. I guess I'm confused by the above. If the OP has stolen the user's credentials, it can just say phishable = no and pass its assertion regarding those credentials to the RP. This is about a rogue OP, and the relationship between the OP and the user, not really about the relationship between the OP and RP (although if the RP knew whether or not it could trust the OP by some out-of-band means, it would simply not accept an assertion from the OP unless that trust was established). You might use a rogue RP to start the attack, but the attack is actually performed by the rogue OP, not the rogue RP. - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 12:25 PM, john kemp wrote: If the authentication mechanism is phishable, a good OP is supposed to say phishable=yes. Otherwise it is cheating the user's trust. Yes, RPs will just have to trust assertions from an OP. But with all due respect, I just don't see how the honour system mitigates phishing. I guess we could argue about where we see the trust. I see it between between the user and the OP. The RP only trusts (or rather accepts) the user's choice of an OP (and the assertions coming from it as representing the user). Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That points to AQE, as David mentioned already. A browser plug-in, like sxipper, that uses a username and (a generated, non-user-visible) password internally and will only submit it to the correct OP can't be phished. Is this a different kind of authentication than password? I don't think so. Is it phishable? I think that the OP can reasonably say that it is not. Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
On 2-Feb-07, at 1:53 PM, Josh Hoyt wrote: Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. .. or, pushing it a bit further, I could ask/configure my OP to always issue phishable=no for me, because I am a power user, always watch the address bar, check certificates, make sure my machine is not compromised, etc. That's also fine, as long as the OP represents the user's interests. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Josh Hoyt wrote: On 2/2/07, john kemp [EMAIL PROTECTED] wrote: Don't get me wrong - I think it's a good idea for the OP to make a statement about the authentication method used (although I would prefer it to say something like authn_method=urn:openid:2.0:aqe:method:password, rather than phishable=yes). That points to AQE, as David mentioned already. A browser plug-in, like sxipper, that uses a username and (a generated, non-user-visible) password internally and will only submit it to the correct OP can't be phished. Is this a different kind of authentication than password? I don't think so. Is it phishable? I think that the OP can reasonably say that it is not. Therefore, I think that the authentication mechanism is (or at least can be) independent from whether the authentication channel is phishable. I will agree that the authentication channel might be separated from the authentication method, as you have described those concepts. I'm not sure if that's a meaningful distinction. For example - in Sxipper, does the password get moved across the network to the OP, or does Sxipper act as the OP (on the client side?) If the former, then I'd argue that Sxipper password auth is slightly less phishable, but not completely so. If the latter, then the trust is /really/ only between the RP and the user. - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
I'm in support of this idea. I think a single parameter in the OP's response will pave the path to integrate solutions to the phishing problem and scales up to the AQE extension as it is re-worked. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, February 01, 2007 1:42 PM To: OpenID specs list Subject: Proposal: An anti-phishing compromise Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
Hi Josh, do I understand correctly that the motivation for your proposal is not 'fix' the phish problem, but to simply hilite it so that RPs will begin to put pressure on their OPs to move to something beyond passwords? If this is the case, perhaps allowing an SP to add it to its request for authentication would give a direct (and loggable) mechanism by which the RP can provide feedback to the OP product managers? Thanks Paul Josh Hoyt wrote: Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-302-1428
RE: Proposal: An anti-phishing compromise
Josh, thanks for posting! See my comments inline -Hans ... Other relevant issues: ... * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) Is that entirely true? There is a flow in the OpenID protocol that is hardly ever used, the association flow, that can be used. Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Benefits The proposal is trivial implement, it acknowledges that But it's not trivial to deploy! Since the proposed solution fundamentally changes the basic authentication payload, every single implementation would have to change. Drawbacks - It may be tricky to define what is meant by non-phishable. And any such definition would probably change over time, too. ... My overall problem is that I don't see how your proposal really solves phishing. Am I crazy? (It has happened before ;) Perhaps you're only concerned with the OP/RP relation? Your proposal is based on the OP adding an extra field into its authentication response, but in a phishing scenario, this OP would never even be involved in the authentication step. Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. This information may contain the phishing strength field you define above, but it can also contain something like a security profiles. (Yes, here I go again ;) It just seems to make sense to do it this way. 1. OPs that want to remain like today, can do so by accepting non-associationed authentication requests, or by not requiring the meta-information in the association request. 2. OPs that want to provide a stronger user story would require the assoc step + meta-info. The OP now becomes its own gate keeper: only good enough RP's will have acceptable profiles (perhaps cryptographically signed by a 'trusted 3rd party', or asserted via other reputational mechanisms), and therefore these RPs are the only ones that can authenticate. 3. in the same vein, the RP would only redirect to acceptable OPs. The RP decides what is an acceptable OP just as the OP decides what is an acceptable RP. 4. the user would still be out in the cold unless it is impossible to log in as a side-effect of an authentication step (as previously discussed on the list). Perhaps that entire 'log in when authenticating' flow should be stricken from the spec unless user's explicitly desires that behavior via some mechanism (like added params to the URL -- ugly, or a checkbox next to the URL input field -- questionable). Anyway, just my thoughts. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
sorry, trying to straddle worlds/terminology OpenID SAML RP == SP (Service Provider) OP == IDP (Identity Provider) Josh Hoyt wrote: On 2/1/07, Paul Madsen [EMAIL PROTECTED] wrote: Hi Josh, do I understand correctly that the motivation for your proposal is not 'fix' the phish problem, but to simply hilite it so that RPs will begin to put pressure on their OPs to move to something beyond passwords? If this is the case, perhaps allowing an SP to add it to its request for authentication would give a direct (and loggable) mechanism by which the RP can provide feedback to the OP product managers? What's an SP as opposed to an RP? Josh -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-302-1428 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
I think that it is an excellent idea since it allows us to have it both ways. We can continue to offer backwards compatibility with legacy infrastructure without compromising the strength of the strongest schemes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, February 01, 2007 4:42 PM To: OpenID specs list Subject: Proposal: An anti-phishing compromise Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net
RE: Proposal: An anti-phishing compromise
I think we all agree that talking about the method used is far more useful, though with this proposal we're really trying to balance it with simplicity in the authentication protocol itself. Maybe it is better to phrase the discussion around if the user provided a secret (password) to the OP or not to authenticate versus talking about phishing directly.?. I'd hope that this parameter in the auth spec really helps bring the discussion around to the Assertion Quality Extension and that it be implemented to provide the more robust metadata such as what type of authentication was actually preformed. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of john kemp Sent: Thursday, February 01, 2007 7:13 PM To: Granqvist, Hans Cc: OpenID specs list Subject: Re: Proposal: An anti-phishing compromise Granqvist, Hans wrote: Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. The receiver should decide what is 'non-phishable', not the sender, so it would be better if the OP just states what mechanism was used, perhaps. Agreed. A statement as to the phishability or not seems to be too vague to be useful. A simple statement of the authentication method used would seem to give the same effect, while providing potentially useful information (assuming the RP trusts statements from the OP at all.) Benefits ... Here's what I think: Since the association step is hardly ever used, it can much more easily be overloaded with extra information without breaking any implementation. If the OP would *require* an OpenID association step from the RP, then this step can include an exchange of meta-information between OP and RP. How does the association step between OP and RP change the relationship between the OP and the user (agent)? I thought the attack we were considering is when a rogue RP directs the user agent to a rogue OP, who then steals the user's credentials? How is that affected by the rogue RP and rogue OP associating? - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
