71–80 of 129 posts
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…
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…
I like to call those sites out and have submitted some to https://github.com/duffn/dumb-password-rules
If they cannot get it right, how does that leave the rest of us?
Here's a python implementation using bloom filters which avoids storing the whole list (need to store ~1 gig), yet still gives you very good accuracy: https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2...
It's more what I think this should look like.
All of those rely on Troy Hunt's API. Which may be fine for some people, yet others may uncomfortable introducing an external dependency. I generally recommend avoiding external API dependencies if you can. Here's a python implementation using bloom filters which avoids storing the whole list (need to store ~1 gig), yet still gives you very good accuracy: https://gist.github.com/marcan/23e1ec416bf884dcd7f0e635ce5f2..…
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…
why would they even do that?
Pointy haired bosses often deliver solutions based on what sounds like an admirable position to take, or a point of view that makes them look good politically. One that sounds good in a rapid fire round table discussion, like a daily stand up, where the boss’ boss needs two sound bites from them because he’s VERY busy, and doesn’t have the time to think deeply before cocktails at lunch, and an afternoon of golf.
Q. Give me your update on the password business.
A. Very good sir, we’re making users pick strong passwords.
Q. What defines the strength of the password?
A. Well, we assign 10 requirements, to ensure the user picks something sufficiently random. More requirements is better than no requirements.
For online attacks, an attacker can't even try the top 1000 passwords on for an account in any major website in reasonable time without triggering the alarm, as they all(?) have rate limiting (usually in the form of account lockdown after single-digit failed attempts).
For offline attacks, there first needs to be a breach. While they undoubtedly happen, they are very infrequent events. But once they happen, you should assume all passwords would be cracked very fast. Hackers can get their hands on a lot of computing power, and the brute-forcing attempts are not alphabetical, but rather clever how-humans-chose-passwords models. You're relatively safe because of the low frequency of breaches, not because a hacker trying trillions of passwords a second will be frustrated by your password choosing policy. I'm sure most of the passwords from the breaches would be attempted anyway.
Credential stuffing[0] is the real issue. If there was an API to test that a user isn't using this password on other websites, that would be very useful.
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…
There’s something that I don’t really understand regarding password managers which maybe you could explain. How is using a password manager to manage multiple passwords more secure than using a single password everywhere? In the case of a password manager, if your computer is breached, then all passwords are breached. If your passwords are hosted encrypted on a website, then if that website is breached, the master pa…
Seems like eventualy you'll end up driving away everyone who isn't tech savvy/doesn't use a password manager/randomly generated password, which seems like something that'll significantly limit your site or app's audience.
I get the logic behind it, and it's a neat idea on a security level, but it seems like a guaranteed way to drive your userbase to your competitors by making it annoying to sign up.
This is over the top. Even enforcing password complexity is over-rated. For online attacks, an attacker can't even try the top 1000 passwords on for an account in any major website in reasonable time without triggering the alarm, as they all(?) have rate limiting (usually in the form of account lockdown after single-digit failed attempts). For offline attacks, there first needs to be a breach. While they undoubtedly…
Before that, attackers would just wait for new usernames to appear on the scoreboard/chat and check them against password dumps. The easy come, easy go nature of bitcoin made it particularly lucrative.
Password reuse is a massive issue. At a glance, one might wonder why most sites need to care so much since they don't deal with money. Who cares about a forum like HN? But consider that it's easier to audit/impede new accounts with anti-spam measures, so there's value in taking over old accounts. And you don't want people with moderation tools getting attacked either. Ideally, it's nice to be able to trust an account with 1,000 posts more than one with 0 posts, but that evaporates when accounts are easily stolen.
Aside, how do you implement account-locking without making it trivial for users to DoS each other that way?