> 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.
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.
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.
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.
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.
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...
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.
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.
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).
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 :)
This annoys me the most, my password contains some of those characters.
Why is this even a restriction or is just poorly developed code?