

We need a “/heartbleed.txt” standard, and we need it ASAP - jik
http://blog.kamens.us/2014/04/09/we-need-a-heartbleed-txt-standard-and-we-need-it-asap/

======
Spittie
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).

~~~
jik
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.

------
timthorn
One 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)

------
clarkevans
Your 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
>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
Your 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.

------
jzwinck
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.

~~~
jik
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.

~~~
jzwinck
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.

~~~
jik
>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.

------
blauwbilgorgel
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."

------
JackC
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.

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
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.

------
bitJericho
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.

~~~
jik
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.

~~~
Navarr
This 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.

------
fuj
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.

~~~
fennecfoxen
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.

------
KhalPanda
Well, 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.ka...](http://webcache.googleusercontent.com/search?q=cache:blog.kamens.us/2014/04/09/we-
need-a-heartbleed-txt-standard-and-we-need-it-asap/)

~~~
jik
Sorry. My blog doesn't usually get this much traffic. ;-)

Trying to increase the number of servers but httpd isn't cooperating.

~~~
edent
I 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
We use CloudFlare at work, but I had not previously foreseen the possibility
that it might be needed for my blog.

------
bencollier49
So sites ought to list their unpatched vulnerabilities? Erm?

~~~
jik
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.

------
Lockal
There 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)

------
jwagner
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.

~~~
jik
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.

------
mschuster91
In theory, one could expand this standard to allow for _arbitrary_ mass-hack
information.

~~~
jik
Yeah, I added an update to the bottom of the posting mentioning the
possibility of generalizing it.

~~~
maxerickson
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.

~~~
jik
I could live with simplifying the proposal to just list CVE numbers and
timestamps.

------
otikik
No, we don't.

------
mh8h
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.

~~~
jik
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.

~~~
mh8h
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.

------
dubcanada
Yah just what we need more *.txt files in the root of your website!

~~~
icebraining
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.

------
SchizoDuckie
_sarcasm mode on_ Great idea. Let's give attackers that have metasploit
installed a shortlist of your current system status. _/ sarcasm_

No. No. No.

~~~
jik
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.

------
jasonlotito
[http://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
The blog doesn't appear to be served by HTTPS, period.

