201–210 of 529 posts
Earlier quoted context omitted.
You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).
and if said "compromised" server simply decides to not supply the js that hashes the password?
As others have mentioned, nearly the entire internet breaks without javascript - it's a sad state of affairs. One protection I like to use is to disable javascript that is loaded over plaintext http - this breaks nearly nothing, and is easy to do via Chrome settings: https://i.imgur.com/NRVg5Xf.png
ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss…
> Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses Why is it not sufficient simply to throttle logins at the server?
Throttling by IP address may have worked 10 years ago, unfortunately it's not an effective measure anymore.
Modern cred stuffing countermeasures include a wide variety of exotic fingerprinting, behavioral analysis, and other de-anonymization tech - not because anyone wants to destroy user privacy, but because the threat is that significant and has evolved so much in the past few years.
To be entirely honest, I'm kinda surprised Google didn't require javascript enabled to log in already.
How is this nonsense upvoted on hackernews..?
This is a completely reasonable business decision and trade-off.
Earlier quoted context omitted.
I switched to Fastmail years ago and it was the best mail-related thing I ever did. I was dreading the migration but it literally took ten minutes, switch DNS records (I have my own domain), run Fastmail's import, done. I still can't believe how fast the UI is. It's by far the fastest web app I've ever used, and the same goes for the service in general. Seriously, just ditch Gmail now, the alternatives are great.
Gmail is more than just mail, it's also integration with other Google services, like calendar. How does Fastmail fare in that regard?
Earlier quoted context omitted.
It stops them from using the password to log in to your other accounts. It stops a compromised server from silently leaking unhashed passwords. It makes password hashing user auditable. You could even do a call and response model to stop the hashed password to log in at all. Here is a primitive scheme for such a model (public key crypto probably enables more clever schemes, not sure): - Upon signup, generate hashes o…
> It stops a compromised server from silently leaking unhashed passwords If you trust the site to deploy correct JavaScript to do this, then that's the same level of trust that they implemented password salting and hashing server side. You don't gain any robustness by moving this to JavaScript. Your scheme is just a weak salting technique. You'd be better off with just using a longer salt and hash function.
I can trust the site to deploy the correct javascript more than I can trust it not to steal passwords because
- That is auditable - it is impossible for a malicious site to do so without risking being caught.
- The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss…
It's still under-esitmating.
Earlier quoted context omitted.
Throttle based on what? IP address? This works for domestic IT departments looking to shut out automated attempts from specific ranges but at Google's scale IP based filtering could end up shutting out an entire country.
Which country uses a single IP address for all its devices/citizens?
ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. They're probably right that not running JS is privacy accretive, but only if you consider their individual privacy, and not the net increase in privacy for all users by being able to defend accounts against cred stuffing using JS. The privacy loss…
XSS vulnerabilities are everywhere. You obliviously don’t realize that. Note that I do use js, because it makes life easier. But you got to realize that not using js will at some point protect you against an XSS vuln. They are that prevalent.
Earlier quoted context omitted.
It stops them from using the password to log in to your other accounts. It stops a compromised server from silently leaking unhashed passwords. It makes password hashing user auditable. You could even do a call and response model to stop the hashed password to log in at all. Here is a primitive scheme for such a model (public key crypto probably enables more clever schemes, not sure): - Upon signup, generate hashes o…
Use a password manager and don't reuse passwords. If your randomly generated, unique password has good enough entropy then why go through all of the trouble of the rest of the client side hashing? There's nothing stopping you from hashing your own passwords client side and sending your bcrypt hash up to the server except some sites still truncate the passwords to 32/16 chars etc. When you have the need for the level…
As for writing my own crypto. Indeed, if anyone actually used the scheme I suggested they would be making a mistake. I wrote it not to be used but to demonstrate that we can do better in an easy to understand way. Unlike me, Google has the resources to read the papers, do the math, carefully implement this, and do it properly.
Keywords for how to do it properly include "zero knowledge password proof" and "password authenticate key exchange".
PS. It's irrelevant to this conversation, but putting all my passwords into one program has always struck me as a monumentally stupid idea. I use one for passwords I don't care about, I memorize unique passwords for passwords I do care about.