Earlier quoted context omitted.
Go ahead and suggest an alternative
One-time use magic links sent to a verified email.
You just Chicken and Egged your email login.
There’s no need to change passwords if they're robust, unique and not breached
231–240 of 288 posts
Re: There’s no need to change passwords if they're robust, unique and not breached
#232I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried. Key material rotation seems to be a sensible practice in general.
With a ratelimit of 60 attempts per minute (which is significantly higher than any user would legitimately ever need) you're looking at thousands of years to bruteforce a random 6 character alphanumeric password.
The problem is that ratelimiting doesn't work when your password database is leaked. Brute force attacks on the front end system basically don't happen because rate limiting is everywhere. They'll try a handful of default passwords and move on.
Re: There’s no need to change passwords if they're robust, unique and not breached
#233> There’s no need to change passwords if they're robust, unique and not breached This assumes you'll know if passwords were exposed in a breach. Some breaches go undetected.
This also assumes that changing the password would effectively lock out attackers that have already breached your systems.
Re: There’s no need to change passwords if they're robust, unique and not breached
#234Earlier quoted context omitted.
Working at a acquisition of a big consulting corporation. Had these recommendations in place before being acquired. We're onboarded onto better security systems by new mothership. Password rotation every 75 days. No dictionary check. No check against known breached passwords. No real reasonable rules against insecure passwords (like ac_Paul2022 is valid 'secure' password). Additional massive "spyware" on corporate de…
I worked at a small consultancy. We started without password rotation requirements, because it's more secure. We had to add them, because our clients' legal teams started requiring that their contracts with vendors mandate industry-standard security practices. Your employer was probably in a similar situation: certain practices are mandated by customer contracts, not actual security assessments. It takes a long time…
Second that, we get some corporate checklist from the customer and they want it green.
Explaining that it is not industry standard anymore takes time and if they want to take time of their employees using our system to deal with that, I am not wasting our company time to make them right.
Re: There’s no need to change passwords if they're robust, unique and not breached
#235I am in the camp of requiring people to have strong passwords, and not requiring them to be changed - ever. When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems. My oldest online account - btw it is a brokerage account at one of the big brokerage houses, where a great deal of my cash and investments sit - has not asked me to change the…
I worked on a crypto-related project where we ended up just generating a strong password on the client during registration. Credential stuffing attacks are just too effective.
Nobody complained. I think it's a better solution than making the user come up with their own strong password with annoying special character rules when you can just generate one for them.
The interesting challenge was making it work well with all password managers though which often have mind-numbingly dumb heuristics about what could possibly be a password field. It's worth a blog post.
Re: There’s no need to change passwords if they're robust, unique and not breached
#236I feel like this post was intended to inflame or shock the reader with the writers stance on password policy. But anyone who has been in security for more than 1 month knows that regular password rotation has not been a recommendation for over 5 years. Both NIST, and MS have been trying to get the world to move to long, never rotated password, so long as those passwords are dictionary checked. Every company (all 3 of…
Special characters are OK.. The casual layperson knows how to make a special character a separator.
Nope, special character for casual layperson is ! at the end of the password and when they have to change password they just make it !!
Re: There’s no need to change passwords if they're robust, unique and not breached
#237While it is certainly correct to never enforce changing a password, I would argue that it is totally okay to expire it in certain scenarios.
When my company set up the Active Directory f.e. we put a LSA password filter[0] in place that checks against HIBP. The password policy was set to expire every 90 days, atleast 15 characters and dont enforce a history. The non existent history was clearly communicated and users are encouraged to just enter their existing password three times when it expires. That way there is only one place where the passwords are checked for leaks and they are already there in plain, so it is manageable and doesn't add that much attack surface.
[0]: Something like https://github.com/fblz/PassFilter or https://github.com/rlabolle/hibppwdflt
Re: There’s no need to change passwords if they're robust, unique and not breached
#238Earlier quoted context omitted.
I am very curious why public private key auth is not a thing for websites and applications. I would rather have a single password to the server that publicly hosts my public key then I can simply point websites and applications to that address during signup. Every app/site would check the server every 5-20 mins for changes to my public key in case I need to change it. Then I can use my private key to authenticate to…
You sit down at a public machine with no accessible ports. I hope you memorized your public key so you can type it in.
It's probably a bad idea to authenticate on a public machine to begin with. How can you possibly know what that machine might do with your account once you log in?
But let's say you want to do it anyway. There is no need to memorize or type the entire key; a site-specific private/public keypair can be derived from a memorized master password and the domain name (for uniqueness) via a KDF. The site never needs to see the master password, so in the event of a breach all your other logins remain secure, and there are no key files to synchronize, just a single password for access to all your accounts.
You do need to trust that the PC you're using to log in is secure, though, since it has access to the master password; I'm not sure how you would get around that without involving some other trusted piece of hardware, and if you have that you could just use it to access the site instead.
Re: There’s no need to change passwords if they're robust, unique and not breached
#239Even NIST has stopped recommending password rotation, so it’s irksome that there are still organisations that require it.
Re: There’s no need to change passwords if they're robust, unique and not breached
#240Assuming a single character has something in the order of 100 possible values (I.e. a US English keyboard, no Unicode etc.) then a 12 character random password would take about 11.5 days to crack if you had a billion machines that could each crack a billion passwords a second.
Assuming NTLM hashes you can currently crack almost 100 billion hashes per second on a single AWS p3.16xlarge that costs $25/hour to run (https://www.thesecurityfactory.be/password-cracking-speed/)
I.e. you’d need 10 million hours of these machines to try every combination possible, with an average time to crack of 5 million hours. I.e. a total cost of $125 million, although I bet you could negotiate a pretty good AWS discount and/ or build the servers yourself and optimize them for cracking, so let’s call it around $50 million to crack a truly random 12-ASCII character password today.
Assuming Moore’s law improvements and improvements in energy costs/ efficiency and we can reasonably assume this cost could roughly halve every 18 months, to under $1 million in a decade. That’s not a lot of money to a nation state actor, so if you’re in a position where you seriously worry about active attacks against you specifically, perhaps using passwords that are longer than 12 characters is worthwhile.