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

191–200 of 529 posts

Re: JavaScript is now required to sign in to Google

#191

Post by userbinator »

throwawaymath wrote: post #157
dane-pgp wrote: post #144

Earlier quoted context omitted.

The security bugs found during Pwn2Own are usually kept under embargo, and only published later by the browser developers. Here's an article about a Chrome bug found in 2017's Pwn2Own: https://www.computerworld.com/article/3186686/web-browsers/g... and it does involve JavaScript. Could you provide some recent examples of the sort of browser exploits you mean, that don't require JavaScript? (I assume you're not includ…

Sure: https://www.cvedetails.com/vulnerability-list/vendor_id-1224... . Also look at Google Project Zero writeups, and similar CVE details for Firefox and Safari. Some are related to JavaScript (notably, it's hard to exploit V8 if the browser isn't processing any JavaScript!). But the vast majority are memory corruption and sandbox escape issues. Disabling JavaScript insulates you from a nontrivial - but nontheless m…

But the vast majority are memory corruption and sandbox escape issues.

...which require JS to exploit. (What is a "sandbox escape" if there isn't code to... escape it?)

I went through the 50 vulnerabilities on that page and looked at the nature of them and inspected any PoC code if any. This is the results:

PDF,JS,JS,WebGL(JS),JS,CSS,JS,JS,extension,HTML(but PoC needs JS),JS,PDF,PDF,MIDI(JS),AppCache(JS),PDF,JS,UI,WebRTC(JS),JS,JS(speech recognition!?),JS,JS,JS,JS,JS,JS,JPEG(rendering uninitialised memory --- not exploitable without JS to read that data),JS(WebWorker),HTTP/SSL(!),SVG+JS,UI,JS,XML(!),SVG+JS,JS(audio),Fonts(actually Windows font renderer bug),UI,??(no details available),IndexedDB(JS),WebGL(JS),UI,JS(WebSockets),NaCl(extension),extension,PNG,WebGL(JS),?,JS,WebGL(JS)

That's 32/50 confirmed to require JS to exploit, and only 3/50 stood out as being "visit a page with all plugins/JS/extensions disabled, and still get pwned", of which 1 is actually a Windows bug.

Disabling JavaScript insulates you from a nontrivial - but nontheless minority - subset of browser vulnerabilities.

Looks more like a majority to me.

Re: JavaScript is now required to sign in to Google

#192

Post by Spivak »

martin1975 wrote: post #188

JavaScript is fast becoming, if it hasn't already, the next rich GUI framework... It was supposed to be just touch up on HTML, now you can't sign in anymore w/out JS enabled. What if I wanted to do a rich client in C# or Qt? Do I need a JavaScript engine to sign in?

Yes, plenty of apps allow you to sign in with Google -- they open up an embedded web browser for the sign-in dialog and oauth permission screen.

Re: JavaScript is now required to sign in to Google

#193

Post by lisper »

Phlarp wrote: post #171
lisper wrote: post #139

Earlier quoted context omitted.

> 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?

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?

Re: JavaScript is now required to sign in to Google

#194

Post by snowwrestler »

the_clarence wrote: post #130
vivekseth wrote: post #53

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?

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.

Re: JavaScript is now required to sign in to Google

#195

Post by userbinator »

bencoveney wrote: post #83
Zelphyr wrote: post #32

I'm getting tired of Google dictating how the web should work. That's the job of standards bodies. Google is increasingly taking the place of overbearing overlord that Microsoft embodied in the 90's and early 2000's.

Is there a standard relating to whether JavaScript should be optional?

According to the WHATWG:

https://html.spec.whatwg.org/multipage/scripting.html

"Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting."

"Authors are also encouraged to make their applications degrade gracefully in the absence of scripting support."

Re: JavaScript is now required to sign in to Google

#196

Post by PetahNZ »

gpm wrote: post #88
vivekseth wrote: post #53

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…

This is completely wrong. HTTPS is what secures this, not client side password hashing. If you don't use HTTPS, you can just get MITM'd to disable any kind of client side hashing.

Re: JavaScript is now required to sign in to Google

#197

Post by sunsetMurk »

duxup wrote: post #177

I'm not really sure how it works if you don't want to use JavaScript, do you then whitelist sites that you're ok with it? Wouldn't the solution for folks who don't want to run JavaScript just to whitelist it for Google? Maybe I'm missing something but that seems pretty simple, would let Google do their thing and the folks who don't want to run it run it just for Google and places they want to. If someone already does…

Yes, practical.

Re: JavaScript is now required to sign in to Google

#198

Post by untog »

userbinator wrote: post #119
brunoTbear wrote: post #78

Earlier quoted context omitted.

It's surprising to me how many users on HN can only think as far as their own browser. Really the question here is not "what's the harm of JS across the web" but rather what is the specific privacy cost of running JS on a sign in page and what is the security benefit of the same. The worst case cost of JS on a browser is that you get a drive by download and your endpoint is owned. This seems unlikely on a Google doma…

I'm sure tracking everyone and controlling exactly what they can do will make them safer. Why don't we put surveillance cameras everywhere and make them record 24/7 too? Authoritarian ideology like this is what turned me off the whole "security industry" years ago.

Google already controls exactly what you can do... on Google.

You're arguing against ubiquitous surveillance, when the OP is arguing for company surveillance of the way in which you interact with their login screen, on their site.

Re: JavaScript is now required to sign in to Google

#199

Post by bunnycorn »

jazzyjackson wrote: post #101
afandian wrote: post #35

Earlier quoted context omitted.

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.

I've recently switched to MacOS's built in mail client with IMAP to Gmail, never have to wait for my UI to do something. So count me in as surprised how far gmail has gone downhill.

Never liked webmail anyways.

Thunderbird might be superior, but I really like that App because it's so light and fast.

Re: JavaScript is now required to sign in to Google

#200

Post by naasking »

gpm wrote: post #88
vivekseth wrote: post #53

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…

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

Post reply on HN