11 ms·
The “security.txt” proposal reached last step in the IETF process
- tareqak 7y agoI think it is great that this proposal is almost done getting through the process. I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords.
- Someone1234 7y agoIf you had a machine readable definition for what is allowed within a password, wouldn't it make more sense to put that close to the password entry itself (e.g. on the input element/page)? Having a site-wide definition seems like it would require a lot of mechanics to target specifc pages or properties that may have different rules (e.g. consumer Vs. corporate logins). I still hope companies start following NIST guidelines and stop having password rules entirely.
- linsomniac 7y agoI love this idea, though I'm not sure I want my password manager executing arbitrary regexes it finds on the Internet.
- saagarjha 7y agoIf you restrict it to “formal” regular expressions you’ll stay out of “arbitrary code executing on a Turing machine”.
- wahern 7y agoRegular expression engines are notoriously buggy. You definitely wouldn't want to pass random expressions to libpcre. Web browsers are already running random expressions from the internet, but their regex implementations have proven the rule by being fodder from exploit writers. In any event, requiring a password manager to pull the engine from Firefox or Chrome wouldn't be cool. They're more likely to use libpcre or re2, but see above. The NAPTR DNS record type uses regular expressions for domain rewriting: https://en.wikipedia.org/wiki/NAPTR_record https://en.wikipedia.org/wiki/NAPTR_record Not many DNS libraries support that record type as it adds alot of problematic bloat.
- saagarjha 7y agolibpcre is exactly the implementation I’m not talking about, because it supports too much. I think re2 doesn’t do backtracking, so it’s probably a better choice.
- wahern 7y agoYou can still easily blow up memory with unions, which makes it easy to lock up Linux, which notoriously performs poorly under memory pressure.
- ibly31 7y agoWouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. To save (potentially rate limited) requests, the ripper software could compare the regex against a candidate password and skip it altogether. It's like expressing in machine-readable form how many/which characters they can skip.
- hwbehrens 7y agoI would say in general, no. For a long time, American Express had something along the lines of `^[A-z0-9]{6,8}$`. Given a candidate string, evaluating even this extremely basic regex will take more time than comparing it against a hash table. I suppose you could flip it around and use it as a generator for an arbitrary dictionary, but then you'll run into memory limitations first. Plus, there's always the fact that an adversary can just, you know, go find the password requirements on the website and generate a matching regex themselves. Of course, if the regex is something like `^password$`...
- Beldin 7y agoIf you have the regex, you'd use it to generate candidate strings. Then, of course you don't have to check any more. For a more complex regex, you could resort to a simplified version (eg, with larger search space). But the space of all random strings is way too huge to just generate random bitstrings and hope they match the regex.
- Johnny555 7y agoWouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. If knowing the rules for acceptable passwords makes it significantly easier to brute force passwords, that sounds like more of an argument to not have those rules in the first place since it wouldn't take an attacker long to figure them out himself even if they aren't published. Hiding the password policy is a very weak form of security through obscurity. I guess it would make it easier to programmatically determine which websites have insecure passoword policies (like an alphanumeric passsword no more than 8 characters long), but the problem here is the password policy, not publishing the rules. Even the NIST recommends that sites stop requiring these arbitrary password rules as they don't actually improve password security: https://www.alvaka.net/new-password-guidelines-us-federal-government-via-nist/ https://www.alvaka.net/new-password-guidelines-us-federal-go...
- deleted 7y ago[deleted]
- mtmail 7y agoThere's a similar proposal to allow password manager to change passwords. https://mikewest.github.io/change-password/ https://mikewest.github.io/change-password/ (https://www.kryogenix.org/days/2017/02/24/a-standard-password-change-api/ https://www.kryogenix.org/days/2017/02/24/a-standard-passwor...)
- packet_nerd 7y ago> I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords. I disagree. Password "complexity" requirements need to die and instead every site's password regex should be `.{12,64}` and then verify it's not in the dictionary or a list of leaked passwords.
- all_blue_chucks 7y agoThe current thinking among the security community is that sites should allow all passwords that aren't found on a wordlist, so that would be one hell of a regex.
- edent 7y agoThere doesn't need to be a file. The HTML5 specification allows the password input to include a validation regex. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password#Validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- rahuldottech 7y agoFor the uninitiated: https://securitytxt.org/ https://securitytxt.org/ Original HN thread: https://news.ycombinator.com/item?id=15416198 https://news.ycombinator.com/item?id=15416198
- deleted 7y ago[deleted]
- blue_shirt 7y agoAt one point in time I believe there was also a discussion on why somebody was removing it from their site. I'm having a hard time finding it currently and remember it being for excessive contacts from people using automated tools to scan their site. Edit: Found it, https://news.ycombinator.com/item?id=19152145 https://news.ycombinator.com/item?id=19152145
- DyslexicAtheist 7y agothere is a draft (from November 27, 2019) that makes the presence of a disclosure policy (using security.txt) mandatory on gov domains: "Binding Operational Directive 20-01 Develop and Publish a Vulnerability Disclosure Policy" https://cyber.dhs.gov/bod/20-01/ https://cyber.dhs.gov/bod/20-01/ > Create a security.txt15 file at the “/.well-known/” path16 of the agency’s primary .gov domain. This file must include the Policy and Contact fields, as specified in the Internet-Draft.17
- nwcs 7y agoComments should be directed to the IETF last-call list via email: last-call@ietf.org List info: https://www.ietf.org/mailman/listinfo/last-call https://www.ietf.org/mailman/listinfo/last-call Guidance on the last call process: https://ietf.org/about/groups/iesg/statements/last-call-guidance/ https://ietf.org/about/groups/iesg/statements/last-call-guid... Archive of comments so far: https://mailarchive.ietf.org/arch/msg/last-call/aDZq1M-m4du-wN5b58puSQ_7y2M https://mailarchive.ietf.org/arch/msg/last-call/aDZq1M-m4du-...
- phkamp 7y agoMy first thought was "XKCD 463"
- _pmf_ 7y agoFrom a liability point of view, this only has downsides for a "target" company.
- arminiusreturns 7y agoI actually think this is a great proposal. I may start implementing it regardless.
- alasdair_ 7y agoAn interesting attack for any website that allows customers to choose their own string for use in the url would be to choose the name ".well-known" - I'm sure I've seen sites that take user input and create a folder based on that name. Similar to reddit.com/r/.well-known except as a top-level folder but I can't find a good example right now. Once that happens, they could put up a malicious security.txt file and get free security reports sent to an email of their choice.
- Dylan16807 7y agoMinimizing that risk is the entire point of .well-known. Instead of securing a hundred different magic URLs, everything goes into a single spot.
- DyslexicAtheist 7y agoyou can use CNAME records to mitigate this though https://github.com/securitytxt/security-txt/issues/91 https://github.com/securitytxt/security-txt/issues/91
- tialaramex 7y agoBut as you hint, r/.well-known does NOT in fact exist and you can't make it The /.well-known/ paths were reserved by RFC specifically because this doesn't really happen. You could _make_ a site with the defect you imagine on purpose and perhaps somewhere in the vast galaxy of sites there's already one that can be abused to do this, but they're vanishingly rare. To the point where I don't know of one even though I went looking. One reason this prefix would be expected to be especially rare is that dot directories are both illegal in Windows (though the NT kernel has no problem with them) and special in Unix systems (they're legal but they're treated differently because it was convenient) and so any developer or administrator working with file paths for their web server is likely to disable names starting with dot at about the same time they disable names starting with slash and other shenanigans which blow stuff up. Now of course a URL doesn't have to reflect a path on disk, but as soon as it doesn't we're talking about a slightly more clued in developer, maybe someone who has heard about security and thinks it might be a good idea.
- 7y ago
- disconnected 7y agoThis seems like a really poorly thought out proposal. From the draft's [1] intro, which provides motivation for the proposal: > When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly [...] Occam's Razor: they lack the channel to report those vulnerabilities because the company doesn't give a damn about security, not because of some hitherto unsolved technical difficulty. Companies that give a damn about security already have either a "catch-all" contact for security related things displayed on their contacts page, or have dedicated pages detailing what the hell you are supposed to do to report a vulnerability. Companies that don't give a damn will continue to not give a damn and will ignore your document, and will continue to suck at security until someone starts punishing them - monetarily - for such appalling behavior. But let's leave that aside for a moment. Researchers spot vulnerabilities. Need a way to report them. So what's the solution? Apparently, a text file with only one mandatory field... > 3.5.3. Contact > This directive indicates an address that researchers should use for reporting security vulnerabilities. The value MAY be an email address, a phone number and/or a web page with contact information. ...which contains... er... a catch-all contact for security related things and or a link to a contacts page detailing exactly what the hell you are supposed to do to report a vulnerability? sigh... But the real kicker is that that the standard doesn't even require that the contact information is up to date or valid: > 6.2. Incorrect or Stale Information > [...] Organizations SHOULD ensure that information in this file and any referenced resources such as web pages, email addresses and telephone numbers are kept current, are accessible, controlled by the organization, and are kept secure. In case the meaning of "SHOULD" is in question see RFC 2119 [2], but basically, they "strongly recommend" that you keep your contact information up to day - instead of, I dunno, REQUIRING it, since having a channel to properly report security vulnerabilities is the ENTIRE POINT of this exercise? /facepalm Are we really supposed to take this seriously? This is simply security theater. [1] https://tools.ietf.org/html/draft-foudil-securitytxt-08 https://tools.ietf.org/html/draft-foudil-securitytxt-08 [2] https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt
- velosol 7y agoIsn't this part of why postmaster and abuse addresses exist? Perhaps a WHOIS entry that was specifically for security issues?
- tptacek 7y agoI know Google, Facebook, and Github now have this, though Apple, Microsoft, Amazon, Stripe, and Square do not (to rattle off the other tech companies with huge security teams.) But I don't really get it. Why is this a good idea? As 'DyslexicAtheist related, if you put this page on your site, people will crawl for it and find you, and then kick off horrible automated scanners that generate bogus bugs on every site they check, and then submit bounty requests for them. Meanwhile: what serious tester would be impeded by not having this page to refer to, if you have a /security page on your main site, which you have to have anyways for this to work? Recall that most of the fields in security.txt are themselves just URL pointers. I also think the RFC itself is kind of funny. Do not rely on security.txt as authorization to test a site! it says, as if an RFC really had the authority to establish that, rather than an expensive court case in which both sides of the argument will have competing claims about whether testing was allowed or (the US default) not.
- cperciva 7y agoI agree with the concern about bogus reports from automated scanners -- Tarsnap gets a lot of those (run against the website, even though Tarsnap's bug bounties explicitly exclude the website!). I suspect that if this is useful at all, it's not for serious testers but rather for people who stumble across issues by accident. There are times when I've had to phone a number in whois to report a problem, because all of the contacts on a company's website went to customer support or marketing -- and there was one occasion when I didn't report something I noticed, because the whois was anonymized.
- oefrha 7y agoInterestingly this page started showing up in my server logs recently. I was actually thinking about putting one up but after reading your post I should probably think twice.
- mgalgs 7y agoRegarding the spam concern, from securitytxt.org: > Will adding an email address expose me to spam bots? > > The email value is an optional field. If you are worried about spam, you can set a URI as the value and link to your security policy.
- quotemstr 7y agoWhat's wrong with emailing webmaster@domain.tld?
- eru 7y agoTry mailing webmaster@google.com
- pmlnr 7y agoThat's google not being compliant. The fact that google does something in one way doesn't make it right.
- ShakataGaNai 7y agoWhere does that go? To whom? What do they do with it? In a lot of companies, any generic name email address probably goes to the trash, some group like customer service, an auto-responder that says "Sorry no" and sometimes to marketing. None of these help you. On rare occasion webmaster@ might get to someone who is useful and technical, but it might also be in a folder with thousands of other junk messages. A better guess would be security@ . But still, wouldn't it just be easier to have a standard place to lookup who or where to go to contact someone for security issues? oh yea... security.txt
- defanor 7y agoBoth "webmaster" and "security" are standardized in RFC 2142, so one should be able to contact those easily. It's indeed not what happens in practice most of the time, but not sure if throwing more standards at it is a good solution: if/when most of the online services will follow those, they'd probably follow different ones.
- superkuh 7y agoOkay. I implemented it on my main domain for kicks. I wonder how long until bots begin looking for it.
- jillesvangurp 7y agoI think this is nice but having this in and a lot of other meta data in a machine readable form would be nicer. You could also think of things like licenses a and copyrights. Technically, the problem this specification solves is making it easier to find security related metadata for projects that typically have this information already but just not an easy to find place. So, the next logical step would be making this machine readable so IDEs, project hosting websites, and other tools, can do the right things instead of having to parse files intended for humans with no consistently used syntax.
- sho 7y agoLooks pretty machine readable to me? This is the consistent syntax to be used.
- jillesvangurp 7y agoWas expecting something like a yaml or json file to be a good standard for this. It's nearly 2020, we should not be improvising text file formats in standards anymore. .txt screams intended for humans.
- sho 7y agoYou're thinking too short term. .txt far predates, and will far outlast, any standard du jour. I bet you wouldn't be so gung ho about security.xml. I really don't see the issue. robots.txt works just fine, and this is simply following in its highly successful footsteps. What you suggest is change for change's sake.
- technion 7y agoFor people discussing automated tools and noise, prediction: we will start seeing automated tools flagging "missing security.txt" as some sort of vulnerability and I will end up implementing it just to stop the noise. It feels like a lose-lose situation.
- cstuder 7y agoA list of all official .well-known files and paths: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml https://www.iana.org/assignments/well-known-uris/well-known-... Wikipedia knows some less official ones too: https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers https://en.wikipedia.org/wiki/List_of_/.well-known/_services...
- deleted 7y ago[deleted]
- yrro 7y agoEST is a new one to me, and yikes!
- mikeiz404 7y agoIf you’re looking for an example security.txt, you can have a look at https://www.google.com/.well-known/security.txt https://www.google.com/.well-known/security.txt. There is also this site which lets you create create a security.txt file by filling out some fields: https://securitytxt.org/ https://securitytxt.org/