http://blog.kamens.us/heartbleed.txt
If you are going to propose something, why wouldn't you implement it.
We need a “/heartbleed.txt” standard, and we need it ASAP
21–30 of 51 posts
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#22A useful alternative could be for password managers to periodically (and on creation) check ssl certs, store them, and then check for revocation (periodically or on demand). That would be general, useful (I guess) and it would not require any new standard.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#23If a site knows it may have been compromised, it could simply force users to change their passwords on the next login. There is precedent for this (Adobe is one I recall), and it doesn't require any new smarts on the client side.
Great, and how do the users keep track of which of the hundreds of sites they use have done that? With the idea I'm proposing, it's possible to automate this _in the client_, such that users can proactively defend themselves against sites that haven't patched themselves or even indicated whether they were ever vulnerable in the first place.
"Do you want to visit this web site? It may by vulnerable to the CVE-2014-0160 (a.k.a. 'the Heartbleed bug')." or the like.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#24I'd rather have an universal api to change my password on every service, this way I could just batch-change all my passwords from something like Keepass in a matter of seconds, instead of having to waste some hours to change everything, while figuring a different ux on every site (and while we're at it, a standard that define what can go and what can't go in a password. Every site has different rules, and sometimes those aren't even listened. The worst I've seen was a site that allowed me to change my password, but refused the new password when trying to login).
I realize that this won't happen, but hey, since we're already dreaming about something that should get implemented by every site...
Anyway, as someone already said, in an hypothetical world this should be useless, as if a site is vulnerable it should get fixed ASAP, and force a password change to every user. And in the real world, almost nobody would check the hearthbleed.txt file (yes, software like lastpass and keepass could check for the user, but a very small % of the internet use such software).
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#25A useful alternative could be for password managers to periodically (and on creation) check ssl certs, store them, and then check for revocation (periodically or on demand). That would be general, useful (I guess) and it would not require any new standard.
That requires keeping a huge amount of state and doing a lot more complicated programming then just checking a few fields in a YAML file.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#26I'd rather have an universal api to change my password on every service, this way I could just batch-change all my passwords from something like Keepass in a matter of seconds, instead of having to waste some hours to change everything, while figuring a different ux on every site (and while we're at it, a standard that define what can go and what can't go in a password. Every site has different rules, and sometimes t…
It's obviously going to be a lot easier to convince maintainers of web sites with wildly varying stacks to drop a plain-text file into the root directory of their site, then it is going to be to convince them to implement a universal password change API.
If Mozilla, Microsoft, and Google added support for /heartbleed.txt to their browsers then a whole lot of people would check it. Even if not, if password managers are modified to check it, and this leads to even a minor increase in the penetration of the user of password managers by users of the internet, that would be a good thing.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#27Your proposal may want to follow RFC 5785 aka "/.well-known/"
That said, I don't see what problem you're solving or why the solution you propose should help.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#28So sites ought to list their unpatched vulnerabilities? Erm?
Well, yes, frankly, they should. ;-)
Frankly, it doesn't matter whether they do or not, because if a vulnerability is known and there are exploits for it in the wild, then hackers are simply going to try to exploit it, not check /heartbleed.txt.
Aside from all that, sites who don't have the courage to list their unpatched vulnerabilities can simply only list the ones that are already patched.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#29Basically, make everything easier for script kiddies by decreasing the amount of time they take to scan a host for the vulnerability. Weighting the pros and cons... the cons completely crush this idea.
You can already run a script that does the test in mere milliseconds. Whatever else the merits of this proposal, don't pretend avoiding it keeps you safer.
Re: We need a “/heartbleed.txt” standard, and we need it ASAP
#30Your proposal may want to follow RFC 5785 aka "/.well-known/" That said, I don't see what problem you're solving or why the solution you propose should help.
>Your proposal may want to follow RFC 5785 aka "/.well-known/"
This is addressed in a comment below the blog posting.
>That said, I don't see what problem you're solving or why the solution you propose should help.
I don't know how to explain it better than I already have. Sorry.