I enjoy seeding a random password generator with a bunch of non-ascii characters [1]. Often it fails telling me that I'm using unsupported characters, other times the form just doesn't return (or returns with a 5xx error), and even worse sometimes it lets me create the account but I can't login because they did something weird with those characters. I'd say less than 70% of sites let me login with one of these in my password...

At the very least try to use one of them (generally a simple alt-code works, the first smiley face is just alt+1), it's a pretty good indicator of which sites are mucking with your passwords.

[1]•◘○◙►◄↕‼¶§▬↨↑↓

Edit: Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!

The first "smiley face" on ALT-1 is actually the ASCII character SOH "start of heading"; many things that might otherwise accept Unicode will properly filter that out because ASCII control codes are illegal in a wide variety of otherwise-accepting contexts.

But it is a great QA check on any text field, which should either cleanly reject it in some manner [1] XOR accept it and process it "correctly" for whatever that means locally, but not something in between.

[1]: A lot of Unicode processing nowadays puts in the Unicode replacement character for unknown characters, but for the ASCII control codes I'd say you've often got a solid security case to say "Someone's just trying to screw with the system, we'll just filter it out entirely" for them. Excepting the ones we still use, basically \r \n \t, there's not much reason to keep them. (Think twice about \v "vertical tab" and think three times about letting \b "backspace"s through. Inconsistent behaviors by various layers of code are scary.)

It makes sense that control characters are removed (or replaced). I didn't know the ALT-1 was SOH, so that's good to know. (I guess I'm showing my age a bit there)

Thanks for the info!

> Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!

Which is exactly why I'd be wary of such clever password schemes on any account I cared about.

Try to create a password at Jet2.com. A Password like: "SuperSecretPassword!" gives you an error "Your password must be at least six characters or more and is case sensitive.". It's idiotic.

Oh yes, I'd almost forgotten about the misleading, unhelpful or downright incorrect error messages. It's also fun when account creation and login form don't use the same validation rules, so you can create an account but then you can't log into it.

Even major sites suffer from this. Netflix web UI allows 60 character passwords, but their Roku app and I believe the Xbox One app only allow 50 character passwords.

I ran into that once with my credit card company. I used a generator to create a maximum length password, only to discover that the Javascript managing the login had an off-by-one error and wouldn't accept that length. I was able to work around it through judicious use of browser inspection tools -- the change password page accepted it just fine.

I sent in a complaint and got something to the effect of "well, no one else reported it."

If you call in to your fidelity account, they ask you to type in your username and password with the keypad to authenticate yourself. I haven't given it much thought, so perhaps I'm wrong, but this struck me as probably based on some dicey insecure backend implementation.

More likely it is to prevent your having to say your password to the person on the phone. This protects you from a malicious bank employee.

Right, but my point is the backend to make this work must be terribly insecure. I just did some reading, and apparently they take your password and just store the keypad equivalent (or more likely, a hash thereof). So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

> So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

I'd have to see this to believe it. I would hope that they would at least store it as two separate entries, and only use the phone one during the phone process. And the person on the phone will likely still ask you some less-sensitive verification questions.

I had googled just now and read that somewhere else, but you are right, I just tested it, and it does not work as I described on the website itself.

> they take your password and just store the keypad equivalent (or more likely, a hash thereof)

That's… not exactly more likely. These are commonly systems predating the internet, from a time when connected networks were trade-specific and Very Expensive, storage security was a lesser concern (and CPU-expensive) when the system could only be accessed on dedicated lines only accessible to employees.

That'd certainly make sense — a lot of what we see now are fossils like that, frozen in the amber of legacy systems.

That would be a reasonable precaution in the era before recording devices became cheap, tiny and ubiquitous (or capable of doing signal processing in real-time) – just as changing passwords monthly made more sense in the 1970s when shoulder-surfing was the major threat and lack of remote access throttled guessing rates even more than slow CPUs. (Repeat for plastic ID cards before you could buy a printer at Costco, etc.)

I don't know what Fidelity does, but I work at a bank and if we were to implement such a feature we handle it securely. When you set your password we store a hash of the password, but we also store a hash of the keypad version of your password.

So logins to the website still use the full character set -- only logins via the phone are verified against the keypad mapping. That one has less entropy (because of the reduced character set) but attempts to brute-force it will QUICKLY be recognized and stopped, since each attempt is visible to a human being who is handling the phone call.

> think your password is "fido"? it's actually encoded as 3436)

A form of hashing... ⸮

VirginMedia (large ISP in the UK) won't accept passwords longer than 10 characters. No spaces or special characters allowed, must contain a number, must start with a letter etc.

What is really frustrating about this is when I asked them why they reply "we've chosen these limits to make sure your online password is secure"

I can imagine your facepalm.. Wondering how many of these "up to N characters" rules are actually there because there is a `password CHAR(N)` DDL declaration for storing plaintext passwords...

I tend to set password fields to varchar(400), though it's encoding info and base64 hashes.

    encoding\options\base64-salt\base64-hash-of-normalized-utf8

I keep the encoding/options so it can be backwards compatible on change... when an encoding/options isn't the current when the user logs in, it will be re-encoded/saved in the current... this is so that security can be upgraded over time.

Run normalization on composite unicode characters & look-a-likes before encoding.

I do one thing some consider bad, which is strip leading/trailing whitespace which is more often a copy-paste error, not actual password entry.

Additionally, if you contact their customer support via the form they used to provide they ask for your password, which is them presented back to you in plain text when they reply.

Quoting from a reply I had: "As there's no account password quoted on the form you’ve filled in I'm unable to go in to any account specifics."

"accountPassword: I'm not giving you my password"

Same with the Virgin Atlantic Flying Points site (usernames and passwords). Infuriating thing is the points are worth real money and can be transferred to other users so there is a real incentive to break in.

I guess it's a problem across the entire Virgin group of companies?