Hacker News Reader

Comment by hannasanarion | Hacker News Reader

How much you wanna bet they weren't salting passwords in the backend?

Every time I see passwords with a list of excluded characters, I assume their system breaks when processing such passwords in plaintext. Hashes wouldn't cause any problems.

It could also be because they had imperfect character escaping in the codebase at some previous point in time and didn't bother to migrate user credentials to work exclusively with the newer correctly-escaped code.

Fun fact: PHP used to escape some characters in some POSTed data by default before a specific version, then changed the default config:

> Prior to PHP 5.4.0, the PHP directive magic_quotes_gpc was on by default and it essentially ran addslashes() on all GET, POST and COOKIE data.[1]

I know for a fact some of users of a previous site I worked on had stored their password (hash) with one escaping mechanism, only to start failing authentication after that function was no longer used upon data input (all escaping should be done upon output for more perfect control of different security contexts eg. escaped HTML versus escaped SQL versus escaped JSON).

[1] https://www.php.net/manual/en/function.addslashes.php

I remember reading that a somewhat-legitimate reason for blocking special characters is that it's a signal for keyloggers that the typed string might be a password. After briefly searching Google, I couldn't find anything to support that theory though.

It's an interesting point, but I think when the user has a keylogger, they've already lost. I'd rather have websites disallow passwords shorter than ~10 chars which are trivially brute-force'able in case of a leak.

If special chars can be a signal for keyloggers, so are strings > 10 chars, and strings which are not all-lowercase/all-uppercase/first-capital. Basically to mislead the keylogger in this way, the user would have to use a short all-lowercase dictionary password :)

I jokingly like the idea of using utf-8 emojis in a password. They're available on nearly all phones and web browsers, common enough to not be susceptible to those sort of keyloggers and don't show up in any of the largest dictionaries/rainbow tables.

Possible, maybe not even hashed?

Given the disallowed chars that's suggestive that the form used to be implemented as a GET, so it's possible passwords were in log files for a long time.

Is there a technical reason to use a GET for authentication? I've always seen it as a POST. If you use GET, won't your parameters be plainly visible in well, everything, unless they put them in the body and that's a whole nother can of worms.

I have definitely seen some sites using GET for authentication, they tend to be ones that have been around for a long time and haven't been fixed. Can't remember the last time I saw this though.

I'm not sure when easyJet first started using online accounts, but "you can't use some URI query reserved chars" does seem like a strong indicator there used to be a GET involved.

No, https encrypts the URL as well (although the domain itself can be leaked via DNS). But in most respects query params are no different to the body security wise. The main difference is that if you bookmark it, you may end up storing your sensitive data in your bookmarks.

Query params often end in stuff like web server (WAF, load-balancer, reverse proxy, ...) access logs and they might get accidentally exposed.

They shouldn't get exposed of course, but they do. [EDIT: redacted an example of some random dude's access log]

If you search for "password" in there you will likely see a new Mirai bot variant [1] bouncing credentials off the server looking for weblogin.cgi on vulnerable Zyxel devices.

I imagine PA highlit this detail in their post ("weblogin.cgi accepts both HTTP GET and POST") exactly to ensure sure defenders don't restrict themselves to blocking or investigating only the more normal POST mechanism.

[1] https://unit42.paloaltonetworks.com/new-mirai-variant-mukash...

Yeah that's a fair point. So the security is worse in that sense, so many ways to leak it. It'd be insanity to put sensitive info in the query params either way. It's just not the appropriate place for them.

I had no clue the URL was encrypted too. So how does DNS work? Or does it send through plaintext the name of the server, and the rest of the URL has to be encrypted by the endpoint.

The domain name is not encrypted, but the path and querystring are.

So, a spy watching your https traffic knows that you're interacting with news.ycombinator.com (and possibly other things), but they don't know anything that goes after the `/`: which thread, whether you're POSTing or GETting, or of course any of the content.

No. GET params in the URL should not have security-sensitive data this wasn't always widely known. Even in HTTPS-everywhere world, there are still security implications.

Early versions of some PHP sites, for example, would pass around auth tokens (think the auth cookie) in a URL. This soon became an obvious problem when users copy-pasted their URLs into forum posts, non-HTTPS URLs were logged by proxies, and web server access logs became gold mines for maybe-still-active sessions.

Reply on news.ycombinator.com