5 ms·
We need a “/heartbleed.txt” standard, and we need it ASAP
- mschuster91 13y agoIn theory, one could expand this standard to allow for arbitrary mass-hack information.
- jik 13y agoYeah, I added an update to the bottom of the posting mentioning the possibility of generalizing it.
- maxerickson 13y agoI 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.
- jik 13y agoI could live with simplifying the proposal to just list CVE numbers and timestamps.
- timthorn 13y agoOne of the April Fool's RFCs this year seems to have considered this issue, roughly: http://www.rfc-editor.org/rfc/rfc7169.txt http://www.rfc-editor.org/rfc/rfc7169.txt
- bitJericho 13y agoBiggest 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.
- mschuster91 13y ago...WHAT?! Did they use <form method="get"> for their login forms?
- _pmf_ 13y agoRelax. They have now switched to "post", and everything is just fine.
- jik 13y agoI 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.
- Navarr 13y agoThis is a silly, unnecessary standard that will probably not be implemented by anyone. Saying we need it and we need it now is simply ridiculous.
- mikeash 13y agoIs 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.
- bitJericho 13y agoMy 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.
- mikeash 13y ago
- KhalPanda 13y agoWell, it didn't take HN/Reddit long to hug that site to death... 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.kamens.us/2014/04/09/we-need-a-heartbleed-txt-standard-and-we-need-it-asap/ http://webcache.googleusercontent.com/search?q=cache:blog.ka...
- jik 13y agoSorry. My blog doesn't usually get this much traffic. ;-) Trying to increase the number of servers but httpd isn't cooperating.
- edent 13y agoI use CloudFlare (https://www.cloudflare.com/ https://www.cloudflare.com/) on my blog - handles even the largest load HN has thrown at it. Worth setting it up - just in case :-)
- jik 13y agoWe use CloudFlare at work, but I had not previously foreseen the possibility that it might be needed for my blog.
- bencollier49 13y agoSo sites ought to list their unpatched vulnerabilities? Erm?
- jik 13y agoWell, 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.
- jzwinck 13y agoIf 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.
- jik 13y agoGreat, 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.
- jzwinck 13y agoWhat 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.
- jik 13y ago>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.
- JackC 13y agoSince 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. Something like: https://www.linkedin.com/.well-known/password_revoke 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/ ... 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.
- jik 13y agoI'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.
- dubcanada 13y agoYah just what we need more *.txt files in the root of your website!
- icebraining 13y agoYou 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.
- fuj 13y agoBasically, 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.
- fennecfoxen 13y agoYou 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.
- otikik 13y agoNo, we don't.
- jasonlotito 13y agohttp://blog.kamens.us/heartbleed.txt http://blog.kamens.us/heartbleed.txt If you are going to propose something, why wouldn't you implement it.
- ceejayoz 13y agoThe blog doesn't appear to be served by HTTPS, period.
- jwagner 13y agoA 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.
- jik 13y agoThat requires keeping a huge amount of state and doing a lot more complicated programming then just checking a few fields in a YAML file.
- Spittie 13y agoI'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).
- jik 13y agoIt'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.
- clarkevans 13y agoYour 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.
- jik 13y ago>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.
- dismiss22x 13y agoYour end-comment about /vulnerabilities.txt is a better solution than a /heartbleed.txt as this will not be the last such vulnerability. However, I disagree about YAML. I'd recommend a standard JSON or CSV.
- SchizoDuckie 13y agosarcasm mode on Great idea. Let's give attackers that have metasploit installed a shortlist of your current system status. /sarcasm No. No. No.
- jik 13y agoAs 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.
- blauwbilgorgel 13y agoI 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."
- mh8h 13y agoDoesn'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.
- jik 13y agoMITM 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.
- mh8h 13y agoOf 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.
- maxerickson 13y agoThere 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)
- Lockal 13y agoThere is already an X.680 extension to indicate that secure connection might be wiretapped (for slightly other reason, but the result is the same). https://tools.ietf.org/html/rfc7169 https://tools.ietf.org/html/rfc7169