Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

Post reply on HN
Print view View original

351–360 of 529 posts

Re: JavaScript is now required to sign in to Google

#351

Post by userbinator »

mike_hearn wrote: post #325
mpeg wrote: post #320

Earlier quoted context omitted.

Not to detract from your work there, but there's actually some great research papers about how Botguard itself is easy to bypass and google cookies provide most of the heavy lifting when it comes to bot detection. I've snooped around a bit myself and it doesn't seem like botguard does anything much more advanced than other fingerprinting solutions. I just don't buy that this is all about detecting more bots; every so…

Ah, you're assuming it's the same strength on all places it's used - and also that it actually has been bypassed. There didn't used to be any public bots that can beat the strongest version and from a quick Googling around I don't see that it's changed. Someone took apart a single program manually, years ago, but the programs are randomly generated and constantly evolve. So that's not sufficient to be able to bypass…

It's a lot faster and more scalable to not automate a full web browser. Bot developers would rather not do it, they only do because they're forced to. Forced to ... by requiring Javascript, like this.

In other words, the bot developers are still getting through, and meanwhile it's the actual humans who don't want JS which get screwed. Reminds me of DRM... honest customers are the most inconvenienced, while crackers still break it.

Re: JavaScript is now required to sign in to Google

#352

Post by delroth »

rocqua wrote: post #350
raesene9 wrote: post #314

Earlier quoted context omitted.

Credential stuffing more commonly refers to the practice of getting valid sets of creds from various password database dumps and retrying them across common/popular systems. 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)

Ip based lockouts as opposed to account based lockouts do better against cred stuffing. Because there is a cost to getting more IP adresses. Maybe carrier grade NAT would lead to too many false positives?

Most bad actors doing abuse at scale have access to large networks of proxies on residential or mobile IPs, usually backed by malware on workstations, laptops and mobile phones.

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).

Re: JavaScript is now required to sign in to Google

#353

Post by lucb1e »

So I'm wondering, all these automated detections and CAPTCHAs... how does that tie in with automated decisions being made about you under GDPR? They're trying to protect us from bots, but those decisions are also made by bots. What if their bot makes a mistake? Does that count as an automated decision under GDPR, for which I should be able to ask a human for a second opinion?

Re: JavaScript is now required to sign in to Google

#354

Post by aequitas »

dspillett wrote: post #334
mathw wrote: post #323

Earlier quoted context omitted.

I find the idea of detecting someone's trying to bust your login page with some kind of automated system and deciding to serve them a ridiculously aggressive Bitcoin miner rather amusing.

You risk setting up a little cold war that you probably don't have time for though... "Think you are clever, eh, try this for size..." -- some attackers in response to being affected by your counter measures.

Whats stopping that war from happening at any other time? If a attacker has the resources and carelessness to mount such an attack at a whim you should be prepared for it?

Re: JavaScript is now required to sign in to Google

#355

Post by fiblye »

guest0001 wrote: post #274

"When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious." In my experience (it is already the case with gmail and outlook up and now), this means I will not be able to login to my account when in holiday in another city, country, or when I use a borrowed device, or when I am behind VPN/Tor, etc, unless I give google my p…

I get this on my own computer that I've been using for 6 years on a static IP. It happens at least once a month, sometimes several times. Each time they ask for a phone number confirmation when no phone number is linked to the account (and never will be).

Google™ employees have come in and found mind-bending ways to excuse it when I've mentioned this before.

Re: JavaScript is now required to sign in to Google

#356

Post by rocqua »

dspillett wrote: post #332
Borealid wrote: post #299

Earlier quoted context omitted.

Can'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 Bitco…

> Can't you use Javascript to implement challenge-response authentication > 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 some…

Regarding point 1, you can combine 'challenge response' with diffie helman to

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.

Re: JavaScript is now required to sign in to Google

#357

Post by avip »

userbinator wrote: post #351
mike_hearn wrote: post #325

Earlier quoted context omitted.

Ah, you're assuming it's the same strength on all places it's used - and also that it actually has been bypassed. There didn't used to be any public bots that can beat the strongest version and from a quick Googling around I don't see that it's changed. Someone took apart a single program manually, years ago, but the programs are randomly generated and constantly evolve. So that's not sufficient to be able to bypass…

It's a lot faster and more scalable to not automate a full web browser. Bot developers would rather not do it, they only do because they're forced to. Forced to ... by requiring Javascript, like this. In other words, the bot developers are still getting through, and meanwhile it's the actual humans who don't want JS which get screwed. Reminds me of DRM... honest customers are the most inconvenienced, while crackers s…

You are putting words he didn’t say. JS provides vast reactive surface to identify automated tools with.

Re: JavaScript is now required to sign in to Google

#358

Post by xg15 »

mike_hearn wrote: post #311

When I was at Google I started both the login risk analysis project and the Javascript-based bot detection framework they're now enforcing, so it's a pity to see so many angry comments. Maybe a bit of background will make it seem more reasonable. Firstly, this isn't some weird ploy to boost ad revenue. This is the login page - users are typing in a long term stable identifier already! The Javascripts they are requiri…

Javascript ist also required for the vast majority of web-based exploits. I find it somewhat strange that you ask me to make my system less secure so you can better secure my account.

Re: JavaScript is now required to sign in to Google

#359

Post by tinus_hn »

rocqua wrote: post #350
raesene9 wrote: post #314

Earlier quoted context omitted.

Credential stuffing more commonly refers to the practice of getting valid sets of creds from various password database dumps and retrying them across common/popular systems. 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)

Ip based lockouts as opposed to account based lockouts do better against cred stuffing. Because there is a cost to getting more IP adresses. Maybe carrier grade NAT would lead to too many false positives?

IPv6 addresses aren’t really scarce.

Re: JavaScript is now required to sign in to Google

#360

Post by xg15 »

mike_hearn wrote: post #325
mpeg wrote: post #320

Earlier quoted context omitted.

Not to detract from your work there, but there's actually some great research papers about how Botguard itself is easy to bypass and google cookies provide most of the heavy lifting when it comes to bot detection. I've snooped around a bit myself and it doesn't seem like botguard does anything much more advanced than other fingerprinting solutions. I just don't buy that this is all about detecting more bots; every so…

Ah, you're assuming it's the same strength on all places it's used - and also that it actually has been bypassed. There didn't used to be any public bots that can beat the strongest version and from a quick Googling around I don't see that it's changed. Someone took apart a single program manually, years ago, but the programs are randomly generated and constantly evolve. So that's not sufficient to be able to bypass…

I understand this is not a subject where details can be shared, but - I'm sorry - at this level, this sounds like marketing speak. "You can't possibly comprehend just how advanced our AI is. If it appears stupid to you then because we intentionally want to have it appear stupid..."
Post reply on HN