Hacker News Reader

Comment by colinclerk | Hacker News Reader

Perhaps surprisingly, US government guidelines exist, are pretty fantastic, and agree with the author:

  Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.

It's called NIST 800 63-B and available here: https://pages.nist.gov/800-63-3/sp800-63b.html

Shameless plug - I'm the cofounder of Clerk and we handle passwords in a sane way out-of-the-box: https://clerk.dev/features/passwords

View on HN

6 characters and entirely numeric seems like a bad idea, or am I missing something?

That provides one million possibilities. I don't think you're missing anything. That's pretty terrible.

The only thing prolonging your account at that point is the service's rate-limiting, assuming a naive "enter this password in the login field, try it, repeat."

On the other hand, if you have too many password requirements and the user can’t remember it, they often lean on bad password hygiene, and the password ends up being reused (and inevitably leaked) or written down somewhere.

The numeric-only stipulation was in the "Memorized secrets chosen randomly by the CSP or verifier" category. Not chosen by the user.

Rate limiting can be practically strong for everyday use. Bank PINs are commonly 4 digits, though the chip+PIN system allows up to at least 6. Three attempts and the card is locked. Provided you stop users from picking obvious numbers like birthdays, it's pretty effective at preventing card fraud.

Weak passwords can be fine, provided rate limiting is extremely aggressive. You can adjust this based on access e.g. your admin account might be locked under stricter heuristics like a single attempted login outside your geographic region (Live mail does this to me sometimes). In this case the user might even have the correct password, but if something else doesn't add up then you can block.

But if you actually tried to use 6 digits you'll discover most layers never tested it, including some of the most common point-of-sale systems and many ATMs not operated by your bank. Plus, tellers at your bank won't believe you.

My debit card in Switzerland came with a six digit pin - which was a surprise coming from the UK - and it works fine in other countries (Germany and Italy at least). But chip and pin is well known established in Europe so that's not too surprising.

Interesting - I should have qualified all that as US specific, I (stupidly) forgot you have debit card pins as well.

To continue that quote from above:

> A rationale for this is presented in Appendix A Strength of Memorized Secrets.

The relevant part of which reads:

> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...

> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

My reading was not that it must be entirely numeric, but that there is no rule that it won't be. As in, an attacker cannot make any assumptions about the characters in the randomly chosen password, such as "well it won't be all numbers, so lets rule out all those possibilities The 6 character limit only seems to apply to randomly assigned ones, not to ones the user picks, which is where a strategy like "what about all the number combinations" is more useful.

Any kind of bias like that is potentially exploitable, though. If the rule allows "only numeric", and that's the simplest thing to implement, then someone's going to implement it that way.

Which means that an attacker now knows that moving "only numeric" to the beginning of their attack sequence may be a viable strategy. Whereas if the rule did not specify, the attack would not be able to make assumptions about the character set.

Re: entirely numeric, as long as the attacker assumes that the victim may use letters in their password, all numbers is fine, it increases the total number of possible combinations an attacker needs to work through

It's...not great, but can be handy if you pick something that isn't really identifiable - mostly dates.

On a few sites I've actually used old student ID #'s - easy to type and reasonably long, with the exception of one, all are 6+ characters.

I interpreted it backwards, "if you want to use a numeric keypad for controlling access to something, the codes MUST be at least 6 digits long, and you MUST assign them"

It's fine if there's no way an attacker can execute a brute-force attack. And that can even be prevented in hardware. The iPhone is a good example.

6 numeric characters is only ~20 bits. 8 is only 27 bits.

Far too short.

6 characters in length seems a bit shoddy.

Yeah, bump that to 8 and it's more reasonable. And if it's already required to be randomly chosen, why not 10?

It's not 10 because it still needs to be memorized.

That’s the key people are missing. There’s a trade-off (though people can easily memorize phone numbers for example) when the password gets to complicated and you have to write it down.

I know it's hard to imagine, but before we all held supercomputers in our pockets we all used to have dozens of ten-digit numbers memorized. I still remember my grade school friends' phone numbers.

You were an extreme outlier if you bothered to memorize dozens of ten digit phone numbers in the era before everyone had a cellphone.

The average person doesn't even have ten good friends, much less a need to memorize dozens of phone numbers. They would buy address books / contact books to write down dozens of numbers, not memorize numbers they very rarely use.

Or even more niche in your outlier status if you could remember IPs of the commonly used servers without a DNS in place.

Most of the time, local networked IPs all start with the same values for the first 3 octets (maybe 2 if VLAN but then usually only one digit diff). The same was true for most people's local phone number memorized registry. Those of us old enough, we only had to dial 5 digits using (70s) the last number of the prefix before eventually moving to 7 digits to include the full prefix (80s). The world suddenly changed when we had to dial the entire area code as well (90s).

I think "dozens" is an overstatement, but 10-20 wasn't unusual. In college, I could have given you the number for a dozen delivery restaurants, easily. Not proud of it, just saying. That's not counting family, friends, services like taxi companies and movie theaters, and work.

How many different area codes did those dozen delivery restaurants and taxi companies have? How many different exchanges? Was each one a unique area code, each a unique exchange? If not, then you're not really remembering unique 10 digit numbers. There's going to be a lot of repeated numbers in there.

I remember 2 out of the 3 landline numbers (one is my parents, still using that) I used to know, my 2 ICQ numbers, and my mobile phone number (which is still the same now, 20 years later). I never felt the need to remember a ton of numbers, that’s what phone books (digital or analog) are for and why I now use a password manager ;)

You didn't memorize ten random digits. Area code, exchange, four digit extension is six things...

Area code was likely all the same, maybe 2-3 tops, and associated both with the following exchange and geography, and used extensively.

Exchange, also likely all the same, maybe 6 at most, and again likely associated with geography.

On top of that, in many areas in the US the time between moving to ten-digit dialing and the time of cell phones becoming even somewhat popular is really only a few years or less. Some places in the US are only finally being forced to move to ten digit dialing with some places still supporting seven digit dialing.

https://www.kcbd.com/2021/10/12/new-10-digit-dialing-procedu...

Note the date on this: Oct 2021!

> Starting on Monday, October 25, 2021, Texans with phone numbers in the 254, 361, 409, 806, 830, 915 and 940 area codes must dial 10-digits (area code + telephone number) for all local calls.

Sure but for most of them it was only ~ the last 5 digits that differed. Unless you were more cosmopolitan and made lots of long distance calls.

Rate limit the requests. Do an account lockout with an email click to re-enable after 10 guesses, do 2FA on new devices and you get pretty good security.

For many systems, users can memorize 6 digits easily.

The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.

None of that will help you if your hash database leaks. But I'm ok with letting the decision with the user.

Interesting. In most cases if hash database leaks, the ability to crack depends on two factors, not one (password and hash difficulty) assuming you are salting properly.

You can specify pretty high difficulty with argon2id etc. Ie, shoot for a one second runtime with a very high memory requirement (you can go to GB range even).

So I'm not sure all is always necessarily lost

Reply on news.ycombinator.com