31–40 of 121 posts
I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinction without a difference.
Earlier quoted context omitted.
> Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable. This is not safe! Now an attacker just needs to intercept the hashed password and replay that, and he gets to login without knowing what the password is. Use h…
> Use https. And don't do client-side hashing, it's no improvement. Well, it's an improvement if your users are reusing their passwords. Then multiple different sites will have different hashes sent. But that's all besides the point, we should've been using zero knowledge proofs for authentication since the beginning.
Wow, this is still even a thing. The form, all its js assets and form api endpoint all have to be secured. And https for everything that contains code. Deploying SRI for web pages over https is also another layer of defense against js tampering. Also, sending passwords across the wire in any reversible manner is really more dangerous than is necessary. Passwords/passphrases could be salted hashed by the browser in Ja…
Not the worst idea from the developer's point of view, but it doesn't protect the user: the site could still serve bad JavaScript which didn't properly hash the password (this, for example, is why Mozilla accounts are completely, totally and utterly insecure, and why Firefox password storing should never be used by anyone who doesn't wish to share his passwords with Mozilla, any Mozilla employee and any state which can compel any Mozilla employee). The browser needs to natively support doing this.
There's also the issue of replays. This topic has been well-studied; I believe that Secure Remote Password (SRP) is currently the gold standard for this.
I wish they outlined a plan to push this icon out to Stable. Even better the plan should call for the browser to eventually refuse to submit forms with password fields unless HTTPS was used for both loading the form and submitting it. I think that developers who are still using HTTP with passwords either don't understand the implications (and a tiny icon won't help), don't care, or don't have "management buy-in" to s…
Browser should display a scary warning popup when submitting form to http (either always, or maybe at least when there is input type=password in a form). This would be annoying enough to get management buy-in to implement https, if someone still maintains the app - better than a tiny icon. Breaking stuff is a last resort, nuclear option. There are many forgotten, old web apps that would totally stop working and peopl…
But it was removed in later versions of Netscape and Internet Explorer, because everyone turned it off as soon as they made their first search engine query.
> If you’re submitting your login form over HTTPS, that’s good, but it’s not enough. You have to deliver* the form over HTTPS too.* I'm glad they mentioned it. Too many people think their sites are secure if logged in sessions use https and everything else is http. Their example is that an attacker could insert JavaScript to steal the password, however they could just as well change the form target from https to http…
For too long popular a lot of popular gambling sites such as betfair and skybet have done this. I think betfair now is all https, but I'm not sure of skybet (and I can't be checking while at work).
Plaintext HTTP is scary stuff these days.
I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…
If the cookie is set through HTTPS, the browser won't send it when loading HTTP resources. So the cookie won't be exposed that way.
We should still be using HTTPS for all traffic in 2016.
I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…
I don't understand the distinction between the login form and every other page of the site. If someone is logged in and then back to normal http, someone can just grab the cookie and pretend to be that person already-logged-in. I suppose if one uses the same password for every account they have then knowing their password is more harmful than just having access to 1 site... but other than that it seems like a distinc…
Earlier quoted context omitted.
Browser should display a scary warning popup when submitting form to http (either always, or maybe at least when there is input type=password in a form). This would be annoying enough to get management buy-in to implement https, if someone still maintains the app - better than a tiny icon. Breaking stuff is a last resort, nuclear option. There are many forgotten, old web apps that would totally stop working and peopl…
They used to -- see http://www.kentlaw.edu/faculty/rwarner/classes/legalaspects/... (§2.4, about half-way down) and http://labs.ft.com/2014/05/do-we-really-need-to-hide-the-url... But it was removed in later versions of Netscape and Internet Explorer, because everyone turned it off as soon as they made their first search engine query.
Today there should not be "do not display this anymore" checkbox.