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

181–190 of 529 posts

Re: JavaScript is now required to sign in to Google

#181

Post by asdfasgasdgasdg »

greglindahl wrote: post #104
Operyl wrote: post #34

Earlier quoted context omitted.

Google is dictating how signing into their account system on their properties works, not login forms for _every single site_.

Google's policies get exported. For a long time it was OK to drop email that came from a server without rDNS. Then gmail started allowing such emails, and then legit sites started sending email from servers without rDNS. In this case the export mechanism is Captcha v3.

So you're saying you're getting tired of everyone else copying Google's behavior?

Re: JavaScript is now required to sign in to Google

#182

Post by [deleted] »

vivekseth wrote: post #53
totony wrote: post #37

Earlier quoted context omitted.

Passwords can be hashed directly client-side with javascript, which is way more secure than sending them clear on the wire, so i dont disagree with Google's stance here and dont understand the hate

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?

[deleted]

Re: JavaScript is now required to sign in to Google

#183

Post by superkuh »

bluetidepro wrote: post #10

I'm genuinely curious who actually browses the web in 2018 with JS disabled, though. Wouldn't 99.9999% of the web basically break? Like, if you do, do you only stick to a few basic sites, or?

I used to think the same thing about people who browse with auto-loading plugins. Then browsers caught on and started click-to-play'ing them.

Javascript is the new plugins (so much host OS functionality exposed now) and it requires a new click-to-play. I'd like to think they'll eventually integrate something like NoScript into the browser as a standard. This free for all code running is too much now that the browser is an OS.

But it's difficult to get browser companies to understand something when their income depends on not understanding it.

Re: JavaScript is now required to sign in to Google

#184

Post by snowwrestler »

eco wrote: post #176
nathanaldensr wrote: post #117

Earlier quoted context omitted.

I can speak from experience regarding FastMail because that's exactly what I did. In fact, I migrated off a grandfathered Google Apps account with my custom domain to FastMail with that same domain. Yeah, it's a bunch of steps, but I'm very comfortable with making DNS changes. My wife and I have an account; it's worth every penny. Also, FastMail allows for subdomain handling. I use this feature with nearly every site…

I'm in the weird Google Apps for Your Domain limbo right now myself. I've wondered what would happen if I switched to something other than GMail but kept my google account with that email address. I know a long time ago you could set up a Google account using a non-GMail email address but I'm not sure if that's even a thing anymore. That's what I want though. Keep the email address with my own domain that I've used f…

You absolutely can set up a Google account with any email address you want.

https://accounts.google.com/SignUpWithoutGmail

I use Google services heavily at work, all on a Google account that was created with my work email address. And we are not a Google shop; my employer's email is self-hosted Exchange.

Re: JavaScript is now required to sign in to Google

#185

Post by rb666 »

nathanaldensr wrote: post #117
asdkhadsj wrote: post #58

Earlier quoted context omitted.

Switching email providers is reasonably painless, fwiw. Set up forwarding, migrate mail when you can. Even better if you set up the majority of your non-security-essential mail to be at your own domain, hosted by Fastmail/etc. Then you can easily change your email provider and your contacts don't even care. I've yet to implement this is in my own life, I just switched to fast mail - so I can't speak from personal exp…

I can speak from experience regarding FastMail because that's exactly what I did. In fact, I migrated off a grandfathered Google Apps account with my custom domain to FastMail with that same domain. Yeah, it's a bunch of steps, but I'm very comfortable with making DNS changes. My wife and I have an account; it's worth every penny. Also, FastMail allows for subdomain handling. I use this feature with nearly every site…

Another very happy user of FastMail here, with our own domain. I initially was excited by subdomain handling, but switched back to only using my main account.

Using FastMail-specific features will lock you into this specific vendor once again, one of the main reasons to switch in the first place!

Re: JavaScript is now required to sign in to Google

#186

Post by mathnmusic »

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.

Which country uses a single IP address for all its devices/citizens?

Re: JavaScript is now required to sign in to Google

#187

Post by ReverseCold »

mathnmusic wrote: post #186
Phlarp wrote: post #171

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

Which country uses a single IP address for all its devices/citizens?

China Telecom does something weird with NAT, not sure what exactly but I've seen it mentioned here before

Re: JavaScript is now required to sign in to Google

#188

Post by martin1975 »

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?

Re: JavaScript is now required to sign in to Google

#189

Post by skunkworker »

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…

Use a password manager and don't reuse passwords. If your randomly generated, unique password has good enough entropy then why go through all of the trouble of the rest of the client side hashing?

There's nothing stopping you from hashing your own passwords client side and sending your bcrypt hash up to the server except some sites still truncate the passwords to 32/16 chars etc.

When you have the need for the level of security, client side hashing will not be as good as dedicated HSMs that many services now use on authentication.

Writing your own crypto flows can be extremely dangerous as you open yourself to all kinds of side channel attacks.

Re: JavaScript is now required to sign in to Google

#190

Post by skunkworker »

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 why server side HSMs (hardware security modules) are a thing.
Post reply on HN