Hacker News Reader

Comment by andrenarchy | Hacker News Reader

If you use javascript to extract the token from the URL then you can simply pass it via the hash ("fragment") part of the URL. The hash portion is only interpreted by the user agent and never sent to a server (see https://tools.ietf.org/html/rfc3986#section-3.5). This is how we solved it at paperhive.org.

View on HN

This has been suggested numerous time since I published. I had not previously considered this solution and I think it's a fine solution for people to make if they know the tradeoffs.

It's worth noting there are a number of reasons this JavaScript could possibly not execute beyond people who have JS turned off. I've seen a number of sites fail to execute JavaScript when an Ad Blocker is run, for instance.

In this case, there are a number of server side fixes available that wouldn't require any JavaScript. They're not terribly complicated and will always work. For that reason, I'm still comfortable with the server side fix, but think the JS fix is a decent alternative.

Obviously, the drawback is that you've introduced a javascript dependency to a core function which definitely doesn't require it. Having said that, I notice that paperhive.org renders an entirely blank page if javascript is unavailable, so I guess the password reset is the least of your concerns in that scenario.

And what percentage of the users have javascript disabled? Objectively you have bigger concerns when you run a site than 10 people who have js disabled.

Definitely more than zero. It's not just a case of javascript being disabled, either - there are many other reasons why it might be "unavailable", which is why I used that word.

Of course I'm not suggesting you're not allowed to use any javascript on your site, or even that you should only use it when it's strictly necessary, but if it's entirely unnecessary and you don't engage in best practise by, for example, using progressive enhancement, then that's something that could be improved.

I used to think so, but information sites probably needs to work without javascript, if only for google bot.

It's 2016, everyone has JS enabled.

The ones that don't are most likely bots (now even that's changing thanks to projects like phantomjs).

>everyone has JS enabled.

Using an addon like NoScript it's possible to selectively enable javascript per domain. When a website doesn't work without js I am forced to decide whether it's worth enabling js for this site. Very often I decide it's not worth it and I never use that site again.

You and I both. Remember, however, that you and I are not a representative sample of the general population of web users.

That would be meaningful if we were talking about some optional UX feature, but this is security. Does having a non-representative browser config mean we don't deserve security? I think not. Security has to work without JS.

Why wouldn't it just <noscript> an input field to enter the token

Can I ask your reasoning in doing this?

Why should we trust any website and execute their JS code on our machine? What about privacy, if they decide they can track us and sell the information to whoever they want? And even if they're "legit", what about the 3rd parties they might trust wrongly?

Honest question : what harm could possibly be done by Javascript?

Remote code execution for one: https://oreoshake.github.io/xss/rce/bugbounty/2015/09/08/xss...

What's more, rowhammer can be done from js: https://github.com/IAIK/rowhammerjs

I personally do this for some combination of privacy, security, and ad blocking.

I come to a website to read it, not for it (and who knows what else) to execute code on my machine, no matter how deep into the sandbox it is. If I want to watch the video and allow it to use my data, I will explicitly allow it.

When your browser runs JavaScript, it downloading and automatically executing untrusted, unsigned, ephemeral code. Even if the site is over SSL, only the _party_ is validated---the resources themselves are not signed.

If your browser instead presented the JavaScript as a program itself, and listed the programs it executed, and from what sources, users would have a wholly different perspective. JavaScript has the illusion of remote execution; most users don't think of it as executing programs on their computer.

Addons like NoScript are essential security precautions that mitigate a host of attacks. Unfortunately, even security-essential software like the Tor Browser Bundle leaves JS enabled by default because it'd "break" the web.

There's other reasons---as a free software user and activist, I won't run non-free JavaScript programs.

I gave a talk earlier this year about these problems and some ideas to solve them: https://media.libreplanet.org/u/libreplanet/collection/resto...

Gets around all the anti-ad-block websites and it is much, much, much faster.

Sadly doesn't work in Chrome.

And I hate it when a site is loading JavaScript from a large domain, e.g. cloudflare.com; generally I just close my browser window and view something else.

No way am I going to allow JavaScript from every single site using CloudFlare to run all at once.

For users without JavaScript it's reasonable to include a plain form and send token in plain text as well, so user can copy-paste it into a form and reset his password.

You are assuming that 3rd party javascript is not taking the whole URL including the hash part and sending it for analytics. I have seen at least one analytics company do that.

Wouldn't any (third-party) JavaScript on the page still have access to it?

They would also have access to everything else, including the entered password.

Right. The scenario I'm considering is not a hostile attacker but simple an overzealous analytics script which also tracked hash strings. Heck, since some sites used to do AJAX navigation that way it wouldn't surprise me if some analytics services were configured to track hash strings.

Reply on news.ycombinator.com