[leejo]

I just logged in to change my easyJet password:

> Your password must be a single word between 6 and 20 characters in length and must not include the special characters # & + or space.

Come on! This is ridiculous. If you're going to get hacked at least have a sane password policy.

[Sosh101]

Doesn't a max length suggest that they are storing passwords rather than hashes?

[borplk]

It doesn't necessarily mean that.

A limit always exists. If you don't enforce it yourself you will find out when someone decides to send you 64GB of data to hash as their password. So always better enforce the limit yourself.

[PUSH_AX]

Sure could be, but to play devils advocate maybe not, some hashing libraries have limits (silent truncation or otherwise) and/or it could be reasonable not to allow users to make the backend hash strings of unbounded length.

These specific limitations indicate that it's more likely to be something bad however, it's funny because I remember adding EasyJet to https://github.com/dumb-password-rules/dumb-password-rules/p... last year.

[thephyber]

Not guaranteed, but it suggests that their company processes aren't Password Manager friendly.

[capableweb]

Still better than my bank (one of Spain's biggest) that requires your password to be 8 (not less, not more) digits.

[marsRoverDev]

HSBC in France have the same, it's a huge motivator for me to switch away.

[jesterson]

May I know why? It's a problem if there is no 2FA but I doubt HSBC won't have 2FA and this password requirements.

[capableweb]

The bank I'm using has 2FA for all actions performed in the website, so that's my guess as to why they don't prioritize fixing the lame password requirement.

[jesterson]

Exactly. 2FA is much more important than complicated password (not that I'm advocating to have a guessable one here), altogether providing acceptable level of security.

[gerdesj]

Use "password" - eight letters and it's English and so should be safe on a Spanish site.

[capableweb]

You missed that we're only allowed to use digits/numbers. No letters!

[coremoff]

72779673

[hannasanarion]

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

[trickstra]

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.

[thephyber]

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

[derwiki]

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.

[jakub_g]

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 :)

[anon73044]

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.

[leejo]

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.

[x86_64Ubuntu]

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.

[ShinTakuya]

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.

[zwp]

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

[ShinTakuya]

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.

[x86_64Ubuntu]

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.

[hannasanarion]

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.

[leejo]

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.

[thephyber]

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.

[doublerabbit]

> must not include the special characters # & + or space.

This annoys me the most, my password contains some of those characters.

Why is this even a restriction or is just poorly developed code?