251–260 of 529 posts
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.
> Throttle based on what? User Id?
Earlier quoted context omitted.
Modern cred stuffing is done by botnets. When I see a cred stuffing attack, it's maybe 1-3 attempts per IP address spread over 100-500k IP addresses. Often you'll have a family of legitimate users behind an IP address that's cred stuffing you at the same time. 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…
Any advice on where to read more about these modern cred stuffing countermeasures? I'd love to learn more.
https://link.springer.com/chapter/10.1007%2F978-3-319-07536-...
Earlier quoted context omitted.
Do you have a better solution for differentiating yourself as an actual user from a robot spammer?
This is only truly necessary as a mechanism to prevent automated signups. It is less necessary, but can be useful, to prevent repeated login attempts (rate limiting works there). For accessing a website it's completely inexcusable.
Only if there isn't some shared knowledge between the website and prospect.
For example some niche websites that I use have locally-based challenges such as 'how many engines can be fitted to a Boeing 747-400'* or a short mathematical algebra to solve.
Both approaches work without Javascript and without external support, just with a two-column table and a trusted group of challenge-creators.
* it's more than four
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).
>but it can also prevent a (compromised) server from seeing your password If the server is compromised, then there is no protection of your cleartext password at all. This is because the entity that compromised the server can replace the original JS with anything, including new JS that sends your cleartext password off to their own host as you type each character. The only activity on your part that can save you agai…
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).
This is only true when client-side hashing is under control of the client. In a web browser, it is not. The browser will happily run whatever JS the server sends it. So if the server is compromised, it can send compromised JS, and there goes your client-side hashing protections. An example of where it might work is in an app, where you're getting the client code from a separate channel like an app store.
This is coming right after the reCAPTCHA v3 announcement https://news.ycombinator.com/item?id=18331159 Sorry, you don't have enough Google Points to browse the web. Please enable JavaScript and install Google Chrome.
> Sorry, you don't have enough Google Points In the past few months all our domestic devices have gradually hit that notional condition with Google Search. All the laptops one by one, and then last night my phone. My wife's phone is the only one that can still use their search without a ten-round Recaptcha challenge. As each device was locked-out from Google I switched the default over to DDG.
Earlier quoted context omitted.
Hashing passwords client side has no benefit if a site uses HTTPS. If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?
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…
The downside is not a tiny bit of computation time. It's also increased latency for the customer.
I'm genuinely curious who actually browses the web in 2018 with JS disabled, though. Wouldn't 99.9999% of the web basically break? Like, if you do, do you only stick to a few basic sites, or?
I'm not sure if it quite qualifies as browsing with JS disabled but I run UMatrix with the default settings set to disable all scripts on a site. Then I've set some common domains I trust that greatly improve usability (things like ytimg, paypal, some common 3rd party scripts). I'd say I browse the web normally. Plenty of sites load normally with scripts disabled (and may even be more pleasant to browse). Maybe a 25…
OTOH, web works faster with uMatrix. You can probably get an extra couple years of your computer if you're aggressive about disabling ads and superfluous JS.
This is coming right after the reCAPTCHA v3 announcement https://news.ycombinator.com/item?id=18331159 Sorry, you don't have enough Google Points to browse the web. Please enable JavaScript and install Google Chrome.
Recent new version of Google Mail flat out doesn't work to any usable standard in Firefox. Ten seconds to open a new 'compose mail' window. A context menu does a multi-second HTTP fetch before showing. The previous version worked great. Either the dev team has just given up on quality or they're intentionally goading me into installing Chrome. I'm not going to play that game -- at this point Thunderbird works better.