Checksum, hashing and notification #220
Comments
Hyperpolymath
changed the title
|
would you prefer if I split that into the two parts (they both relate to newbie hackers engaging with the document, but there are two issues: OpenSignature verification for safe hacking And this is the thing I was referring to re extensions, but it is just one of them (again, if it is an extension, it will be more of an issue as some might some might not, whereas pushing towards a standard might be better. https://chrome.google.com/webstore/detail/yeswehack-vdp-finder/jnknjejacdkpnaacfgolbmdohkhpphjb - the extension, free https://www.yeswehack.com/ - the wider service/the company, if you are interested |
|
The existing RFC uses PGP signatures to protect against tampering, is there a reason why that doesn't work? See: Not clear about the other question - can you provide an example of what the field would look like and some of the possible values? |
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Just background
There is a risk that someone might tamper with email addresses/contact details such that it is routed to some cracker, or whatever might be in the security.txt file. Then someone comes along, thinking that is the correct one, send information on vulnerabilities to that]
There are increasingly extensions that make it much easier to know if there is a security.txt file, and if hacking for good reasons is welcome, and if someone is not wrapping up that info and just sending it in genuine belief but mistakenly to a competitor or to a hacker or even routed to something like Pastebin or Wordpress (site, forumm, mailing list, etc etc.) for direct posting online.
Describe the solution you'd like
A clear and concise description of what you want to happen.
The OpenPGP signature for the security.txt file is a good idea, so that the person could verify the integrity of the security.txt file. This could then be regularly checked, and in particular on file opening, or modification or replacement and flagged to the original address. That way of doing things would
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Really just the different SHA algorithms, and different places/options for where to put that for checking.
Perhaps this signing could be extended to cross-reference against the blockchain at intervals, or maybe ensuring it has some reference to the DS record value for the domain, or something about regular checking of signature automatically.
Or maybe there is a way to get the extensions that might do the verification automatically. I have used "Yes we hack!" to spot these sites automatically, but they do not do the checking just tell you if they exist and read the contents if do and say you can or cannot do it based on what is written in it.
Additional context
Add any other context or screenshots about the feature request here.
Perhaps this is done some other way, just seems quite useful dealing with increasing numbers of new people who know about it but inexperienced, admins of many sites who might not be paying attention, or users of sites who might want to be informed to make a decision about whether to get help over it.
Also, I did not see in the security.txt tool on your site that says YES or NO or TEMPORARILY NO or WITH EXPLICIT PERMISSION or ... whatever might be the intent of the site, and whilst likely it will be security policy it links to, might usefully appear as a flag of some sort in the security.txt thing (just one line with "permission to hack: [whatever value]", or a link to the vulnerability disclosure programme (VDP) maybe?
To some extent I think that VDP might better be part of the security.txt file, but I am not that radical, and sure that that's a bit extreme at this point.
Well, maybe something a bit better than that, but...
The text was updated successfully, but these errors were encountered: