I tried to comment on the blog with something about a time stamp is all you need for the general case (and maybe some urls giving more information about the situation).
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.
Biggest ever hole? Really? Am I the only one that remembers Yahoo placing passwords in the URL of unencrypted pages? I remember having to erase the URL line when people were around for fear of leaking my password.
I hardly think that a security hole, no matter how large, at a single web site, is on the same magnitude as one security hole that probably impacts the majority of web sites on the internet and could have been taken advantage of completely invisibly for years.
Is that really bigger? Heartbleed meant that I, sitting comfortably in my home, could hit up yahoo.com and grab your credentials without being anywhere near your computer, or any of the data your computer sends or receives.
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.
My point is that there have probably been hundreds of these types of events going back to the ancient times of the internet. The sky is not falling guys, just a good downpour.
My point is that heartbleed is unique in its combination of severity and scope. Something like 25% of all the web servers on the internet could have their most private data extracted for a period of two years. The sky isn't falling, but I can't think of anything else that comes close. Vulnerabilities that affect individual sites, while still really bad, still don't approach this.
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.
If 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.
What site operator would install something which turns users away? Users will just click OK anyway, and if there is no OK button, users will decide their client is broken and go back to using Internet Explorer.
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.
>What site operator would install something which turns users away?
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.
You do know that a URL doesn't have to map to a particular path in the filesystem, right? You can load the resource's representation from anywhere you want.
Basically, 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.
A 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.
I'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).
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.
As others have pointed out, if they have metasploit installed they're just going to scan your site for all known vulnerabilities in a matter of minutes. Making it easier for the good guys to find out whether you've patched Heartbleed is not going to make things any easier for the bad guys.
I thought about a "hackers.txt" around the time "humans.txt" got popular. It would be stored not in a publicly accessible location, but in a location where finding it would mean a data leak (private web folder, users.sql).
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."
Doesn't heartbleed let an attacker hijack the keys? Then they can man-in-the-middle the connection, and spoof the file so that the website appear to be not vulnerable to the attack.
MITM attacks require far more sophistication and many more moving parts than just stealing data from a web server's memory. Just because you have the SSL cert's key doesn't mean you have the ability to use it to MITM a site.
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.
Of course. You can't MITM all the traffic to the site. But if hackers are targeting a certain security-conscious user, this standard will give them another tool!
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.
There can be a useful communication of "passwords older than X should be changed" to the user. Blocking that doesn't make the user any worse off than simply not having it.
(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)
Since the point of this proposal is to inform password managers (or other user agents) that a password needs to be changed, a slightly different approach could be to specify "if you created an account in this timeframe, you should change your password." Then there's no need to specifically address which vulnerabilities existed when.
from: <datetime>
to: <datetime>
change_url: https://www.linkedin.com/sorry-we-lost-your-password-our-bad/
... where the file must be requested only via https and the domains must match.
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).
I'm wondering if this is too specific. The other alternative proposal that someone floated in response to my proposal -- a file containing just CVE numbers and timestamps for when the site was no longer vulnerable to each of them -- seems more generalized and covers more than just passwords.
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.
50 comments
[ 229 ms ] story [ 1008 ms ] threadPatched: 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.
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.
"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.
If you are going to propose something, why wouldn't you implement it.
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.
No. No. No.
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."
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)
Something like:
https://www.linkedin.com/.well-known/password_revoke:
... where the file must be requested only via https and the domains must match.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.
https://tools.ietf.org/html/rfc7169