3 ms·
A proposal for better security with domain names: The domain name system has been around for decades and it's a clever and proven system. It can – and should b
by masswerk 8y ago
A proposal for better security with domain names:
The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want.
Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. This could be addressed by a) going back to codepages (Unicode subranges) and defining a valid subset for each range, and b) enforcing a domain name (hostname and domain) to be in a single codepage. Clients should derive the codepage by the Unicode range and generate a codepage-identifier, which may be displayed as a badge, identifying the respective range. And, of course, any mixed domains should be regarded illegal and invalid. (We may even want to make this codepage-identifier a mandatory particle of any URI, preceding the hostname.)
- deleted 8y ago[deleted]
- wongarsu 8y ago>enforcing a domain name (hostname and domain) to be in a single codepage this is essentially what is already implemented in most browsers. You can't mix characters from different scripts in a domain name, except for special cases (e.g. japanese and latin are frequently used together and have little potential for confusion)
- masswerk 8y agoHowever, these are just "anti-phishing" heuristics. We really should apply a rule on this.
- UncleMeat 8y ago> Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. No way. The most sincere problem is that hostnames do not enforce any binding to a real world identity that users can understand (nobody inspects certs) and that the most trustworthy component of a hostname is the second to the last section (right before ".com"). Humans tend to look at the front of the URL, making "www.bank.evil.com" a mind bogglingly effective phishing technique. Homoglyphs are almost always a sign of bad behavior and can just be banned to a large degree. The fact that "foo.com" or "foo.evil.com" are not necessarily owned by company foo is much worse.
- masswerk 8y agoRegarding the parsing of URLs, this is a common, but mostly counterintuitive argument: Take for example names in most western countries, addresses (street-zip-city-country), etc. Most of our most important identifiers work this way. Regarding lacking binding of identity: On the other hand, this has been one of the most important features of the web, from the very beginning. Also, there is no way to setup a system, which will attribute to a single person in a readable and intuitive way. (E.g., names fail to do so.) Arguably, this should be left to (optional) extensions. I'd argue, the knowledge required to parse a URI safely may be conveyed in couple of minutes. Why not enforce this knowledge? Why not have a URL-parsing note on the start screen of any browser? Why dumb down the system and introduce ambiguity – and by this even more insecurity – instead of educating users? URL-parsing is a vital skill, which can be acquired in less time than memorizing a basic table of partial addition results. Why do we still try to teach addition, if we can't teach URLs?
- deanCommie 8y agoExcept this is already broken by multi-part TLDs. foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"
- masswerk 8y agoOn a higher level, all those considerations are about a single question: Is the Web about communication (then it's probably OK as it is), or about a viable business platform with an entry-level as low as it can be? Who's without interest may throw the first stone, er, browser extension.
- lalaithion 8y agoThe best security change we could make, imo, is rewriting domains so that they look like com.evil.bank.www/now/urls/go/from/most/specific/to/least
- travem 8y agoYou're in good company. Tim Berners-Less said something similar when reflecting on what he would do differently if given the chance: > Looking back on 15 years or so of development of the Web is there anything you would do differently given the chance? > "I would have skipped on the double slash - there’s no need for it. Also I would have put the domain name in the reverse order - in order of size so, for example, the BCS address would read: http:/uk.org.bcs/members. The last two terms of this example could both be servers if necessary." From http://www.impactlab.net/2006/03/25/interview-with-tim-berners-lee/ http://www.impactlab.net/2006/03/25/interview-with-tim-berne...
- pvorb 8y agoHow about displaying an identicon, that is rendered from the domain, in the address bar? People might soon learn what the icons of their important sites look like and will easily detect if somebody is trying to phish their bank account.
- masswerk 8y agoWe might even call it "favicon", for the fun of it… :-)
- kba 8y agoAny fake-Facebook website can copy Facebook's favicon, so that wouldn't add any security at all. An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.
- amygdyl 8y agodeliver the Favicon from a USPTO server, and I think you should nail the most amazing proportion of fraudsters, overnight.
- mrec 8y agoNot sure if serious, but no. Anyone can copy a favicon; the point of an identicon is that it's generated from the domain name, so subverting it would require an attacker to find a hash collision with a visually similar domain.
- masswerk 8y agoSorry, I mistook "that is rendered from the domain" for "rendered from a resource from the domain". However, teach users to read domain names! If users do not grasp the general concept, e.g., if the supposed identity is just "example" (possibly with some decoration considered insignificant) and not "example.com", how are they supposed to survive? Domains have been around for more than a quarter of a century, the Internet is actually part of our lives… There is no excuse, and there is no sense in pretending that there was no harm in not understanding the basics. That said, there are real ambiguities that have to be addressed.
- Biqh1 8y agodo you have any examples of school class materials which teach stuff like this? I'd be really interested to read through them.