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

51–60 of 79 posts

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

#51

Post by BjoernKW »

daneel_w wrote: post #34
can16358p wrote: post #23

Mandatory plug: https://xkcd.com/936/

Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.

To offer a slightly more accurate measure than "half a jiffy", this article (published on May 9, 2022) lists the costs involved for different types of passwords and password lengths:

https://support.1password.com/pbkdf2/

Clocking in at a cracking cost of 79 million USD, for most intents and purposes, even a rather trivial 56-bit entropy password such as "align-caught-boycott-delete" (or "correct horse battery staple", for that matter) would be prohibitively expensive to break.

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

#52

Post by wizofaus »

adamrmcd wrote: post #49
wizofaus wrote: post #22

Allowing linefeeds/carriage returns/ASCII nulls seems like a bad idea. I have wanted to include backspace in a password though!

Unless you're manually injecting 0x08 into a database record, isn't it your keyboard that interprets your backspace into the UI layer. There's no way to type a backspace without literally pressing backspace :) Regarding the null, if it's C based, theoretically your password just stops there. All other chars after that would be ignored. Now I wonder, what would other non-C languages do if they see 0x00 in a string?

A password entry control doesn't have to interpret backspace the same way a regular text input control does (obviously meaning you'd need an alternative method of correcting typos). The 08 character can still be part of the control's "text" property that is ultimately hashed/stored etc. As for nulls, languages not based on C handle them fine but you'd have to be very careful they never got passed to an OS-level function, which nearly always treat them as terminators.

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

#53

Post by Someone1234 »

vidanay wrote: post #32
Someone1234 wrote: post #11

Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc). For a specific example Oracle Database has a very restrictive list of characters allowed in a user password. If you're using Database Users behind the scenes (even if not directly, but via an Oracle integration) you're subject to those same restrictions. Up until Oracle 11g passwords were also limited to 30 characte…

If you're storing a raw password in a database, limiting specific characters is waaaay down on the list of things you're doing wrong.

My post said nothing about storing "raw passwords in a database." Therefore, it is unclear what you're replying to.

I am talking about Oracle Database Users and Oracle Database's password limitations therein. The reason for Oracle Database's password restrictions isn't to do with how they're stored on disk (which is secure as if 12c[0]), it is to do with how they were implemented originally (i.e. passwords are implemented as database objects, and database objects have max lengths and other naming rules which apply to passwords).

[0] https://seanstuber.com/how-oracle-stores-passwords/

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

#54

Post by Bakary »

chrismorgan wrote: post #46
phlo wrote: post #31

Let's start at the edgest of cases. Some emoji, for example, are combinations of multiple other emoji, and a given combined emoji may not be uniquely represented by a sequence of codepoints. In the pathological case, this could mean that an OS update on the user's system changes the composition of the same emoji, which might make it impossible for them to input their password. It is probably prudent for a system to d…

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…

Reversing the argument a bit: what incentive does the dev have to not restrict characters and be done with it? It's basically getting rid of various problems at no cost. And the type of customer demographic annoyed by this will not only be tiny in number but will also probably be annoyed by other things as well anyway.

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

#55

Post by ElectricalUnion »

daneel_w wrote: post #34
can16358p wrote: post #23

Mandatory plug: https://xkcd.com/936/

Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.

> A dictionary attack breaks a mere four English words in half a jiffy.

What system allows you to try 2⁴³ passwords in half a jiffy?

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

#56

Post by barrkel »

vidanay wrote: post #32
Someone1234 wrote: post #11

Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc). For a specific example Oracle Database has a very restrictive list of characters allowed in a user password. If you're using Database Users behind the scenes (even if not directly, but via an Oracle integration) you're subject to those same restrictions. Up until Oracle 11g passwords were also limited to 30 characte…

If you're storing a raw password in a database, limiting specific characters is waaaay down on the list of things you're doing wrong.

Most likely what's being talked about here is using Oracle to track identity across accesses to data on a per user basis, for permissions and auditing, and that piggybacking on Oracle's own password management with its own restrictions.

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

#57

Post by tzs »

Someone1234 wrote: post #11

Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc). For a specific example Oracle Database has a very restrictive list of characters allowed in a user password. If you're using Database Users behind the scenes (even if not directly, but via an Oracle integration) you're subject to those same restrictions. Up until Oracle 11g passwords were also limited to 30 characte…

> Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc)

I've heard banks and other financial institutions use the "our ancient mainframe only allows 8 characters in account passwords" excuse or "our ancient mainframe database can only handle 8 characters in the password column", and find it extremely hard to believe.

First of all, I find it hard to believe that each customer has a user account on the mainframe, and so the mainframe's restrictions on account passwords is irrelevant. Your banking account is going to be entirely something defined by the database.

Second, I find it hard to believe that they are running their web server on their ancient mainframe OS. The web server is going to be running on something more modern. Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. Your user name (if their online banking uses something other than you account number) and you password for online banking should be entirely handled on the Unix or Unix-like or Windows Server that is running their web-facing stuff. The ancient mainframe stuff should never see it.

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

#58

Post by daneel_w »

BjoernKW wrote: post #51
daneel_w wrote: post #34

Earlier quoted context omitted.

Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.

To offer a slightly more accurate measure than "half a jiffy", this article (published on May 9, 2022) lists the costs involved for different types of passwords and password lengths: https://support.1password.com/pbkdf2/ Clocking in at a cracking cost of 79 million USD, for most intents and purposes, even a rather trivial 56-bit entropy password such as "align-caught-boycott-delete" (or "correct horse battery staple"…

In the case of PBKDF2 it hinges on what PRF and how many rounds. As an example, WPA2 uses PBKDF2 with an HMAC and accompanying parameters to the tune of a single upper-tier consumer GPU being able to test just over a million passwords per second through hashcat. Realistically you will find the password long before you're close to the end of the key space.

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

#59

Post by phlo »

chrismorgan wrote: post #46
phlo wrote: post #31

Let's start at the edgest of cases. Some emoji, for example, are combinations of multiple other emoji, and a given combined emoji may not be uniquely represented by a sequence of codepoints. In the pathological case, this could mean that an OS update on the user's system changes the composition of the same emoji, which might make it impossible for them to input their password. It is probably prudent for a system to d…

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 printable ASCII characters can meaningfully decrease the amount of the tickets that generate half of your ticket volume, you should give it some serious thought.

There are good arguments for both approaches, and the right way also depends on your user base. There was a story about WhatsApp a while ago, criticizing that WhatsApp would only notify users when their contacts' security code had changed, whereas Signal (and other secure messengers) would block and ask for confirmation first. Signal currently sits at 100M+ downloads in Play store, WhatsApp sits at 5B+. The numbers are very vague, but WA has 1-2 orders of magnitude more users than Signal.

In the WhatsApp example, a small change in the process can mean that good security becomes accessible to a pool of billions of users, vs. excellent security to millions. Restricting the password character set (to a sensible set of characters, and with a sensible length limit) comes with no security drawbacks, and good chances of some process/usability improvements. For a real-world deployment, I would argue it's very prudent.

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

#60

Post by blincoln »

daneel_w wrote: post #34
can16358p wrote: post #23

Mandatory plug: https://xkcd.com/936/

Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.

Maybe you can correct my math. English has something like 500,000 words, but adults who speak it natively know 20,000 - 35,000[1]. If we cut that down to 10,000 to be conservative, that's still 10,000,000,000,000,000 (10 quadrillion) combinations at four words in a password. That's not including any capitalization, special characters between words, etc., just the stock XKCD "four random English words".

No provider is going to let anyone try that many combinations against a login API, but let's consider the case where the hashes have been captured. Hashcat on a Radeon RX 6650 can test about 30 billion MD5 hashes per second, about 200,000 sha512crypt hashes per second, about 500,000 MacOS PBKDF2 passwords per second, and about 32,000 bcrypt hashes per second.[2][3]

To brute-force the "four random English words" space for a single password, I therefore calculate:

MD5: 333,333 seconds (a little under 4 days)

sha512crypt: 50,000,000,000 seconds (578,703 days, or 1,585 years)

Mac OS PBKDF2: 2,000,0000,000 seconds (231,481 days, or 634 years)

bcrypt: 312,500,000,000 seconds (3,616,898 days, or 9909 years)

No one recommends storing passwords as MD5 hashes anymore, but that's the fastest algorithm Hashcat supports. When using the kind of hash that information security specialists tend to recommend these days, it seems like the XKCD method is still pretty safe. Am I missing something? Did I calculate something incorrectly?

Edit 1: Fixed the figures for sha512crypt.

Edit 2: for the NVidia A100 you mentioned in another branch of this thread, it would be about ten times faster per GPU, but it's still an impractically long time for the modern password hashes unless the adversary has millions of dollars to spend on cracking a high-value account's password.

[1] https://wordcounter.io/blog/how-many-words-are-in-the-englis...

[2] https://hashcat.net/forum/thread-10919.html

[3] It would be slower to handle the four English words case, because AFAIK you'd need to use the wordlist mode instead of straight brute force.

[4] https://gist.github.com/Chick3nman/d65bcd5c137626c0fcb05078b...

Post reply on HN