RE: Symptoms vs. Causes
and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. Bank issues a SecurID token (or SD chip with onetime pad) and requires a six-digit PIN to be entered which cannot be reused. In order to get to the bank in the first place, user must enter a URL that is printed on their monthly statement. It changes every month and you may not use any other URL. So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. My bank requires my surname, a customer number that is not the account number, a 5 digit pin code typed in, and a challenge response where the challenge is two random letter positions from my secret word, and the response is two letter selections from two dropdown boxes. No protocols needed. It would be interesting if someone submitted a best practices draft for banking services over the Internet, which documented how banks could prevent, or avoid phishing. Such a draft could say something like, never send customers an email with URLs for a site which requires login. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Thu, 13 Sep 2007 12:21:48 +0100, [EMAIL PROTECTED] wrote: and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. Bank issues a SecurID token (or SD chip with onetime pad) and requires a six-digit PIN to be entered which cannot be reused. In order to get to the bank in the first place, user must enter a URL that is printed on their monthly statement. It changes every month and you may not use any other URL. Sorry, my fault for remembering to mention the constraint that you also don't have to carry a token around. Obviously, if people are prepared to carry tokens the problem is much easier. That said, this scheme is actually not very secure because it's susceptible to active MITM attacks on the connection to the bank. The schemes I mentioned are substantially more secure. So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. My bank requires my surname, a customer number that is not the account number, a 5 digit pin code typed in, and a challenge response where the challenge is two random letter positions from my secret word, and the response is two letter selections from two dropdown boxes. This is complicated, but actually not particularly phishing resistant-- something that is true of a lot of the mechanisms banks are currently adopting. First, it's vulnerable to the MITM attack mentioned above. Second, it doesn't take that many phishing attacks to extract most of the secret word. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. At the end of the day, phishing is a social problem, not a technical problem. It can't be solved by purely technical means. All technical solutions to phishing involve some form of behavior change. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. Remember, this is not like typical cryptography MITM attacks where the MITM receives an ecrypted stream and is able to decrypt it, modify it, and reencrypt it. In this case, the user asks the MITM to provide a web page and associated Javascript. While the look of this page will be identical to the bank's page, the functionality does not need to be identical. It can send everything cleartext to the MITM who them emulates the human user. To defeat MITM you need a secure channel, but how can you establish a secure channel to a human being who has already defeated the bank's security system by enlisting the phishing organization as their agent? I would rather see the focus of effort go to building simple embedded computer systems that one can plug into a USB port and rely on to establish an encrypted channel to the bank. That way, the human user does not play any significant role in establishing the channel of communication and cannot subvert the process. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Thu, 13 Sep 2007 16:14:47 +0100, [EMAIL PROTECTED] wrote: So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. (1) No, this technique is still easily phished by someone who impersonates the image map. (2) It's easy to write keyloggers that would capture mouse clicks. Nobody does it because the imagemap technique is not widely used. If it were, that would change. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. That's far from clear, but even if it were so, the phisher can force multiple trials on the same phishing email, as if you had mistyped, thus recovering significant portions of the secret word. And of course, this either requires multiple secret words or a strong password equivalent on the server side. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. I suppose it depends on what you mean by cleartext inputs. See: [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, A Convenient Method for Securely Managing Passwords, In Proceedings of the 14th International World Wide Web Conference (WWW 2005) [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
You are both wrong. Mouseclick loggers are commonplace. They have been around for at least four years, about six months after banks in Brazil started to use mouse based keyboards. Some of them capture the screen area round the mouse pointer at the time of the click. From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Thu 13/09/2007 11:27 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Symptoms vs. Causes At Thu, 13 Sep 2007 16:14:47 +0100, [EMAIL PROTECTED] wrote: So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. (1) No, this technique is still easily phished by someone who impersonates the image map. (2) It's easy to write keyloggers that would capture mouse clicks. Nobody does it because the imagemap technique is not widely used. If it were, that would change. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. That's far from clear, but even if it were so, the phisher can force multiple trials on the same phishing email, as if you had mistyped, thus recovering significant portions of the secret word. And of course, this either requires multiple secret words or a strong password equivalent on the server side. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. I suppose it depends on what you mean by cleartext inputs. See: [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, A Convenient Method for Securely Managing Passwords, In Proceedings of the 14th International World Wide Web Conference (WWW 2005) [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Eric Rescorla wrote: In the end 'phishing' is about UI and not protocols. Quite so. It's about both. We can severely limit phishing through the use of mutual authentication. The UI part is that whatever mutual authentication you use has to be both mandatory AND easy to use. The IETF has a responsibility in as much as we need to provide the protocol infrastructure that allows the UIs to be correct. IMHO it's not just our responsibility - W3C has a role to play, and so do the IEEE and the ITU in as much as today's smart cards aren't really that smart. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
The entire issue depends to some extend also on the communication model you have in mind. If you consider an approach that is closer to SAML or OpenID then the end host interacts with the identity provider directly. If you, however, focus on something that is close to the AAA model then the end host interacts with the service provider (who then relays the information it gets to the identity provider, i.e., AAA server). In the latter case the mentioned dictionary attack is more important since you obviously don't want to give your username/password away to an arbitrary entity. Still, there are obviously a number of solutions available to provide protection. Ciao Hannes Christian Huitema wrote: There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
I agree with Eliot and based upon what we know about phishing and UI, the more mandatory and automatic and easy to use you make the mutual authentication, and the less you leave to the user the better off you are. _ From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 3:59 AM To: Eric Rescorla Cc: ietf@ietf.org Subject: Re: Symptoms vs. Causes Eric Rescorla wrote: In the end 'phishing' is about UI and not protocols. Quite so. It's about both. We can severely limit phishing through the use of mutual authentication. The UI part is that whatever mutual authentication you use has to be both mandatory AND easy to use. The IETF has a responsibility in as much as we need to provide the protocol infrastructure that allows the UIs to be correct. IMHO it's not just our responsibility - W3C has a role to play, and so do the IEEE and the ITU in as much as today's smart cards aren't really that smart. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Christian Huitema wrote: There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. Well if we're going here then: (4) The chosen solution requires that I have to remember zero or fewer non-dictionary passwords Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
I think this discussion here is completely off base. It is thinking in terms of 1980s authentication protocol design where the relying party is the authentication authority. It is also attempting to solve a problem for a constituency that isn't here (Dan excepted) and has not been asked what its real requirements are. First need to separate the two so that the choice of authentication mechanism is a decision between the user and the authentication authority and the relying party's role is limited to deciding whether a particular authentication authority and mechanism are adequate for their needs. This means that we need to have a consistent mechanism wherby the relying party can route authentication queries to the appropriate authentication authority. In the case of a federated system where one credential can be used at multiple locations it means we need a discovery layer. We have no shortage of authentication protocols (SAML, WS-*, EAP, ct. ct.). We have a standard for a personal identifier. What we lack is a standard discovery mechanism. OpenID has several mechanisms that are designed to integrate into the infrastructure as it is. That and SRV appear to be very useful starting points. What has to be avoided at all costs is yet another meta-neogtiation layer to select the authentication protocol or for that matter more authentication protocols. From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Wed 12/09/2007 8:05 AM To: Christian Huitema Cc: ietf@ietf.org Subject: Re: Symptoms vs. Causes Christian Huitema wrote: There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. Well if we're going here then: (4) The chosen solution requires that I have to remember zero or fewer non-dictionary passwords Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 00:51:33 -0700, Christian Huitema wrote: There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. Well, I'm not convinced that this is in fact a requirement (I note it's not in Sam's document, not that I take that as gospel). That said, if you want this property, then it severely narrows the scope of possible solutions, more or less down to either ZKPP/PAKE protocols and to public key-based authentication using random (as opposed to password generated) keys. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 09:59:25 +0200, Eliot Lear wrote: [1 text/plain; ISO-8859-1 (7bit)] Eric Rescorla wrote: In the end 'phishing' is about UI and not protocols. Quite so. It's about both. We can severely limit phishing through the use of mutual authentication. This is one possible approach, but not the only one. In fact, it's one of my principal objections to Sam's document, so I'll refer you to my review here. The UI part is that whatever mutual authentication you use has to be both mandatory AND easy to use. And, of course, spoofing resistant, which is the major unsolved problem. The IETF has a responsibility in as much as we need to provide the protocol infrastructure that allows the UIs to be correct. As I noted in my review, we already have a number of protocols which potentially provide this functionality, including mutual authentication. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Eric, As I noted in my review, we already have a number of protocols which potentially provide this functionality, including mutual authentication. And I think looking at protocols without an understanding of how they are used and how they interact with the UI is just as wrong as attempting to fix the problem simply within the UI. You wrote that some mechanisms could be made to work. You might be right, but I'm not convinced. Someone actually has to write out how these mechanisms, such as challenge/response ARE made to work with a web browser and a transactional protocol, such that they also actually solve Eliot's Dad's probem (EDP ;-) of the user not shooting themselves in the foot by transmitting the same credential to multiple disparate relying parties (or authenticating services, if you will). That's fully in scope for this organization, btw. Or for W3C. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 16:20:09 +0200, Eliot Lear wrote: Eric, As I noted in my review, we already have a number of protocols which potentially provide this functionality, including mutual authentication. And I think looking at protocols without an understanding of how they are used and how they interact with the UI is just as wrong as attempting to fix the problem simply within the UI. You wrote that some mechanisms could be made to work. You might be right, but I'm not convinced. Someone actually has to write out how these mechanisms, such as challenge/response ARE made to work with a web browser and a transactional protocol, such that they also actually solve Eliot's Dad's probem (EDP ;-) of the user not shooting themselves in the foot by transmitting the same credential to multiple disparate relying parties (or authenticating services, if you will). None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Eric Rescorla wrote: None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. As I wrote, the problem is in both places. For one thing, TLS-PSK, SRP, and PwdHash all have the problem that they require some sort of secure interface on what is generally an insecure platform. What is needed is a way to modularize and isolate those authentication transactions. Sam claims it can be done in software - fine. What is the communication path to and from? What's the architecture? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 16:32:34 +0200, Eliot Lear wrote: Eric Rescorla wrote: None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. As I wrote, the problem is in both places. For one thing, TLS-PSK, SRP, and PwdHash all have the problem that they require some sort of secure interface on what is generally an insecure platform. Yes, but this is not a protocol problem, it's a UI problem--an unsolved one, I might add, but not an issue for the IETF. What is needed is a way to modularize and isolate those authentication transactions. Sam claims it can be done in software - fine. What is the communication path to and from? What's the architecture? Each of these approaches has a fairly obvious architecture. In fact, Digest, which I forgot to mention in my previous message, already has a pre-existing architecture, and PwdHash works with the existing architecture. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Erik, You have to put the two together. If we do, we find that we can solve the UI problem by taking authentication OUT of known insecure components. But that requires a protocol to that authentication component. If one exists, what is it? It requires process interactions. What are those? All of this needs to be written down IN THIS CONTEXT. The secure communication path must be capable of opaquely traveling through a host without knowledge of IP address, for instance. We've done stuff like this before, but not in this context. TLS depends on IP address. Oops. And then there's registration. Uyh. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Eric, Each of these approaches has a fairly obvious architecture. In fact, Digest, which I forgot to mention in my previous message, already has a pre-existing architecture, and PwdHash works with the existing architecture. You have to put the two together. ALL of the approaches that you mention fail given an insecure UI. NONE of them are likely to be applicable given a secure UI. What will be necessary is a secured channel from the authentication module of the user to the authenticating party. What is that? It's almost assuredly not going to include IP addresses. How will PSK-TLS work in such circumstances? What is the communication between the module and the browser? And add on top of ALL of that the UI and don't forget registration. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 16:58:12 +0200, Eliot Lear wrote: Erik, Eric. You have to put the two together. If we do, we find that we can solve the UI problem by taking authentication OUT of known insecure components. But that requires a protocol to that authentication component. If one exists, what is it? It requires process interactions. What are those? All of this needs to be written down IN THIS CONTEXT. The secure communication path must be capable of opaquely traveling through a host without knowledge of IP address, for instance. I have no idea what you're talking about here. This problem can be solved entirely in the client side software without any intervension on the wire or in the server, as PwdHash demonstrates [though of course one could argue that a superior protocol is needed.] What you're describing sound like secure software architecture issues, not protocol issues. We've done stuff like this before, but not in this context. TLS depends on IP address. TLS does not depend on IP address. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 17:08:05 +0200, Eliot Lear wrote: Eric, Each of these approaches has a fairly obvious architecture. In fact, Digest, which I forgot to mention in my previous message, already has a pre-existing architecture, and PwdHash works with the existing architecture. You have to put the two together. ALL of the approaches that you mention fail given an insecure UI. It depends what you mean by secure UI. If you mean unspoofable password entry prompt, that's one thing. If you mean client side software that's not susceptible to malware, keyloggers, etc., that's quite another. All the approaches I mention work just fine with the first class of secure UI--provided we knew how to build one that people could actually use. NONE of them are likely to be applicable given a secure UI. I don't agree with this assertion. What will be necessary is a secured channel from the authentication module of the user to the authenticating party. What's an authentication module? You seem to be assuming a particular system architecture that you haven't laid out. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Eric Rescorla wrote: What's an authentication module? You seem to be assuming a particular system architecture that you haven't laid out. Many others have. I myself did so in a USENIX Login: Winter Security issue some years ago. SubOS would be a software example. Potentially CardSpace could be made this way. Kerberos 5 is not far from this if you think of the authentication module being a KDC. Using today's vernacular, let this module be the identity provider and the authenticating service be a relying party. And finally, having a token or some sort of SmartER Card that can handle large numbers of credentials would all qualify as examples. I'm not ready to say which one is quite right, or if there is another. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
And I think looking at protocols without an understanding of how they are used and how they interact with the UI is just as wrong as attempting to fix the problem simply within the UI. You wrote that some mechanisms could be made to work. You might be right, but I'm not convinced. Someone actually has to write out how these mechanisms, such as challenge/response ARE made to work with a web browser and a transactional protocol, such that they also actually solve Eliot's Dad's probem (EDP ;-) of the user not shooting themselves in the foot by transmitting the same credential to multiple disparate relying parties (or authenticating services, if you will). None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Wed, 12 Sep 2007 11:27:07 -0400, Keith Moore wrote: And I think looking at protocols without an understanding of how they are used and how they interact with the UI is just as wrong as attempting to fix the problem simply within the UI. You wrote that some mechanisms could be made to work. You might be right, but I'm not convinced. Someone actually has to write out how these mechanisms, such as challenge/response ARE made to work with a web browser and a transactional protocol, such that they also actually solve Eliot's Dad's probem (EDP ;-) of the user not shooting themselves in the foot by transmitting the same credential to multiple disparate relying parties (or authenticating services, if you will). None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. nor I. but the first step in solving an unsolvable problem is realizing what you're up against. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
And one that W3C is currently working on. I am on the W3C Web Security Context call at this very minute. From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Wed 12/09/2007 10:20 AM To: Eric Rescorla Cc: ietf@ietf.org; Eliot Lear Subject: Re: Symptoms vs. Causes Eric, As I noted in my review, we already have a number of protocols which potentially provide this functionality, including mutual authentication. And I think looking at protocols without an understanding of how they are used and how they interact with the UI is just as wrong as attempting to fix the problem simply within the UI. You wrote that some mechanisms could be made to work. You might be right, but I'm not convinced. Someone actually has to write out how these mechanisms, such as challenge/response ARE made to work with a web browser and a transactional protocol, such that they also actually solve Eliot's Dad's probem (EDP ;-) of the user not shooting themselves in the foot by transmitting the same credential to multiple disparate relying parties (or authenticating services, if you will). That's fully in scope for this organization, btw. Or for W3C. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Its an IRTF issue at this point RE: Symptoms vs. Causes
I suggest people take a look at CardSpace before continuing this thread. I don't use username/password at all and it is one heck of a lot nicer to use than any system that does. I can in addition make use of a password, smart-token or OTP token but there is no need for a username. Kick this to the IRTF and start an interest/research group there if we are going to do anything. From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Wed 12/09/2007 11:39 AM To: Eric Rescorla Cc: ietf@ietf.org; Eliot Lear Subject: Re: Symptoms vs. Causes None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this problem--provided that the user actually uses the new authentication method and doesn't type his password into some Web form. But of course that's a UI problem, not a protocol problem. and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. nor I. but the first step in solving an unsolvable problem is realizing what you're up against. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes (was next step on web phishing draft)
Michael Dillon said: Personally, I would like to see some more criticism of the fact that this draft is about Phishing, a symptom of security problems, rather than about strengthening a weakness in Internet security. It is entirely possible to solve the phishing problem without strengthening the network, and possibly even introducing new weaknesses. Being too focused on one symptom is not a good way to approach security. Indeed, it is entirely possible that the solution to phishing lies with the banking system, not with the Internet or IETF. Phishing is not a problem only for the banking industry. We have discovered phishing websites on the Internet designed to mimic web authentication systems deployed at my University, obviously designed to steal our passwords. I certainly agree with attacking the cause rather than symptom. But a portion of Sam Hartman's draft is in fact dealing with a cause of the symptom. Namely the part that is trying to protect user credentials from disclosure to an unauthorized party -- by proposing to eliminate the near ubiquitous phenomenon of sending passwords over TLS to an application server. And using proper cryptographic authentication techniques that don't transmit long-lived passwords or keys over the network period. It's about time the IETF stood up and said that. And yes, I agree that a new properly designed version of HTTP Digest authentication might be one way to help. As well as the various zero knowledge protocols. Bernard Aboba said: So we need to think carefully about distinguishing symptoms from underlying causes. If we just focus on symptoms, we will be playing a game of Wack-a-mole. For example, the document states that anti-phishing measures MUST support passwords, yet with the increasing prevalance of key stroke logging malware, it is not clear to me that merely avoiding the sending of cleartext passwords over the wire is enough. We can have a discussion about whether long lived human memorizable passwords have a future. But we have to deal with the reality today. I suppose that some time in the distant future we might all be using public key authentication, carrying around our PKI credentials on smart cards, mechanisms to interface those cards to endsystems are commonplace, systems and federations of PKIs are ubiquitous, proper certificate revocation infrastructure is in place etc etc .. But we are very far from that world. If passwords altogether are eliminated, then I presume malware will just evolve to deal with it. So the whack-a-mole game will continue as usual. Users could be tricked into installing a trojan horse that captured their private key or logged the passphrase that they typed to unlock it. Should we be recommending non-reusable passwords or smartcards/tokens everywhere? At some level, you have to trust the software on your endstation. Even if you've protected your authentication credentials, not trusting endstation software means that you may not be able to conduct any private or sensitive tasks on it. I don't think this problem can be solved until we have radically more secure designs in both operating systems and applications. Even that may not be enough. --Shumon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Shumon == Shumon Huque [EMAIL PROTECTED] writes: Shumon And yes, I agree that a new properly designed version of Shumon HTTP Digest authentication might be one way to help. As Shumon well as the various zero knowledge protocols. I believe that http digest plus channel bindings does meet all the requirements that draft-hartman-webauth-phishing discusses for authentication systems. Clearly the protocol cannot define the UI issues. I'm not sure I prefer the approach of revising http digest, but I do believe it would meet the requirements of my draft. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
Actually, a fundamental problem with the current protocol is that there was little attention paid to the requirements of UI design experts. The natural result is that application developers worked with what they had to produce an interface usable by their average user. Any critique of the protocol or new protocal in this space MUST be consider interactive usage AND unattended program to program authentication. In the end 'phishing' is about UI and not protocols. Dave Morris On Tue, 11 Sep 2007, Sam Hartman wrote: Shumon == Shumon Huque [EMAIL PROTECTED] writes: Shumon And yes, I agree that a new properly designed version of Shumon HTTP Digest authentication might be one way to help. As Shumon well as the various zero knowledge protocols. I believe that http digest plus channel bindings does meet all the requirements that draft-hartman-webauth-phishing discusses for authentication systems. Clearly the protocol cannot define the UI issues. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
David Morris wrote: Actually, a fundamental problem with the current protocol is that there was little attention paid to the requirements of UI design experts. The natural result is that application developers worked with what they had to produce an interface usable by their average user. Any critique of the protocol or new protocal in this space MUST be consider interactive usage AND unattended program to program authentication. In the end 'phishing' is about UI and not protocols. +1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
[EMAIL PROTECTED] said: In the end 'phishing' is about UI and not protocols. +1 sorta, in that I feel this build on the above is appropriate.. In the end 'phishing' is about UI, and also about protocols, to the extent the latter influence and/or enable UI particulars. E.g. HTTP+HTML's direct enablement of form-based login, as well as HTTP's redirect capability, ... =JeffH ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes (was next step on web phishing draft)
I certainly agree with attacking the cause rather than symptom. But a portion of Sam Hartman's draft is in fact dealing with a cause of the symptom. Namely the part that is trying to protect user credentials from disclosure to an unauthorized party -- by proposing to eliminate the near ubiquitous phenomenon of sending passwords over TLS to an application server. And using proper cryptographic authentication techniques that don't transmit long-lived passwords or keys over the network period. It's about time the IETF stood up and said that. I agree with that. We can have a discussion about whether long lived human memorizable passwords have a future. But we have to deal with the reality today. Why is it an either/or? Can't we do both? My issue with was with saying that solutions MUST support passwords. I suppose that some time in the distant future we might all be using public key authentication... but we are very far from that world. Smartcards aren't the only alternative here. For example, folks in the KEYPROV WG make an argument that token authentication has the potential to become a mass market phenomenon. Should we be recommending non-reusable passwords or smartcards/tokens everywhere? Frankly, I think it would be best if the IETF would develop solutions compatible with a range of approaches, and let customers choose. Even if you've protected your authentication credentials, not trusting endstation software means that you may not be able to conduct any private or sensitive tasks on it. Right. But there's a difference between violation of privacy and being able to empty someone's bank account. It's a distinction that is worth making, and one which the current document is not clear about. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Tue, 11 Sep 2007 13:55:54 -0700 (PDT), David Morris wrote: Actually, a fundamental problem with the current protocol is that there was little attention paid to the requirements of UI design experts. The natural result is that application developers worked with what they had to produce an interface usable by their average user. Any critique of the protocol or new protocal in this space MUST be consider interactive usage AND unattended program to program authentication. In the end 'phishing' is about UI and not protocols. Quite so. There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes (was next step on web phishing draft)
Michael Dillon said: Personally, I would like to see some more criticism of the fact that this draft is about Phishing, a symptom of security problems, rather than about strengthening a weakness in Internet security. It is entirely possible to solve the phishing problem without strengthening the network, and possibly even introducing new weaknesses. Being too focused on one symptom is not a good way to approach security. Indeed, it is entirely possible that the solution to phishing lies with the banking system, not with the Internet or IETF. I think this is a very good point. Ultimately, the explosion of attacks that we are seeing is fed by the ability of miscreants to convert personal information into cash. Phishing is only one avenue for this - the miscreants have shown an ability to quickly develop new attacks and business models. So we need to think carefully about distinguishing symptoms from underlying causes. If we just focus on symptoms, we will be playing a game of Wack-a-mole. For example, the document states that anti-phishing measures MUST support passwords, yet with the increasing prevalance of key stroke logging malware, it is not clear to me that merely avoiding the sending of cleartext passwords over the wire is enough. In terms of underlying causes, the ease with which personal information (social security number, bank account #s, birthdate, etc.) can be utilized for identity theft and subsequent fraud is sobering. A sampling of recent stories in the news: http://www.identitytheftdaily.com/ http://www.forbes.com/feeds/ap/2007/08/16/ap4027723.html http://www.schneier.com/blog/archives/2005/08/identity_thief.html http://mortgagefraud.squarespace.com/journal/2004/4/7/id-theft-leads-to-charges-for-six-amerifunding-scheme.html http://www.usdoj.gov/usao/pae/News/Pr/2006/jul/whitesmith_release.pdf http://www.courant.com/news/custom/topnews/hcu-mortgage-0828,0,3482889.story http://money.guardian.co.uk/scamsandfraud/story/0,,1669152,00.html While I'm willing to accept that many of these stories originate in fundamental weaknesses within the financial system, I'm not so sure that the IETF has no role to play with respect to development of technology that could help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
