3 ms·

I agree that this experiment isn't demonstrating a perfect mitigation, but it's important to appreciate that it's currently vastly easier for a phisher to permu

I agree that this experiment isn't demonstrating a perfect mitigation, but it's important to appreciate that it's currently vastly easier for a phisher to permute paths and subdomain components than it is to create a convincing ETLD+1. There are various reasons for this, including less text for a phisher to work with and registration requirements for ETLD+1 domains (which means they can't be iterated and dumped as quickly, and domain owners may have a more immediate legal recourse against phishers). That's the point of experimenting on features like this, to get an idea of whether or not the they would be beneficial.

AlisdairO 12y ago
I don't know if such a thing already exists, but perhaps a way for a user to define 'secure urls' that go to their bank (or other important site) would be useful. Chrome could then warn when a user goes to a site that looks too similar.
altcognito 12y ago
What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857 https://twitter.com/aripalo/status/462942544007929857 The issue isn't users recognizing path, it's the domain. It's also that they aren't taking special care while logging in. Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page. On the whole, supporting secure logins would be better for the internet.
- odonnellryan 12y ago
  The problem with that is you can't detect all login forms. If you cannot detect all of them, there's a way to hide them from the browser.
- justinschuh 12y ago
  > What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857 https://twitter.com/aripalo/status/462942544007929857 The team may choose to do something like that in the end. That's really the point of experimenting with different approaches; they use them to get feedback, run user studies, and get a sense of what works best. > Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page. That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.
  - tmzt 12y ago
    You could detect forms that have more than one user provided input field as they are submitted. This wouldn't detect most search boxes or forms that use hidden inputs to transmit values to the backend.
  - ghayes 12y ago
    But `input[type="password"]` would cover the majority of login forms. At the least, it would force the con-artist have to mimic a native password box, which is more likely to get caught by the end-user.
    - nodata 12y ago
      Yes. Anything that doesn't use a password field is normally a giant hack anyway.
    - nyrina 12y ago
      So facebook's mobile login page wouldn't trigger, for example. It's not as simple as peolpe think of it. It never is.
  - altcognito 12y ago
    > That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics. Well, it wouldn't have to detect all login pages, it could just detect most of them. That would add soft pressure to encourage regular websites to use HTTPS in the vein of https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere Hopefully we can push the web towards https everywhere, and users begin to ask the question -- "Why is this page not secure" when performing a login. This soft pressure worked wonders in a number of places: When Google started doing sitelinks, many websites became much more concerned about making those available on their website. In a similar way, hopefully they would be concerned with getting out of the red for their login pages.
  - baddox 12y ago
- handsomeransoms 12y ago
  > Additionally, what about addressing insecure forms that fail to utilize https. FWIW, Firefox detects insecure login forms and emits a security warning to the web console. This is aimed at developers, however, not users (because the developers are the only ones who can improve the situation). Our heuristic is imperfect as well. We simply detect <input type="password"> fields on http pages. This works well enough. Trying to detect when developers are abusing <input type="text"> for a password field is non-trivial.
  - cpeterso 12y ago
    How long has Firefox been logging security warnings (in the web console) for insecure login forms? Do you know of telemetry about how prevalent the problem is or whether the security warnings have helped? I assume, for compatibility, Firefox will never be able to simply reject insecure login forms.
    - Excavator 12y ago
      It looks like it's been around half a years¹. There's also a reference to the Chromium bug² for implementing the same there. There's also mixed content blocking³ which is a similar but user facing feature. 1: https://bugzilla.mozilla.org/show_bug.cgi?id=762593 https://bugzilla.mozilla.org/show_bug.cgi?id=762593 2: https://code.google.com/p/chromium/issues/detail?id=327032 https://code.google.com/p/chromium/issues/detail?id=327032 3: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
- sergiosgc 12y ago
  I'd say that is the best solution, possibly with more work done on the certificate button left of the url. The button currently highlights “good“ sites: https with an Extended Validation certificate. It should be the other way around. Highlight as warning when the site falls short: no SSL or SSL without EV.
- tempestn 12y ago
  I really like that. Preserves all the benefits of hiding the path entirely without... hiding the path entirely. However, how would the browser tell the difference between editing the path and entering an entirely new url or search? It wouldn't be intuitive if you have to click the domain chip to go to a different site. Most of the time a user is going to click the path area in that screenshot, since that's what we're used to. But then, how do you edit just the path?
  - davros 12y ago
    One solution would be that if you click any part of the url and you get fully editable text so you can change the domain or any part of the path.

AlisdairO 12y ago

I don't know if such a thing already exists, but perhaps a way for a user to define 'secure urls' that go to their bank (or other important site) would be useful. Chrome could then warn when a user goes to a site that looks too similar.

altcognito 12y ago

What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857 https://twitter.com/aripalo/status/462942544007929857 The issue isn't users recognizing path, it's the domain. It's also that they aren't taking special care while logging in. Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page. On the whole, supporting secure logins would be better for the internet.

odonnellryan 12y ago
The problem with that is you can't detect all login forms. If you cannot detect all of them, there's a way to hide them from the browser.
justinschuh 12y ago
> What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857 https://twitter.com/aripalo/status/462942544007929857 The team may choose to do something like that in the end. That's really the point of experimenting with different approaches; they use them to get feedback, run user studies, and get a sense of what works best. > Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page. That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.
- tmzt 12y ago
  You could detect forms that have more than one user provided input field as they are submitted. This wouldn't detect most search boxes or forms that use hidden inputs to transmit values to the backend.
- ghayes 12y ago
  But `input[type="password"]` would cover the majority of login forms. At the least, it would force the con-artist have to mimic a native password box, which is more likely to get caught by the end-user.
  - nodata 12y ago
    Yes. Anything that doesn't use a password field is normally a giant hack anyway.
  - nyrina 12y ago
    So facebook's mobile login page wouldn't trigger, for example. It's not as simple as peolpe think of it. It never is.
- altcognito 12y ago
  > That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics. Well, it wouldn't have to detect all login pages, it could just detect most of them. That would add soft pressure to encourage regular websites to use HTTPS in the vein of https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere Hopefully we can push the web towards https everywhere, and users begin to ask the question -- "Why is this page not secure" when performing a login. This soft pressure worked wonders in a number of places: When Google started doing sitelinks, many websites became much more concerned about making those available on their website. In a similar way, hopefully they would be concerned with getting out of the red for their login pages.
- baddox 12y ago
handsomeransoms 12y ago
> Additionally, what about addressing insecure forms that fail to utilize https. FWIW, Firefox detects insecure login forms and emits a security warning to the web console. This is aimed at developers, however, not users (because the developers are the only ones who can improve the situation). Our heuristic is imperfect as well. We simply detect <input type="password"> fields on http pages. This works well enough. Trying to detect when developers are abusing <input type="text"> for a password field is non-trivial.
- cpeterso 12y ago
  How long has Firefox been logging security warnings (in the web console) for insecure login forms? Do you know of telemetry about how prevalent the problem is or whether the security warnings have helped? I assume, for compatibility, Firefox will never be able to simply reject insecure login forms.
  - Excavator 12y ago
    It looks like it's been around half a years¹. There's also a reference to the Chromium bug² for implementing the same there. There's also mixed content blocking³ which is a similar but user facing feature. 1: https://bugzilla.mozilla.org/show_bug.cgi?id=762593 https://bugzilla.mozilla.org/show_bug.cgi?id=762593 2: https://code.google.com/p/chromium/issues/detail?id=327032 https://code.google.com/p/chromium/issues/detail?id=327032 3: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
sergiosgc 12y ago
I'd say that is the best solution, possibly with more work done on the certificate button left of the url. The button currently highlights “good“ sites: https with an Extended Validation certificate. It should be the other way around. Highlight as warning when the site falls short: no SSL or SSL without EV.
tempestn 12y ago
I really like that. Preserves all the benefits of hiding the path entirely without... hiding the path entirely. However, how would the browser tell the difference between editing the path and entering an entirely new url or search? It wouldn't be intuitive if you have to click the domain chip to go to a different site. Most of the time a user is going to click the path area in that screenshot, since that's what we're used to. But then, how do you edit just the path?
- davros 12y ago
  One solution would be that if you click any part of the url and you get fully editable text so you can change the domain or any part of the path.