JavaScript is now required to sign in to Google
301–310 of 529 posts
Re: JavaScript is now required to sign in to Google
#302Earlier quoted context omitted.
Javascript 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.
So, basically javascript is used for security through obscurity?
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.
Re: JavaScript is now required to sign in to Google
#303"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…
Re: JavaScript is now required to sign in to Google
#304Re: JavaScript is now required to sign in to Google
#305> But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you. They don’t seem to explain why though? Did I miss it? Are they fingerprinting the JavaScript environment of my browser?…
Re: JavaScript is now required to sign in to Google
#306Earlier quoted context omitted.
> 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 separately assume a salt is part of my hash function. Salts only help with rainbow tables (an admirable goal, but not my one here). 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…
Re: JavaScript is now required to sign in to Google
#307Earlier 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?
So for example LinkedIn has a breach, which reveals to evildoers that user 'johnsmith@example.com' 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.
Re: JavaScript is now required to sign in to Google
#308"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…
Re: JavaScript is now required to sign in to Google
#309It is best to run gmail on a separate, private browsing window, so that it does not interfere with normal web browsing (i.e., make sure that other websites such as google search cannot see that you are actually logged into gmail).