People aren't underestimating the risk to _their_ accounts, they are discounting the risk to _others_ accounts.
That is, they're essentially saying, 'well, other users chose to have bad passwords, so bully them'.
I think that's a fair viewpoint to have. We've entered a world in which computer literacy is a basic requirement in order to, well, exist.
That said, what's reasonable, and what actually occurs, are two different things. A company isn't going to ideologically decide "screw the users that use bad passwords" if it loses them money.
So we get _seemingly_ suboptimal solutions like this.
There are a few things needed for that to be a good argument 1) Their security really is so good (I'd bet it isn't. I saw a tenured security professor/former State Department cyber expert get phished on the first go by an undergrad.) 2) Google isn't improving their security posture on top of that (I'd be shocked if Google isn't improving theirs, and I'm certain having JS required to sign into gmail closes a major hole in observability of automation) 3) There are real harms from the JS being there for their security/privacy posture (as I've said elsewhere, I'm unconvinced Google is allowed by their own privacy policy from doing anything untoward here)
As to your point about computer literacy and existence, I think the sad truth is that computer engagement is required, but literacy is optional. When that's the case, large companies are in the position of having to defend even the least computer literate against the most vicious of attackers.
You're right on, but I wouldn't call it sad.
The population is expected to operate vehicles without putting others in danger, not credentialize in how cars work. There are endless amounts of things we could demand people spend their precious time deeply understanding. We just like to demand tech-savviness because it's self-aggrandizing.
Like everything else, the solution is to help people on their own behalf.
At an online casino I once worked at, we ended up generating random passwords for our users. We had to, because otherwise attackers would lookup usernames in the large password dumps online and log in as our users. No amount of warnings on our /register page stopped password reuse. So we decided we could do better than that, and that "well, we warned you" was not an appropriate response.
If you look around at everyday objects, everything is designed to protect the user. But for some reason in computing we're still in the dark ages of snickering and rolling our eyes at users for making mistakes.
Exactly! We require "car literacy" in drivers before we allow them to use them. Pretty much every advanced economy has mandatory driver licensing.
A driver can trivially press a few levers and slam themselves into a barrier at 100mph. But they don't do that, because they know, through experience and education, that it's a terrible idea.
That's the exact opposite of the approach that would have cars restrict their own usage into a narrow set of patterns and refuse to function otherwise.
WRT the last half of your comment: I think that's reasonable. Generating random passwords for users is a fair approach.
Account security exists on a spectrum. I don't think anyone (reasonable) is arguing against that, we're talking about mutable state here, actual _actions_.
What I'm railing against, is this idea that every webpage on the internet needs to be behind a CAPTCHA that does a bunch of invasive data collection including probably asking the user to perform a Mechanical Turk task in order to _access a website_ without even logging in.
It happens all the time. A website doesn't like my IP block -> forced through a bunch of nonsense. The site operator probably isn't even aware because they're using an upstream service which does it for them.
2FA is a good defence against it, but lockouts are less as they attacker will be going broad and not deep (could be a single request per user account)
Even as a newcomer without the right contacts on the black market you can get started with very little upfront investment, using services like https://luminati.io/ (they pay software developers to bundle their proxy endpoints within their apps).
We always used to laugh at people who did website security with javascript, the whole idea was that security processing had to be done server-side.
But with security at this level nowadays every added layer helps. Even if it is not even used in the initial authentication step. Think of classifying certain patterns in the attacks and retroactive de-authorizing after login, increasing the time-cost for the attacker.
1. Preventing interception of passwords on the wire
2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because the web site chooses what they do and could make them mine Bitcoins) or rewrite their brute-forcer each time the JS-driven network communication channel is altered
It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification...
Isn't this solved by https? I have no idea, but I hope at least that https protects my passwords.
>2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
I don't want to wait for a login more than a second. Actually, I don't want to wait at all.
>3. ... or rewrite their brute-forcer each time the JS-driven network communication channel is altered
How is this different from altered HTML/CSS? An attacker has to adapt to the altered login page. It is not an argument for javascript.
>It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification...
You say it: a protocol! not a piece of javascript.
Neither do I. But I also accept that, given the sheer volume of stolen creds and bots out there, sites that damage their bang/buck performance, even at the cost of very minor inconvenience to users, are likely to be targeted less frequently and in lower volume. Even if I wasn't begrudgingly willing to pay that price, I'd at least admit to the logic of making the process more time-consuming as a deterrent.
Do you log in that often?
"Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.
> 1. Preventing interception of passwords on the wire
It can, but challenge-response that isn't PKI based requires the remote side to have the secret stored or the local side to know how to generate the value that is stored instead, which goes against other recommended practise (with PKI the remote side can store the public key and ask for something to be signed with the private key).
Protecting passwords on the wire is better done with good encryption and key exchange protocols - in the case of web-based systems that is provided by HTTPS assuming it is well configured.
> 2. Allowing a tunable "difficulty" parameter which makes brute-force attacks cost ineffective
Could you give an example of that? If you are tuning difficulty based on the computation power of the other side, surely the other side could lie about being low powered and get an easier challenge?
> 3. Requiring that brute-force attackers either run a Javascript interpreter (dangerous, because...)
A knowledgable attacker doing this would be safe: they'd make sure the interpreter was properly sandboxed (to avoid reverse hacking) and given execution resource limits (to avoid resource waste). Then if the site/app is important enough that they really want in, they modify their approach if the resource limits are hit.
> or rewrite their brute-forcer each time the JS-driven network communication channel is altered
If your method is only used by you (and you aren't a Google or similar so you are big enough to be a juicy target on your own) and you enter into this arms race you might find it takes so much resource that it gets in the way of your other work. You are only you, the attackers are legion: put one off and another will come along later. Also there is the danger in rolling your own scheme that you make a naive mistake rendering it far less useful (potentially negatively useful: helpful to the attacker!) than your intention.
If the method is more globally used then it is worth the attackers being more persistent.
> It seems to me that having a client-and-server protocol beyond just "POST this data here" can be more secure than sending a password to the server for verification.
It can, though often only against simple fully automated attacks. Cleverer automated attacks may still succeed, as may more manual ones, and targetted manual attacks will win by inspection & replication.
Or they get in through an XSS, injection, or session hijacking bug elsewhere (bypassing the authentication mechanisms completely) that you missed because you spent so much time writing an evolving custom authentication mechanism.
Have the server side not know the password
And be secure against replay attacks given attacker access to plain text.
The scheme is something like:
Setup
Server generates key (x, xG) where G is some elliptic curve base point. It stores x and sends xG to the client.
The client computes y = H(password) and sends yG to the server.
The server stores the shared secret. x (yG)
Authentication:
Server generates nonce r and sends r xG.
Client computes y = H(password) and responds with y r xG
Server verifies that the response equals r (x yG).
End
In this protocol, an attacker with access to plain text, even during setup, still can't do anything.
This method is weak against MitM, but that can be solved on auth by doing a fully ephemeral diffie helman there.
I concocted this scheme on like 10 minutes, so there might be mistakes, and it os probably suboptimal.
Client-side js will always be readable, even if you obfuscate it, you can't trust it to never being decompiled.
But server-side js never has to reach the client, it can be used to dynamically generate basically anything.
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.
The most drastic example I can think of was an unverified rumor that a certain company would "fake" log users in when presented with valid credentials from a client they considered suspicious. They would then monitor what the client did - from the client's point of view it successfully logged in and would begin normal operation. If server observed the device was acting "correctly" with the fake login token, they would fully log it in. If the client deviated from expected behavior, it would present false data to the client & ban the client based on a bunch of fancy fingerprinting.
Every once in awhile, someone will publish their methods/software; Salesforce and their SSL fingerprinting software comes to mind: https://github.com/salesforce/ja3
I don't do much of this sort of thing, but numerous things come to mind. Aim to identify and whitelist obviously human browsers, blacklist obviously robot browsers, and mildly inconvenience/challenge the rest.
For example, an obvious property of a real human browser is that it had been used to log in successfully in the past. Proving that is left as an exercise for the reader, though it inevitably requires some state/memory on the server side.
https://link.springer.com/chapter/10.1007%2F978-3-319-07536-...
User Id?
There was automated tools that did this too!
So for example LinkedIn has a breach, which reveals to evildoers that user '[email protected]' uses the password 'smith1234' then they test that username and password in Amazon, Netflix, Steam and so on.
They only make one attempt per account, because they only have one leaked password per account. Hence, throttling per account isn't an option.
Javascript is opening an attack surface for what will certainly turn into an arms race anyway instead of ending it.
Given that they aren't pushing a new standard for what has already been a problem for a long time while introducing a vector for abuse both to and from it google can be criticized for both of those sins far more.
I don't think it's fair to blame them for the facts that most folks are not willing to give up passwords yet. Given that passwords are the current reality, shouldn't they do everything in their power to make them as secure as possible?
Sometimes one just wants an accurate depiction of a situation -- and those might still be totally accurate characterizations...
[check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.)
Edit: because users who know to use long passwords and 2FA do exist and don't need all that extra security stuff ...
> [check] Allow sign-in from javascript disabled browsers. WARNING etc. (usual warnings about security etc.)
It sounds a bit like what Gmail's doing with their "allow less secure apps" login option, except that's more for allowing IMAP logins using password instead of OAuth.
Usually the login is in incognito, guest mode, and even from different locations and machines. Google asks for a second factor (i dont have it on for my accounts) like phone verification for my usual accounts (not so complicated password) but not for the one with complex password. So I think the level of extra steps/security is linked with how complex your password is. Not so sure if this is a good thing or bad. But, I hope they should continue basing their security measures based on the security measures you take.
The majority of Google's customers also don't pay for an account.
Password are effectively obsolete and everyone should be using multi-factor authentication of some kind. Keys with passphrases. 2FA auth. Whatever.
Making 2FA auth mandatory would be substantially more effective than bot signaling.
> tl; dr: Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses. I think there's a shortsightedness and self-centeredness to a lot of these comments.
If they were, 2FA auth would be mandatory with additional phone-based (i.e. SMS) whenever you try to login from a new geographic area. That would stop anything short of a targeted hack.
Instead, they created an attack on the bot maker's profit margins. Cloudflare, Google, et al. are really just trying to increase the cost of making bots. They are not really trying to _stop_ bots.
Stopping bots requires making unpopular choices.
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.
It's still under-esitmating.
That's quite the hand-wave. How do you even measure privacy loss? And given that browsing history is not in your inbox, why are you so confident that one compromised email account is a bigger deal?
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 of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated.
tl; dr: Good luck detecting and preventing automation of sign in pages at scale without robust JS based defenses. I think there's a shortsightedness and self-centeredness to a lot of these comments.