You can avoid brute force attacks by rate-limiting password guesses.
Password Requirements: Myths and Madness
81–90 of 257 posts
Re: Password Requirements: Myths and Madness
#82Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised. Otherwise I can know for certain when something is not your password each time I get it wrong.
> Rotating passwords is an old idea but mathematically it does reduce the probability of bring compromised.
Please can you show your work.
Most websites limit the attempts per user per time, which should make direct request break-ins unrealistic to mathematically impossible. So now we move the needle to "Your user database has been stolen, someone is trying to break hashed + salted passwords" which is such a problematic scenario for so many other reasons (e.g. unencrypted password recovery information stolen, PII stolen, and social engineering information verification info stolen) that rotating user's passwords weeks-months later is such wishful thinking.
Like, I legitimately don't get it. It was created in the late 1980s by people who just did what sounded right, and we've been stuck with it for over thirty years because change it hard.
Re: Password Requirements: Myths and Madness
#83Earlier quoted context omitted.
I have had trouble convincing people before, would you happen to have a link ?
https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret They refer to it as a “Memorized Secret“. The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions: > composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, an…
I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo.
Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home.
This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for some reason :)
Re: Password Requirements: Myths and Madness
#84There are only really two types of passwords: Passwords for online accounts and passwords used to encrypt things.
Imagine the password for my Gmail is Watermelon45. Theory says that's super weak, but I'm not a watermelon farmer and I wasn't born in 1945 so nobody who knows me is ever going to guess it. I trust Google will effectively block against brute force attacks by rate limiting login attempts, and if Google is breached and the password cracked as long as I'm not reusing it somewhere else it doesn't matter.
Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force. So external storage, computer logins, ssh keys are perhaps examples of the very few situations where high entropy passwords are actually useful. For everything else which is 95% of passwords, easy to remember but unique is fine.
Re: Password Requirements: Myths and Madness
#85My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password
An early version of TBBS didn't require usernames and the passwords had to be unique over all accounts. If you signed up for a new account and selected a password someone else already had, it would tell you so. You could then use that password to login as the other user. Obviously that wasn't very secure but probably was created with a small number of closely affiliated people using the system in mind.
Re: Password Requirements: Myths and Madness
#86Earlier quoted context omitted.
From this doc: https://pages.nist.gov/800-63-3/sp800-63b.html There’s also this great quote: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). There’s other great stuff in there as well like that…
Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
It’s the absolute best way to make sure all your passwords are insecure garbage.
Re: Password Requirements: Myths and Madness
#87In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees.
After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.
Re: Password Requirements: Myths and Madness
#88Earlier quoted context omitted.
From this doc: https://pages.nist.gov/800-63-3/sp800-63b.html There’s also this great quote: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). There’s other great stuff in there as well like that…
Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
My former company required not to use one of the last 10 passwords. So every 3 months, employees did the 11-password dance, setting the password back to the original one.
Re: Password Requirements: Myths and Madness
#89Earlier quoted context omitted.
> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.
I think you missed the word “similarity”. You can’t check similarity with hashes, only exact matches
Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity?
That's literally impossible without plaintext passwords isn't it. That is insane.
Re: Password Requirements: Myths and Madness
#90In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
This is likely the best way to deal with the inertia exerted by antiquated requirements: Most (keyword being 'most') businesses tend to follow the rules laid out by authorities, so an appeal to authority works in this regard.