TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

We need a “/heartbleed.txt” standard, and we need it ASAP

34 点作者 jik大约 11 年前

18 条评论

Spittie大约 11 年前
I&#x27;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&#x27;re at it, a standard that define what can go and what can&#x27;t go in a password. Every site has different rules, and sometimes those aren&#x27;t even listened. The worst I&#x27;ve seen was a site that allowed me to change my password, but refused the new password when trying to login).<p>I realize that this won&#x27;t happen, but hey, since we&#x27;re already dreaming about something that should get implemented by every site...<p>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).
评论 #7559716 未加载
timthorn大约 11 年前
One of the April Fool&#x27;s RFCs this year seems to have considered this issue, roughly: <a href="http://www.rfc-editor.org/rfc/rfc7169.txt" rel="nofollow">http:&#x2F;&#x2F;www.rfc-editor.org&#x2F;rfc&#x2F;rfc7169.txt</a>
clarkevans大约 11 年前
Your proposal may want to follow RFC 5785 aka &quot;&#x2F;.well-known&#x2F;&quot;<p>That said, I don&#x27;t see what problem you&#x27;re solving or why the solution you propose should help.
评论 #7559739 未加载
jzwinck大约 11 年前
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&#x27;t require any new smarts on the client side.
评论 #7559699 未加载
blauwbilgorgel大约 11 年前
I thought about a &quot;hackers.txt&quot; around the time &quot;humans.txt&quot; 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).<p>It would have information like a unique security email contact, bounty for responsible disclosure and congratulations on a job well done.<p>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&#x27;re logging in on.<p>I do think that sites should disclose much more prominently when they were hacked. A few days ago there was the headline &quot;Chrome inadvertently blocks wired.com&quot;. I think such a headline should be &quot;Wired possible serving malware for a few hours yesterday&quot;. No &quot;heartbleed.txt&quot; hidden away, but a large banner across the top of the site: &quot;We were hacked! Read more here! Update your virus scanners and scan your computer.&quot;
JackC大约 11 年前
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 &quot;if you created an account in this timeframe, you should change your password.&quot; Then there&#x27;s no need to specifically address which vulnerabilities existed when.<p>Something like:<p><a href="https://www.linkedin.com/.well-known/password_revoke" rel="nofollow">https:&#x2F;&#x2F;www.linkedin.com&#x2F;.well-known&#x2F;password_revoke</a>:<p><pre><code> from: &lt;datetime&gt; to: &lt;datetime&gt; change_url: https:&#x2F;&#x2F;www.linkedin.com&#x2F;sorry-we-lost-your-password-our-bad&#x2F; </code></pre> ... where the file must be requested only via https and the domains must match.<p>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 &quot;Hey, LinkedIn says that your password is at risk and should be updated. Would you like to do that now?&quot;<p>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&#x27;s another way for sites that have big embarrassing security breaches to try to do the right thing.<p>Possible downsides:<p>- Might teach users a behavior that makes them more vulnerable to phishing?<p>- 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.<p>- 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.<p>- 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&#x27;s passwords (although it&#x27;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).<p>Interesting idea anyway.
评论 #7560227 未加载
bitJericho大约 11 年前
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.
评论 #7559559 未加载
评论 #7559676 未加载
评论 #7559507 未加载
评论 #7559659 未加载
评论 #7559815 未加载
fuj大约 11 年前
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.
评论 #7559736 未加载
KhalPanda大约 11 年前
Well, it didn&#x27;t take HN&#x2F;Reddit long to hug that site to death...<p>Google&#x27;s cache link doesn&#x27;t seem to be working. Anyone else got a cache?<p>Edit: Ah, no, this seems to work now: <a href="http://webcache.googleusercontent.com/search?q=cache:blog.kamens.us/2014/04/09/we-need-a-heartbleed-txt-standard-and-we-need-it-asap/" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:blog.ka...</a>
评论 #7559593 未加载
bencollier49大约 11 年前
So sites ought to list their unpatched vulnerabilities? Erm?
评论 #7559727 未加载
Lockal大约 11 年前
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).<p><a href="https://tools.ietf.org/html/rfc7169" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc7169</a>
jwagner大约 11 年前
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.
评论 #7559704 未加载
mschuster91大约 11 年前
In theory, one could expand this standard to allow for <i>arbitrary</i> mass-hack information.
评论 #7559566 未加载
otikik大约 11 年前
No, we don&#x27;t.
mh8h大约 11 年前
Doesn&#x27;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.
评论 #7559896 未加载
评论 #7559939 未加载
dubcanada大约 11 年前
Yah just what we need more *.txt files in the root of your website!
评论 #7559830 未加载
SchizoDuckie大约 11 年前
<i>sarcasm mode on</i> Great idea. Let&#x27;s give attackers that have metasploit installed a shortlist of your current system status. <i>&#x2F;sarcasm</i><p>No. No. No.
评论 #7559789 未加载
jasonlotito大约 11 年前
<a href="http://blog.kamens.us/heartbleed.txt" rel="nofollow">http:&#x2F;&#x2F;blog.kamens.us&#x2F;heartbleed.txt</a><p>If you are going to propose something, why wouldn&#x27;t you implement it.
评论 #7559765 未加载