Hacker News Reader

So the way to fix this is to get involved and write some software instead of commenting in a forum as if software is a static problem. Why not open a bug report? Maybe we can prevent password reuse by the browser taking a hash of the password being entered in a form and comparing it against other password hashes locally?

The lack of a proposed solution does not make the identification of a problem worthless. Writing code is as much part of the process of solving problems with software as identifying those problems is. When a problem is largely a social one, rather than a technical one, identifying the problem and making people aware of its existence is often the bigger part of the process.

Tor guarantees anonymity. It succeeds at that. There is no technical problem. There is no code to write. This could lead you to think there's a problem with scope, that maybe Tor should guarantee security too. Unfortunately, the design of Tor is not compatible with that goal: if your plain text data goes through an exit node, then by definition, that exit node gets to see what the data is. A bug report titled "Tor does not provide secure communication" would get closed faster than you can say "won't fix". And rightfully so.

There is, however, a social problem, as stated by the OP: many people actually expect security. This is a problem that can only be solved by educating as many people as possible that this is the wrong expectation to have, which is what the OP is contributing to by making this post. This is very much in the spirit of "if you think it should be done, do it".

> Tor guarantees anonymity. It succeeds at that.

Doesn't it fail at anonymity if the entire internet is being monitored?

I fails to see how HTTPS Everywhere + a nag whenever a form is detected on a HTTP page doesn't make this a complete non-issue. OP is not giving Mozilla any credit.

If OP has ever used Tor, he would know that the performance hit is so huge, that no-one in there right mind is going to leave it on by default, if that's even an option. In OPs myopic view, he's missing the fact the the added benefit built in anonymity to all FF Users far outweighs this hypothetical security risk.

>Tor guarantees anonymity.

No it does not, it is always best to use a seperate browser for tor because your browser & OS fingerprint is significant

https://panopticlick.eff.org/index.php?action=log&js=yes

And that is ignoring the fact that most people will continue to login to the HN and facebook accounts.

Maybe we can prevent password reuse by the browser taking a hash of the password being entered in a form and comparing it against other password hashes locally?

Won't work. People have too many accounts to be able to remember unique passwords. A large percentage of mundane users won't understand these things and will just be nagged all the time that they cannot log into their accounts with this new Firething.

We could warn "this is the same as site X which is HTTP". If it's a throw away, that is fine. If it's not, that might matter.

When you enter your password into an input on a page served over HTTP, it is already game over.

Not if you use a throwaway, crappy password, that you do not care gets compromised.

Your proposal, as it stands, doesn't warn the user until /after/ they've typed a non-throwaway password into a site served over http.

You'd need to warn them before they even start typing a password in on an http page.

Ideally yes, but almost no sites send passwords as they are typed. The only likely situation where that would be a problem is if the site itself is compromised, in which case nothing can save you.

Not just a site compromise; a path compromise (malicious exit node, shady ISP, or fake WiFi access point) can inject Javascript in an unencrypted page. CA-signed SSL with cert pinning prevents MITM injection.

You could do that. As you type into any <input type="password"> the browser would buffer the text and not send it through to the DOM immediately. When you hit enter, leave the field, submit the form, etc then it'd get sent through to the DOM where it'd be available to (potentially malicious) javascript. While the password is in the buffer the browser could check for "non-throwaway password + http" and block it if need be.

This does require the browser to know which passwords are which, though, at which point it might as well be entering them for you (and only being willing to do that over https).

What percentage of internet users do you think know what "HTTP" means?

Good point. I would guess 40%.

Really? I would guess substantially less than 1%.

Google did some videos asking the general public what browser they use (before they released Chrome). It might be informative for you.

Then force unique passwords without requiring the users to remember them, something which is both easier for users and more secure.

Perhaps the browser should present a warning dialog anytime you connect to a site over TOR, without using SSL?

You are still making a connection through an unknown third party host, which kind a negates the encryption on the last part of the journey.

The thing is that I doubt anyone is actually running a malicious server that would login to your honeypot as soon as it gets your credentials, at least I would let the username/password list collect for couple of months before checking it and even then I wouldn't blindly hit everything.

But the thing is that thous TOR exit points (just like Proxies) can inject all kinds of JS on the sites they display and while some people run NoScript or similar browser extensions most do not.

And giving out your username/password combinations for scriptkiddies and criminals and allowing them to run any JS on sites you visit does hell of a lot more short term damage than any government surveillance, losing all of your possessions in an identity theft or just getting phony bills is way worse for your average consumer than having their Facebook chat logged.

Tor is a good tool when used properly, but slapping it on to everything isn't what the tool was made for.

> Maybe we can prevent password reuse by the browser taking a hash of the password being entered in a form and comparing it against other password hashes locally?

I always thought that one possible way around this would be for websites to generate the passwords for their users, essentially forcing them to use some sort of password storage (either in the browser, or LastPass, or whatever-you-want). So one would register with just an email address/username and then be shown a generated password à la O5O1zn8H3zEGNjf1Ly8v to store in the browser’s password manager.

Of course, this only works if people only ever use the service from devices they own and I have absolutely no idea how common internet café/public library users are nowadays.

Also, plenty of bad services out there that restrict passwords in lots of different terrible ways.

Is that similar to using something like OpenID, where you sign into the authentication service, then one by one authorize the identity to log you into services?

It seems like a more modular approach than using Facebook or Google to sign into third party sites, but similarly secure in terms of exposing passwords.

I don’t think it has much to do with OpenID – my suggestion still keeps the classical username/password tuple as credentials, but simply disallows the user to choose the password freely.

One extension, of course, would be for websites to somehow signal to browser ‘Hey, please store this password/username for this website’, but I’m not sure whether that's necessary.

>So the way to fix this is to get involved and write some software instead of commenting in a forum as if software is a static problem. Why not open a bug report?

It cuts both ways. I don't understand why you meta-comment, instead of going fixing those things yourself.

It's a little bit different on that side. Telling others to go fix things, if you succeed, is better than (just) doing it yourself. I can donate money to charity, but let's say my budget (and in other scenarios equate budget to time, or skill, or whatever) is £100/month, if I donate that and tell others to donate, then maybe I can have a £1000/month impact.

Whereas if I'm just telling people "this is no good, it needs fixing" then not only am I not helping, I'm not persuading other people to help either.

I see that as merely double standard.

The main premise is wrong too: "if I'm just telling people "this is no good, it needs fixing" then not only am I not helping, I'm not persuading other people to help either.".

Lots of things that are no good NEED to be pointed out. Project members don't magically see all of them.

Either because they don't have that particular use case themselves, or because they haven't thought it that way, or they think it's not important but the users think otherwise, or they have invested too much in some design that they cannot admit it's flawed, etc.

Pointing things out helps making those flaws visible, helps start a discussion, makes the opinion of potential or actual users known, etc etc.

Telling people to go and help is very secondary to that. I don't think many people ever got motivated because of some second-hand meta-comment from someone not even involved in the project.

You're absolutely right - when I commented I was thinking purely in terms of "you shouldn't tell others to get involved, you should be getting involved yourself", I didn't stop to think about the pros or cons of the original comment.

As for doing more harm than good: I can't possibly see how this does more harm than NSA domestic surveillance.

How about false sense of security? Zero improvement in security plus baseless confidence that you are now secure sounds like a step backwards to me! It's already suspected that NSA has been working around Tor for years now. Wasn't there an article recently stating that the NSA (or was in the CIA...?) control 2/3 of Tor exit nodes?

Lastpass does something like that - it warsn about identical passwords, though of course it actually has the plaintext, but a hash would work fine as well.