Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is there a good reason for disallowing some characters from a password?

news.ycombinator.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#71

Post by Someone1234 »

tzs wrote: post #69
Someone1234 wrote: post #67

Earlier quoted context omitted.

> I find it hard to believe that each customer has a user account on the mainframe Why? Do you actually have any experience in this area? I do, and I can tell you, they do exactly that. Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. Migrations are an absolute nightmare. > Users have to go through that to do online banking, and th…

> Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. How do the multiple systems communicate with each other and with the mainframe?

Depends on the company. Web API (with or without VPN), VAN + EDI, Dial Up Modem (not joking), Scripted SSH/Insecure Terminal, FTP/SFTP/FTPS w/XML or Scripts or EDI, etc. Some communications/integrations are bleeding edge, some are older than I am. It really varies.

Then you have multiple half-measure attempts at migration away from the mainframe, so you wind up with a half-built Java layer and a half-built [Large Contractor] bespoke system.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#72

Post by avinassh »

remram wrote: post #4

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.

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

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#73

Post by tzs »

Someone1234 wrote: post #71
tzs wrote: post #69

Earlier quoted context omitted.

> Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. How do the multiple systems communicate with each other and with the mainframe?

Depends on the company. Web API (with or without VPN), VAN + EDI, Dial Up Modem (not joking), Scripted SSH/Insecure Terminal, FTP/SFTP/FTPS w/XML or Scripts or EDI, etc. Some communications/integrations are bleeding edge, some are older than I am. It really varies. Then you have multiple half-measure attempts at migration away from the mainframe, so you wind up with a half-built Java layer and a half-built [Large Con…

Stepping back from all the details, somewhere in all their collection of assorted ancient systems, hacks and kludges from previously failed attempts to migrate to something newer, and whatever else they have, there is something that presents a public facing web site that customers can log in on for online banking. (I'm only talking about companies that offer web-based online banking, not companies that want to add online banking to a system that doesn't already have it).

There is something that handles the user's submission from that site and records somehow that the user is logged in, and directs the user's browser to some site that can somehow get their account information, balances, etc, from whatever that is stored, and can handle form submissions that request operations on those accounts such as transfers, bill pay, and such.

What I don't understand is where the difficulty would be in making it so customers do not talk directly to those web-based things, and instead talk to a web front end running on a separate, reasonably modern Unix, Unix-like, or Windows Server and that server talks those older web-based things. It could even talk to them over HTTP looking like a browser to the older components. The online banking front end would not have any direct integration with the rest of their systems. It would just go through the same interfaces they already are using to support online banking.

Heck that is essentially what Plaid does for banks that don't have a useable API. They log in to the bank's online banking site with the customer's credentials and then screen scrape to get the account balances. That has got to be a nightmare for Plaid because they have to deal with many different banks, any of which might make changes that break their scrapping with no notice.

A bank essentially doing its own Plaid that just has to work with its current online banking site should be a lot more doable.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#74

Post by csydas »

I think as long as the list is clear on what it must not have in advance and what it must have, it's not as big of a deal. Strings are a pain in the ass and come up with surprising ways to be frustrating, so I can totally get a restriction on some character.

What I cannot get is sites that make you play 20 questions to figure out their rules instead of just telling you, as in my experience, it leads to lousy passwords that meet only the bare minimum. I seem to recall some popular site (want to say it was AirBnB) which threw an error "password cannot contain name/username" for basically anything it didn't like, regardless of whether the password actually contained that, and it's very annoying.

It was one of the most welcomed changes to the password system at a former work place when I convinced the small team behind the authentication to put the requirements plain and simple and change from red to green as people met the requirements. We also added a passphrase helper that could be summoned if they missed requirements a few times which based on metrics got some fair use.

People generally want to do well by security and it's on their mind, but no one wants to look stupid because they can't think of a password that meets unknown requirements. Make it clear what's expected, and even a nudge towards how to think of good passphrases, and you'll get happy people using your site.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#75

Post by Fatnino »

cardanome wrote: post #48
SAI_Peregrinus wrote: post #39

Earlier quoted context omitted.

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

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.

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.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#77

Post by remram »

toast0 wrote: post #63
remram wrote: post #4

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.

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

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.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#78

Post by chrismorgan »

phlo wrote: post #59
chrismorgan wrote: post #46

Earlier quoted context omitted.

I don’t think it’s prudent for a system to disallow emoji passwords. Or to restrict various characters. I say: let the user do what they want to do; on their own heads be it if they do something that doesn’t work for them in all circumstances, and the end result is practically not much different from forgetting a password, which is normal . In general, passwords are not treated as essential for access, and there will…

I see where you're coming from, and looking at the problem from a purely technical perspective, I agree with you. A password is just a string of codepoints. Accept what you get, yeet it into a password hashing function, and be done with it. However, in my opinion, for real-world systems, you need to strike a balance between technical and operational, and user experience concerns. If restricting your password space to…

I expect the number of tickets induced by supporting Unicode to be a negligible fraction. (I offer no support for this expectation.) Depending on the type of service you’re running, you might even avoid a few tickets from people that might complain about the restrictions, though certainly most of the time people will just sigh and choose something else and not even think of contacting to complain.

No security drawback? You make it harder for people to use the password they want to use. There is a real cost to that, encouraging bad password hygiene. Provided you support at least printable ASCII it’s unlikely to be a significant cost, but it is a cost, and I remain entirely unconvinced of the practical benefits of the restriction.

Re: Ask HN: Is there a good reason for disallowing some characters from a password?

#79

Post by remram »

avinassh wrote: post #72
remram wrote: post #4

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.

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

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

Post reply on HN