Hacker News new | past | comments | ask | show | jobs | submit login

The last time this came up on HN it got quite a negative review from someone who had tried it on several sites: https://news.ycombinator.com/item?id=19152145

It apparently attracted automated scanners and the signal to noise ratio was atrocious.




People here dislike HackerOne, but afaiu it solves this exact problem. It's the first line of ‘support’ for security reporters.

The fact that the industry currently needs this kind of solution is absurdly comedic. Basically, it would make actual sense to require people to pay ten bucks when posting a report—if they think the report is reasonable and that they would get paid for it.


It’s a good platform, but it really doesn’t solve the time-sink problem, even if you pay for triage services. Triage can knock down well-known patterns of bogus stuff, but so can you; the real problem is the truly wacky stuff people come up with.


I can see and read the JavaScript source code if I intercept the requests! Please pay me $100.


Hi @fractionalhare, apologies for the spam but I am trying to read a post you made a few months ago on implementing Exp [1] but it seems the site is down. Is there a different source perhaps? Many thanks for your time.

[1] https://www.pseudorandom.com/implementing-exp


I'd never enter in a paid interaction without some sort of escrow that will make sure I'm not screwed over for the crime of being a good citizen. The victim could just keep the cost of the report without ever refunding. Innocent people will keep getting caught by this even long after the company acquires a reputation for never providing refunds.


Since the escrow sees your report, it sounds like HackerOne.

HO will just create paid tiers where for a smallish subscription price, people actually take your reports seriously.


Smart contracts on Ethereum blockchain... force them to set a date to pay you and go public. They can't back out.

Going to need a lot of work in the next few years to make something like this viable, but ETH could make it possible


Are you saying that Eth can somehow withhold info until a future time when it automatically becomes public? How would that work?


Ethereum has a Turing complete programming language inside


Yeah so? Think about it. How do you make a blob of data unreadable by people on Thursday but readable on Friday? You can't do it without a trusted third-party.

If Eth has a solution for this, it would mean it basically solves trust in general, which is a persistent pain in all of infosec.


posting your email in a not easily parsable way can save you a lot of spam. (rot13 it, break up characters, etc). Atleast that should cut most of the spam. This might be not standard, but I do not really see why we would need security.txt to be parsable by robots.


I just use GNUPG and encrypt it.


encrypt with my private key?


security.txt is a flag that you may have a bug bounty program, and as a result are a potential source of revenue.

It is time arbitrage between big companies taking security seriously (willing to pay large bounties) and that amount being higher than a monthly or yearly wage in some internet-connected regions. If they throw enough nets into the sea all year, eventually one pays off and they end up living quite well.


What does it mean when I enabled this on my personal (for fun) websites years ago on a whim? I don't have a bug bounty program.


Putting all of these files at root is going to be like have old rusty cars and stained mattresses in front of your house years from now.

The web is not a junkyard.


The proposal is to place the file at /.well-known/security.txt.

And even if it wasn't, there is plenty of namespace room to put every file someone argues for in a 2-page RFC at root. After all, there are only 1024 low-numbered TCP ports and we haven't run out of those yet.


Don’t get me wrong; I dig file-based interfaces, but each time they add another file, it’s another request.

And it’s Anglocentric to continue to unnecessarily put multiple English words into the path; those can’t be touched-up with a later RFC to support Japanese in the file content via a Lang attribute.

The whole thing is shit bad, I’m sorry. Just come up with something that makes fucking sense for once.


Trap them with a honeypot: disable HSTS and automatically delete all messages containing "HSTS" string.


Does this work?


This would be my concern. It seems like a really good tool to attract the attention of bad actors.


The Contact field can point to a landing page.

> A link or e-mail address for people to contact you about security issues. Remember to include "https://" for URLs, and "mailto:" for e-mails

Using a landing page should improve the signal/noise ratio. Google, for example, points to a landing page [0] and GitHub points to their HackerOne profile.

[0]https://g.co/vulnz

[1]https://hackerone.com/github




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: