Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security.txt

securitytxt.org

Post reply on HN
Print view View original

41–50 of 148 posts

Re: Security.txt

#41

Post by JosephRedfern »

irrational wrote: post #17
fbnlsr wrote: post #11

I think humans.txt ( http://humanstxt.org/ ) fits more, and already exists.

I've never heard of this. I wonder how many websites implement this. I tried a bunch of sites, but the only one I could find that had a humans.txt file was google: Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us…

I do! https://redfern.me/humans.txt

It should really be human.txt...

Re: Security.txt

#43

Post by baby »

mjw1007 wrote: post #9

Should surely be .well-known/security.txt, or if not explain why not. rfc5785 "Defining Well-Known Uniform Resource Identifiers (URIs)" [edit: I see the FAQ says that, while the linked Internet Draft says it goes at top-level like robots.txt]

Ahhh. That explains why lets encrypt does it!

Re: Security.txt

#45

Post by BillinghamJ »

s17n wrote: post #36
ikeboy wrote: post #21

If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.

Enables automated vulnerability disclosure.

Nobody wants this. Automated disclosure means getting even more automated-scan reports. Total waste of time.

Re: Security.txt

#46

Post by bzbarsky »

dreamdu5t wrote: post #22

As an operator of many websites... I don't want more emails from "Security Researchers" who want $100 to tell me the obvious such as, "Login form should be rate-limited" or "emails can be enumerated using password reset form" and the like... Instead, we should have a central vulnerability repository that is open-source, standardized, public, and transparent. This repository should vet vulnerability reports before con…

On the flip side, such a vulnerability repository may not have incentives aligned with either the bug reporter or the software owner. See https://palant.de/2017/10/04/observations-on-managed-bug-bou... for a recent post about that sort of problem.

Re: Security.txt

#47

Post by r3bl »

thephyber wrote: post #38
ikeboy wrote: post #21

If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.

The more you use a Google feature as a crutch, the less the web is semantic. Also, Google has increasingly made it difficult to automate searches, so the effort required to notify multiple websites increases quickly.

> Also, Google has increasingly made it difficult to automate searches

That's an understatement. Doing something as simple as

    inurl:"humans.txt"
...and consuming the first three pages showed me CAPTCHA. It was done via a browser, manually. Not all links were clicked.

Re: Security.txt

#48

Post by JetSpiegel »

s17n wrote: post #36
ikeboy wrote: post #21

If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.

Enables automated vulnerability disclosure.

The data behind this is not machine readable anyway, what's the gain here?

Re: Security.txt

#50

Post by jlgaddis »

dmix wrote: post #29
bkeroack wrote: post #26

The first thing every attacker will do: replace security.txt

Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites... Changing things is how you get detected. Much like that recent thread where John Kelly brought his phone in to IT because it wouldn't update and they found malware. That's an obvious failure in any "APT" hackers guide. This isn't like modifying .bash_history to hide malicious behaviour…

> Attackers don't do things that overtly "change" things... especially something that is visually apparent on public facing websites...

Yet, for many, many years, that was probably the most common thing that attackers (including a much younger, teenaged version of yours truly) did. At that time, however, "defacing" web sites was done mostly for bragging rights and without malicious intent. In many (most?) cases, the original index.html page would be copied/backed up and the "new" web page (created haphazardly using vi, perhaps) would replace or augment it.

For a long time, there were even mirrors [0] of these defaced web pages. attrition.org ran one from 1995-2001 and, for much of that time, even ran a mailing list where they would announce these "defacements" -- often, immediately after they occurred (after being tipped off by the attackers). It was pretty common to be able to view the "still defaced" site while it was still live (before being taken down and/or restored). As a frame of reference, attrition.org stopped mirroring these sites in May 2001 [1].

> ... it will no longer mirror the defacements because keeping up with the volume and rate of hacks is too much work ... ([1])

So, yeah, it happened A LOT. It is, of course, a much different world now (although defacements still occur regularly).

[0]: http://attrition.org/mirror/

[1]: https://www.computerworld.com/article/2582627/security0/attr...

Post reply on HN