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

481–490 of 529 posts

Re: JavaScript is now required to sign in to Google

#481

Post by thaumasiotes »

Isinlor wrote: post #336
thaumasiotes wrote: post #133

Earlier quoted context omitted.

Judging by his comment, totony is. Your password _is_ whatever you send over the wire. Doing a hash in JavaScript before sending it won't obscure the user's password from anyone who can see their traffic; it will obscure the user's password from the user.

Nope, the password is what people type in. They may type the same things at many websites. We should not care what that exactly is. Why would you want to see actual user password if you can just not see it? If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it. E.g. Twitter recently discovered that they were storing passwords in plaintext in logs,…

No, the password is whatever you send over the wire. If a website processes your attempt to type "password" into "5f4dcc3b5aa765d61d8327deb882cf99" before sending that to the server, then your password for that website is 5f4dcc3b5aa765d61d8327deb882cf99. That's what the server sees and how it recognizes you. The only effect of this is to make it less likely that the user knows his own password.

Re: JavaScript is now required to sign in to Google

#482

Post by nathan_long »

horsawlarway wrote: post #421
nathan_long wrote: post #415

Earlier quoted context omitted.

> That said, I'd be willing to wager a fair bit that literally every line of code you've run on your machine (probably ever if it's been bought in the last few years) outside of the vendor installed OS and drivers came from the internet. We explicitly decide to install software and we know where we're getting it from. We may not be careful enough, but I certainly trust `brew install` a lot more than I trust a random…

I think this is a reversal of responsibility. You're shifting the responsibility from yourself to a different entity for the choices you're making. The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit. > I bought my car to drive it, but that doesn't mean that every person I pass on the street gets to drive my car. Damn right you don't let ra…

> Damn right you don't let random people drive your car! just like I expect you not to click every link you see!

The difference is that I can interact with any number of people, yet only trust a few to drive my car.

You seem to suggest that I should trust everyone I interact with to drive my car, and since that's risky, I should limit my interactions to a few people.

> You're shifting the responsibility from yourself to a different entity for the choices you're making.

Not trusting a site's code is taking responsibility for what it might do to me. Trusting their code is giving them the responsibility to do what's right.

> The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit.

This is good, practical advice for non-tech people. But fundamentally there is no reason the web needs to be unsafe. Viewing a series of hypertext documents is safe, no matter who wrote them. The web is totally safe if you browse it using curl. It's only when we assume that "of course you're going to run that stranger's code" that things become dangerous.

It's great that we can have web applications. It's not great if every page is an application. There should be an explicit step from "I'm casually looking at your page" to "now I want to trust you and run your code".

> That said, modern browsers do a really, really good job at isolating the code running in that page from anything you care about.

That code can't wipe my hard drive, but it can track me everywhere if I let it.

The reason we need content security policies and cross-site request forgery tokens and cross-site scripting protection etc, etc is that our browsers are constantly eval'ing whatever code they're given.

Re: JavaScript is now required to sign in to Google

#483

Post by nathan_long »

horsawlarway wrote: post #466
plankers wrote: post #427

Earlier quoted context omitted.

Correct me if I'm wrong, but it seems that your personal philosophy places absoluely none of the onus for the internet being dangerous and unfriendly on the people who actually develop things for the internet. You instead blame the layman who has no power to control how websites are constructed. The heck?

I'd disagree entirely. I'd argue that I'm aware of how much effort has gone into making the web much, Much, MUCH more convenient and less risky for the average, day to day user. It's frankly stunning how much the ecosystem has changed just over the last 5-10 years. And I mean that as a developer who works in the security industry with a focus on browsers/extensions. It's ludicrous how much more secure the web of toda…

> It's your responsibility to make sure you trust that entity, and do your due diligence.

What does this entail? I mean, ask the average person if they trust the New York Times, the London Stock Exchange, or Spotify. Those are well-known names - sure we trust them. We trust that, as an organization, they are not plotting to steal our identities.

But trusting them means trusting their business people, their IT people, and their advertising partners, not only to be moral but also to be competent. And whoops, all of them have served malvertising in the past.

Nobody has the time and expertise to evaluate every site's JavaScript every time they visit. The "due diligence" you describe would be a very specialized full-time job.

Whereas turning off JavaScript in the browser takes about 10 seconds.

Re: JavaScript is now required to sign in to Google

#484

Post by [deleted] »

horsawlarway wrote: post #421
nathan_long wrote: post #415

Earlier quoted context omitted.

> That said, I'd be willing to wager a fair bit that literally every line of code you've run on your machine (probably ever if it's been bought in the last few years) outside of the vendor installed OS and drivers came from the internet. We explicitly decide to install software and we know where we're getting it from. We may not be careful enough, but I certainly trust `brew install` a lot more than I trust a random…

I think this is a reversal of responsibility. You're shifting the responsibility from yourself to a different entity for the choices you're making. The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit. > I bought my car to drive it, but that doesn't mean that every person I pass on the street gets to drive my car. Damn right you don't let ra…

[deleted]

Re: JavaScript is now required to sign in to Google

#485

Post by h43z »

singularity2001 wrote: post #265
h43z wrote: post #123

I tried to live with javascript disabled by default but gave up after two months because all I did was white-listing every page I opened. Gave up on my own side projects too. Building something that works with and without javascript is just to much work for me and it becomes ugly quickly. I still think modern websites over use javascript too often and should use markup over code whenever possible. And of course no on…

try again with noscript allowing main page by default but not 3rd party.

I think that most of the annoying (but non breaking) javascript is already covered by ublock.

Re: JavaScript is now required to sign in to Google

#486

Post by z3t4 »

STRML wrote: post #446
z3t4 wrote: post #417

Earlier quoted context omitted.

I'm hijacking this thread to say we need a better ID system for the web! That preferably work without JS. Something built into browsers, that also allow you to create as many identities you want. When a id-signup header is detected, the user see a signup button, and can chose what information is sent to the web site/app. The user can login to any site with the push of a button, or even automatically. With a built in…

In a certain sense this existed with the ` ` element ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke... ) which is unfortunately deprecated. But you still have all the same issues of moving and safeguarding key material. These days with browser/mobile sync, maybe it's actually possible. But like a synced password manager, it makes a primary account breach that much more devastating.

The problem with certificates is they require a central authority, eg. politics. We need something that can work anywhere, without any third party or central authority.

Re: JavaScript is now required to sign in to Google

#487

Post by horsawlarway »

nathan_long wrote: post #483
horsawlarway wrote: post #466

Earlier quoted context omitted.

I'd disagree entirely. I'd argue that I'm aware of how much effort has gone into making the web much, Much, MUCH more convenient and less risky for the average, day to day user. It's frankly stunning how much the ecosystem has changed just over the last 5-10 years. And I mean that as a developer who works in the security industry with a focus on browsers/extensions. It's ludicrous how much more secure the web of toda…

> It's your responsibility to make sure you trust that entity, and do your due diligence. What does this entail? I mean, ask the average person if they trust the New York Times, the London Stock Exchange, or Spotify. Those are well-known names - sure we trust them. We trust that, as an organization, they are not plotting to steal our identities. But trusting them means trusting their business people, their IT people,…

> It's your responsibility to make sure you trust that entity, and do your due diligence.

> What does this entail?

My whole point is that that's up to you to decide. No one else can make that choice for you.

The VAST majority of people have decided that the risks they face today are worth it, and continue to use the web with js enabled.

If you're not one of them, I absolutely respect that decision, but it means you'll have to accept that companies are making financial and security based decisions based on the behaviors of normal people.

That means that when spotify (and lets be honest, every other streaming service) doesn't work without js, you go somewhere else, and use something different.

That's the whole point I'm making. You can make any decision you'd like with regards to your own security, you can make any decision you'd like with regards to the sites you visit. But that site is free to act in it's own interests, including adding features and services that target the majority of their uses.

Re: JavaScript is now required to sign in to Google

#488

Post by mrguyorama »

joshstrange wrote: post #433
gambler wrote: post #414

Earlier quoted context omitted.

Sorry, but at this point it is pretty obvious that big tech companies care about account security only as far as it impact their services. The late revelation about Facebook abusing 2FA phone numbers for marketing is a great demonstration of how that works. Google too does some really funny things to make it nearly impossible to create and maintain an anonymous accounts not tied to a phone number. Even when those acc…

> "Just use our 2FA." What about smaller websites that don't have resources to maintain 2FA? I'm not going to say that providing 2FA is "free" in the time sense (both in implementing it initially and supporting people who lock themselves out) but on the surface 2FA requires just a library to verify 2FA codes and a column in your users table to store the shared secret.

The one thing I dislike about 2FA as a user is, if I drop my phone in a lake, can I safely recover my account? I have a lot of time, money, effort, etc invested in my accounts, and I really don't want to lose that

Re: JavaScript is now required to sign in to Google

#489

Post by naasking »

gpm wrote: post #206
naasking wrote: post #200

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

> - That is auditable - it is impossible for a malicious site to do so without risking being caught.

Hardly. Minimization and obfuscation is trivial, and you can ensure the output is always different in order to defeat auditing. Not great for caching obviously, but 'auditability' is not achievable if the server is determined to fool you.

> - The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.

Password are simply not where you want to leverage your security. If you can find a document example of a real threat that this approach would have mitigated, then I'll take it seriously.

Re: JavaScript is now required to sign in to Google

#490

Post by z3t4 »

mrep wrote: post #429
z3t4 wrote: post #417

Earlier quoted context omitted.

I'm hijacking this thread to say we need a better ID system for the web! That preferably work without JS. Something built into browsers, that also allow you to create as many identities you want. When a id-signup header is detected, the user see a signup button, and can chose what information is sent to the web site/app. The user can login to any site with the push of a button, or even automatically. With a built in…

> The contact list can even be inside the browser, and web site's can ask for it, allowing for example white-listing in messenger apps, or let the user pick who are allowed to see their family pictures, etc. How would that work for sites like Hacker news, reddit, and twitter? Does every single user have to preview and approve every single other user on the website? That doesn't scale at all.

It would work the same, except you can sign up with one click, login with one click, and the server wouldn't store any password/key. But it also allows for additional functionality, for example in a photo sharing app/site you could tell it that only those with these ID's should be able to see the picture, without the site/app needing to know who those people are, they don't even need to have an account on that site.
Post reply on HN