Off-topic but not sure having a patronizing cookie banner is the best strategy.
Cookies and banner have been removed!
Password Requirements: Myths and Madness
251–257 of 257 posts
Re: Password Requirements: Myths and Madness
#252Earlier quoted context omitted.
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.
My company (5b a year annual revenue so not small) stops you from changing your password within 2 days of changing it previously to stop that. Even the head of information security tried changing this and failed to get the change through.
That's the point where people simply append the month number.
Re: Password Requirements: Myths and Madness
#253Earlier quoted context omitted.
yep, all true... this is a solved problem on how to do it right. The fact that the OP finds this interaction funny leads me to believe they don't understand how it can be done correctly, which is scary.
The point isn't that this is not secure. It's just that it isn't more secure, when it prevents setting the current, active password. An attacker could already just log in with that password.
Exactly!
Re: Password Requirements: Myths and Madness
#254Earlier 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 was able to vastly simplify password requirements in a medium sized US company after appealing to the NIST standard.
[dead]
Re: Password Requirements: Myths and Madness
#255Earlier quoted context omitted.
> There is no way to tell if a password is strong since it may be reused. Very good point. From that perspective any reported strength can be extremely misleading. As far as bits go, this is where I get a bit lost. Calculating the number of bits only makes sense if the attacker knows what your character set is. Otherwise they will need to iterate over the full set of characters. So a 20 character password of Xs and Y…
A random 20 character password in base 72 is equivalent to a 124 character password in base 2. They have the same amount of security: 124 bits. https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLM... If a service didn't want to store 124 _bytes_ in a database to represent the above base 2 password, it can use a hashing algorithm to like SHA256 to reduce the storage requirements to 32 bytes. The password still…
Yes, I know that strength is measured in entropy. The question is what the benchmark for a “strong” password is.
Re: Password Requirements: Myths and Madness
#256I lead Security in a quite large bank. I love this article, I’ve been advocating for this line of thoughts for more time that I can remember. I have spoken to regulators hundreds of times, over this and a bunch other security topics that are definitely obsolete. Security policies that just don’t make sense… The most important thing for this kind of things to advance is to have the correct people in the correct places…
> I lead Security in a quite large bank. In most of my banks in Europe, all but one, I cannot log without using an actual physical 2FA device the bank sent me. One of them, Deutsche Bank, sent me a specific hardware 2FA which works "by itself" (and is protected by a PIN). No password to log in: only the user account ID and that 2FA device. The others require my Java SmartCard / national ID card to be inserted in a 2F…
Not anymore, we used to do that and maybe a bunch of customers still have that device to log in, but we have been replacing them (the “hard token”) with a “soft token”, kind of a Google Authenticator linked to your mobile.
It is interesting how “yubi”things have moved in the opposite direction (back to the physical device) and it has its value, after all, leaving your home with all your savings in your pocket is a risk we need to address.
Re: Password Requirements: Myths and Madness
#257In 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.
Why are special characters bad practice? Wouldn't they increase the entropy better than numbers?