[remram]

You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no.

Some sign-up forms don't even give you feedback on which characters are problematic. The Oracle Cloud one kept erroring with "you need one uppercase, one lowercase, and one number" when what it meant to say is "remove that tilde", that took a while to figure out.

[benj111]

(One of) my pet peeves is requiring a certain format for passwords but then not telling you at the password prompt.

I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all.

[SAI_Peregrinus]

> I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all.

You're supposed to use a password manager. Preferably with a passphrase and a second factor like a keyfile or hardware token.

[cardanome]

While password managers are great, there are some cases where I prefer to memorize the password.

That is because I want to be always able to easily access these accounts even when traveling or losing access to my technological devices. Though sadly these days things like 2FA make my life much harder in that regard.

[Fatnino]

Accounts that insists on doing 2fa over SMS...

No only is SMS generally considered insecure, it also falls down dramatically when I travel to the mountains where there's no cell coverage and try to do things on the cabin wifi.

[benj111]

Are you 'supposed to' or is that just the least worst option?

There are fairly limited scenarios when a password manager is better than a plain text document. And if it's online to actually share passwords between devices it's strictly worse.

[toast0]

> You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no.

If you do this, you should really save the version of the normalizing table you used, since they change over time.

[remram]

Damn, I didn't even think about that. On the other hand I feel like if your password includes the kind of characters for which normalization rules are changing, you'll just have to reset it if it breaks. Tracking the version of the table is more than I'm willing to do.

[avinassh]

> You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no.

what are these and why do you need to do it?

[remram]

Some Unicode characters can be represented with different sequences of Unicode codepoints. For example é can be a single codepoint U+00E9 "latin small letter E with acute" or it can be the two codepoints U+0065 "latin small letter E" and U+0301 "combining acute accent".

This is independent of the Unicode encoding, which turns those codepoints into bytes, for example using UTF-8 this gives C3A9 or 65CC81.

Users don't really have control about what their keyboard/application is putting in the text field when they press the button, and obviously the hash of those is different so the password wouldn't match. Normalization is the process of turning the characters into its composed form (in my example "\u00E9") or the decomposed form ("\u0065\u0301"), so you can then compare your codepoints/bytes/hashes.

https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat...