51–60 of 257 posts
Earlier quoted context omitted.
Funny, sure. But you still can have the same transaction by hashing "CorrectHorseBatteryStaple" then comparing with the stored hash.
I think the OP is arguing you can guess a (possibly) current password this way.
In 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…
I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These checklists are pushed on regulators who likely lack any ability to assess the validity of such requirements, rubber stamp the checklists into regulations, and now you have a series of unenforceable or ridiculous security policies and practices that basically serve to frustrate the user while failing to prevent actual attacks.
I've been at companies where there were rather interesting policies like
- Three factor authentication (because a single method isn't enough for some reason)
- No password managers allowed (how this is enforced is completely unknown)
- 6 week password lifetime
- 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)
- Random character requirements/limitations (you must use non-letter characters from set X, but not from set Y, and absolutely only latin letters)
And those are just some of the bangers surrounding password policies; the less said about the network security policies and antivirus policies the better.
And these requirements don't come from some regulation/risk assessment group; they're enforced by such groups, but the actual requirements come from some security firm that sell lists and a stamp of approval once you have every box checked.
It's difficult to not look at such firms as swindlers with a guaranteed paycheck from a captive audience; they sell their services to regulators as a benchmark to meet, and then in turn they sell implementation services to companies that are forced to meet said regulations.
And the end result is just extremely frustrated users who still end up falling for "Hey Bob check this out" phishing emails which is plenty for an attacker to get in and jump around your network until they compromise enough of the environment to take the business down. But hey! The business followed the checklist, so they can't be held liable for exfiltrated data!
Earlier quoted context omitted.
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
I have had trouble convincing people before, would you happen to have a link ?
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, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
In 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…
Earlier quoted context omitted.
i agree. but most sites that enforce a policy (8 chars, symbols, etc) are bruted just as easily. we need to take a step, away from passwords, to secure against brute force in 2022
well the gp's point is that it literally is not 'just as easy' because the space of possible passwords increases greatly with each character, such that 'dog' is much, much easier to bruteforce than 'doggie12'.
My 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
would be a nicer UX if instead of "sorry" it was "great, your password hasn't changed as this was your old password. ps. you're now logged in, go do whatever you were hoping to do you rascal!"
Earlier 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…
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 you should allow users to “paste” passwords and potential passwords should be checked against a list of known bad ones.
My 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
would be a nicer UX if instead of "sorry" it was "great, your password hasn't changed as this was your old password. ps. you're now logged in, go do whatever you were hoping to do you rascal!"
Earlier quoted context omitted.
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
I have had trouble convincing people before, would you happen to have a link ?
> 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). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.