We need a “/heartbleed.txt” standard, and we need it ASAP
blog.kamens.us
blog.kamens.us
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).
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.
That said, I don't see what problem you're solving or why the solution you propose should help.
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.
However, I disagree about YAML. I'd recommend a standard JSON or CSV.
"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.
I'm trying to understand what the workflow and incentives are here. Not every site operator is very security-savvy, and to a first approximation no users are.
The point of this proposal is mostly to enable sites to tell users that they _have_ been fixed (and when), not to tell users that they _haven't_.
Having said that, site operators pay to install valid SSL certificates from valid CAs because they know that if they won't, the browsers will increase the friction necessary for users to access their site.
If something like what I am proposing is widely adopted, then not patching their sites and notifying users that they have done so will similarly increase friction, so site operators will have an incentive to do it.
>Not every site operator is very security-savvy, and to a first approximation no users are.
The penetration of password management apps like LastPass continues to increase. The fact that many users do not choose to avail themselves of better security is no justification for not implementing better for security for the users who do.
If that were not the case then SSL would not exist.
It would have information like a unique security email contact, bounty for responsible disclosure and congratulations on a job well done.
These heartbleed attacks do scare me. They scare me enough that I get the feeling that resistance is futile. Changing your password on a few sites is not going to help when the opposition controls every bit of fiber between you and the website you're logging in on.
I do think that sites should disclose much more prominently when they were hacked. A few days ago there was the headline "Chrome inadvertently blocks wired.com". I think such a headline should be "Wired possible serving malware for a few hours yesterday". No "heartbleed.txt" hidden away, but a large banner across the top of the site: "We were hacked! Read more here! Update your virus scanners and scan your computer."
Something like:
https://www.linkedin.com/.well-known/password_revoke:
from: <datetime>
to: <datetime>
change_url: https://www.linkedin.com/sorry-we-lost-your-password-our-bad/
And then LastPass or 1Password or your browser or a plugin looking at credentials stored by your browser could routinely check sites where you have accounts, and say "Hey, LinkedIn says that your password is at risk and should be updated. Would you like to do that now?"
This is roughly equivalent to having LinkedIn send an email to all affected accounts (which is mandatory good citizenship, right?), but maybe will increase the success rate. It's another way for sites that have big embarrassing security breaches to try to do the right thing.
Possible downsides:
- Might teach users a behavior that makes them more vulnerable to phishing?
- More worryingly, if an attacker was able to MITM requests, they would be handed a list of every site where you have an account, and a way to affirmatively reach out and ask you for your password to those sites.
- Attackers might be able to detect the list of sites you have accounts at just by analyzing encrypted traffic. That could be valuable info on its own.
- An attacker who gained the ability to write to password_revoke (but no direct access to user data) could potentially escalate the attack by revoking everyone's passwords (although it's not clear to me how much more dangerous that would be than being able to write to password_revoke in the first place, and it might be a quick way to blow their cover).
Interesting idea anyway.
I'd extend that proposal to allow a CVE to be listed with a special token indicating "never vulnerable" (perhaps "1970-01-01T00:00:00Z" as the patched-at timestamp) and perhaps to allow a CVE listed with two timestamps indicating the range of time during which the site was vulnerable.
Saying we need it and we need it now is simply ridiculous.
Password in the URL with unencrypted HTTP is colossally dumb, but at least I have to either access your computer or at least snoop on its connection to take advantage of it.
Its developers were summarily bashed for this practice when seeking feedback (and rightly so).
Google's cache link doesn't seem to be working. Anyone else got a cache?
Edit: Ah, no, this seems to work now: http://webcache.googleusercontent.com/search?q=cache:blog.ka...
Trying to increase the number of servers but httpd isn't cooperating.
Worth setting it up - just in case :-)
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.
Patched: 0 and Vuln: 1 isn't really useful information for the user; if sensitive data is involved the site should take itself offline, not warn users. A time stamp indicating when a mess was resolved is all a user who cares needs to decide to create a new password.
I'm not saying what you propose is impossible; I'm just saying it's quite unlikely. Security is all about layers. You don't throw away a layer that could be effective at increasing security in the majority of cases just because there are some cases where it wouldn't work.
This new layer will make the security better for the average user, but it will enable attackers to make a website look falsely patched in a MITM attack.
(That leaves the question of how useful it is to users; I guess it is nice for a service like lastpass, but the truly paranoid probably aren't relying on cues from services)
No. No. No.
If you are going to propose something, why wouldn't you implement it.