9 ms·
ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not
by brunoTbear 8y ago
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 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.
- Forge36 8y agoEven when I ran noscript Google domains were allowed. It's extra step for a small number of technical users.
- greglindahl 8y agoCalling other people, or their opinions, shortsighed and self-centered is usually not the start of a good conversation.
- brunoTbear 8y agoYou're right. I was shortsighted and self-centered.
- kadendogthing 8y agoI mean, why not cut to the chase?
- duxup 8y agoI'll be the guy who says that while I recognize those are insults, they are also sufficiently descriptive of a point of view... it's not like he called someone Mr. Poopypants.
- coldtea 8y agoTo a good conversation no. But not always is a conversation what's desirable. Sometimes one just wants an accurate depiction of a situation -- and those might still be totally accurate characterizations...
- anothergoogler 8y ago> The privacy loss of one account being popped is likely far greater than the privacy loss of thousands of users' browsing patterns being correlated. 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?
- esotericn 8y agoYour first statement is incompatible with your second. (I think the second statement is reasonable, although I disagree with the conclusion). 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.
- brunoTbear 8y agoI think you may be giving people more credit than they deserve, but I'm willing to accept that they're making that argument. Even if that's their argument, that their personal habits around password use and being attentive to not being phished are so good they don't need Google's help defending themselves, so bully for everyone who does, I'm not convinced it's a good one. 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.
- wild_preference 8y ago> I think the sad truth is that computer engagement is required, but literacy is optional. 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.
- the_clarence 8y agoXSS 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.
- lisper 8y ago> 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?
- Phlarp 8y agoThrottle 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.
- mathnmusic 8y agoWhich country uses a single IP address for all its devices/citizens?
- ReverseCold 8y agoChina Telecom does something weird with NAT, not sure what exactly but I've seen it mentioned here before
- dlubarov 8y agoAll of Qatar's traffic used to be routed through 82.148.97.69, though that was back in 2006-2007. At one point it was banned from Wikipedia, which unintentionally affected the whole country. https://simple.wikipedia.org/wiki/User_talk:82.148.97.69 https://simple.wikipedia.org/wiki/User_talk:82.148.97.69
- lisper 8y ago> Throttle based on what? User Id?
- ryantriangles 8y agoWith credential stuffing, isn't it unlikely the perpetrator wants to make more than one or two attempts per user ID?
- PeterLGummybear 8y agoAnd indeed it's time to give up on the web being a document format only. The internet is about loading remote applications in your local sandbox. That's what it is. It sucks, but it is what it is. As part of loading remote applications, we now might be asked to compute whatever anti-abuse puzzles are required. So it goes.
- hnzix 8y agoIf something shitty is happening, you don't have to shrug your shoulders coswhatyagonnado. Understanding the human reason why something shitty is happening doesn't mean you have to accept it. So it goes, until it doesn't.
- ezoe 8y agoRunning JavaScript means parsing text from outside source plus executing the program from outside source. Both requires really complicated code counted by the unit of M LOC(Mega Line of Code). It's still under-esitmating.
- tinus_hn 8y agoIf by ‘cred stuffing’ you mean brute forcing accounts, that’s what short lockouts and 2 factor authentication are for. JavaScript is just a layer of obfuscation and doesn’t fundamentally help.
- roenxi 8y agoI'm not up to speed with the latest and greatest of what java-script can do, but isn't the source code fundamentally user-visible? 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.
- aequitas 8y agoJavascript can be served dynamic as well, per user/connection specific even. So an attacker would have to investigate and counter each new version of the scripts. Even if this could be done automatic it greatly increases the cat/mouse factor for Google.
- dorgo 8y agoSo, basically javascript is used for security through obscurity?
- Borealid 8y agoCan't you use Javascript to implement challenge-response authentication, which meaningfully improves security by: 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...
- ifdefdebug 8y agoSo what about a opt-out at account level? Something in the account settings, like this: [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 ...
- ankit219 8y agoI used a long and supercomplicated password for one of my accounts that i access intermittently. Why I have it is a long story, but I only log into it once or twice a month to check if there is something that needs my attention. 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.
- linker3000 8y agoI asked LastPass to generate me a long and complicated password for a new Office 365 account only to have it rejected as too long because it was over 16 characters. Sigh.
- relic 8y agoIt's probably the switching of devices that raises the level of security.
- Jonnax 8y agoIt costs money to support and a miniscule amount of users would care. The majority of Google's customers also don't pay for an account.
- chatmasta 8y agoMaybe one reason is because google doesn’t know which account is trying to login before the login page, so how could they remember that security setting before attempting to serve JS?
- Nasrudith 8y agoPasswords are obsolete - actual security would involve keys. The fact they have to care about automation for security instead of availability is a sign they have already lost. If you have a disposable EC2 server administration password accessible you are already doing it horribly wrong because you /will/ get attacked frequently. 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.
- cmonfeat 8y agoTo be fair, Google released their own OTP hardware keys and have already 2FA login mandatory for accounts that they deem "high risk." 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?
- fweespeech 8y ago> ITT: people dramatically under-estimating the risk to their accounts from credential stuffing and dramatically over-estimating their security benefits from not running JS. 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.