Live data from Hacker News

Prevent users registering with passwords from data breaches

jordanhall.co.uk

51–60 of 129 posts

Re: Prevent users registering with passwords from data breaches

#51
post #40

Earlier quoted context omitted.

Well there is one important factor about these 20 trillion passwords: are they associated with real user accounts? If not then it really doesn't matter that they got published. They're useless to hackers without knowing what email to type in. The attack model is that the attacker actually has to log into a website and you don't get 20 trillion attempts.

Never underestimate the ingenuity of the user. They might search for a list of good passwords, find it, and pick one. > The attack model is that the attacker actually has to log into a website Not to find the password. If it was then nobody would get upset about plaintext password storage.

Right - "attacker gets an old database backup, and wants to escalate to access to the live website" (or perhaps "attacker breaches QA", or something) is a realistic attack model. Take all the known passwords, hash them, match the hashes against the database, look at the next column over to see whose accounts you compromised.

Re: Prevent users registering with passwords from data breaches

#52

Earlier quoted context omitted.

64? How much entropy is in the passwords you're pasting? While holistically I like to see maximum lengths of 200+, personally I'm satisfied with 20 characters holding 119 bits of entropy.

I find a passphrase (e.g., half a dozen words from the diceware list) easier to memorize than random gibberish and symbols, so it's disappointing that they're so rarely allowed.

I understand that entirely, but I'm asking someone that specifically said they don't type their 64 characters.

Re: Prevent users registering with passwords from data breaches

#53
post #48

If you say to the user, "sorry but that password is too common - please try again" then the user will simply add a 1 to the end of the password and press submit. That doesn't offer much improvement in security.

If that happens commonly, the original password with a 1 appended will probably eventually appear in a future HIBP database. In fact, the user could continue adding 1s until they either give up and try something different, or until it becomes uncommon enough.

Re: Prevent users registering with passwords from data breaches

#54

I need password fields to: 1)not silently fail when I try a 64 character (or 32 character) password 2)not fail and say my password is "too short" when it is 32 characters and you have an unrevealed maximum password length of fewer characters than that. 3)just all-around quit failing when my password is totally fine, it's a quasi-random string of letters, numbers, and symbols and I'll never type it... oh yeah 4)don't…

And not complain it doesn’t have enough entropy because it lacks special characters when it is a hex of a 128bit key!

What I find the most annoying is that developers enjoy creativity for password validation. Some requires special characters, but only from 2 or 3 allowed special characters (what good does it even do in term of entropy???). Some limit the number of times a character can appear in a password, and I understand that it is meant to prevent people using “aaabbbccc” as a password but it also makes long passwords impossible. Many have an artificially low length limit (why would they even do that)?

Re: Prevent users registering with passwords from data breaches

#56
post #37

And I thought we were getting away from arcane rules for passwords. Now you have to avoid every compromised password from any unrelated account? I may use random passwords, but I don't expect the typical consumer to do the same. Sometimes I simply don't care about security for a one off account on a free service where I'll happily use the simplest permutation of "password" for the password.

The existence of password breach databases means that attackers are already attempting other people's passwords against your accounts. We should honestly move to the world where typical consumers are using password managers that generate passwords randomly. I think it is pretty reasonable to expect the typical consumer to install and use a password manager; I think it's pretty unreasonable to expect the typical consu…

Realistically even a dictionary attack for a login service should have some sort of flag after repeated incorrect passwords or at least be rate limited to some degree. It would really only be bad if they gained access to your hashed passwords database table because then the dictionary attack would immediately hit for some weak passwords. I argue that access to the hashes shouldn’t be allowed in the first place.

Re: Prevent users registering with passwords from data breaches

#57
post #54

I need password fields to: 1)not silently fail when I try a 64 character (or 32 character) password 2)not fail and say my password is "too short" when it is 32 characters and you have an unrevealed maximum password length of fewer characters than that. 3)just all-around quit failing when my password is totally fine, it's a quasi-random string of letters, numbers, and symbols and I'll never type it... oh yeah 4)don't…

And not complain it doesn’t have enough entropy because it lacks special characters when it is a hex of a 128bit key! What I find the most annoying is that developers enjoy creativity for password validation. Some requires special characters, but only from 2 or 3 allowed special characters (what good does it even do in term of entropy???). Some limit the number of times a character can appear in a password, and I und…

I've implemented multiple such systems and I can say it's never been a case of the developer enjoying it. These dumb requirements always come from an exec that knows better. At one point a marketing manager informed me I "don't understand password security" while handing me a non-negotiable list of dumb mechanisms like you described.

Re: Prevent users registering with passwords from data breaches

#59

And I thought we were getting away from arcane rules for passwords. Now you have to avoid every compromised password from any unrelated account? I may use random passwords, but I don't expect the typical consumer to do the same. Sometimes I simply don't care about security for a one off account on a free service where I'll happily use the simplest permutation of "password" for the password.

I think every entity which holds a password should adopt the same policy: from the moment the password is created, the entity will undertake to do everything it can to try and break it. Whatever it takes - bot farms, 3rd-party white hat outfits, social engineering in the canteen, whatever. Anything (legal) goes.

Once the password is broken, the account will immediately be placed in suspense until the owner creates a new password. Which, of course, immediately gets fed back into the machine and life goes on.

This would eliminate password rules. If you want to create a password which consists of, say, 100 consecutive zeros, go for it. But you might only get to use it for a fraction of a second if the network can break it quickly.

Re: Prevent users registering with passwords from data breaches

#60
What is the latest and greatest in password creation rules anyway? It is hard to define a password policy which covers both users' practical needs and still makes ERP systems secure and follows best practice of the major players.

Microsoft research has an interesting paper on it. Are there more like this out there? https://www.microsoft.com/en-us/research/wp-content/uploads/...

Hints welcome!

Post reply on HN