Password expiration is dead, long live passwords • Hacker News Board

Re: Password expiration is dead, long live passwords

#161

Post by mormegil » Mon, Jun 03, 2019, 5:30 AM UTC

caymanjim wrote: post #126

It's going to take literally an entire human generation or more for the terrible password rules of the 2000s to disappear. Forced password changes and the myriad irrational rules about acceptable password contents have been drilled into the heads of every sysadmin and security engineer for the past two decades. They were never evidence-based rules, they were just learned behaviors.

If only the heads of security people... It's right there in the law: "[...] the tool for user identity verification [...] must enforce rules for [...] regular password change in the interval of at most 18 months [...]" §19(5)f of the Decree No. 82/2018, the Cybersecurity Decree (the Czech Republic).

(The good thing is this is only an interim requirement until a proper two-factor system is implemented, as required.)

Re: Password expiration is dead, long live passwords

#162

Post by kavi87 » Mon, Jun 03, 2019, 5:39 AM UTC

malaysanghi wrote: post #159

lysp wrote: post #146

Earlier quoted context omitted.

The problem with having a short expiration is that it forces people to simply use their password with a count: password1, password2, ... password23, password24. This means that if you discover someone's current password, you also have their future 10+ passwords as well.

I would think anyone enforcing password expiration would make sure the password is sufficiently (subjective) different from current password. This should be simple to enforce by asking for current password when you are asking for new password. You can perform a text match before computing whatever hash you need to store.

You'll need to store passwords in clear for this, not a good idea.

Re: Password expiration is dead, long live passwords

#163

Post by mypalmike » Mon, Jun 03, 2019, 5:39 AM UTC

loup-vaillant wrote: post #46

Raistael wrote: post #10

Earlier quoted context omitted.

I prefer these methods as well, but password simplification is a user choice, not a causal effect. Any secure password generator and vault, keyfobs and various other methods are great ways to compensate for a password that expires every so often. While I'm not entirely in line with the idea of "forced" password expiration, it's often the only way to ensure that the end user actually updates their password regularly.…

> password simplification is a user choice, not a causal effect The two are not mutually exclusive. If you require users to change passwords regularly, and also make sure the new password is sufficiently different from the last one (like, most characters must be different or something), guess what the users are likely to choose of their own so called free will. And I'm not even speaking of how you must store a passwo…

> Also good luck trying to defeat my strategy (or similar strategies) without storing more than a hash of the password

Enter Old Password: Complicatedpassword1

Enter New Password: Complicatedpassword2

Sorry, your new password is too similar to your old password.

(Passwords are still stored and verified using hashing, but with a form like this, your most recent and new passwords are available in plaintext for comparison when you make the change.)

Re: Password expiration is dead, long live passwords

#164

Post by kavi87 » Mon, Jun 03, 2019, 5:44 AM UTC

malaysanghi wrote: post #159

lysp wrote: post #146

Earlier quoted context omitted.

The problem with having a short expiration is that it forces people to simply use their password with a count: password1, password2, ... password23, password24. This means that if you discover someone's current password, you also have their future 10+ passwords as well.

I would think anyone enforcing password expiration would make sure the password is sufficiently (subjective) different from current password. This should be simple to enforce by asking for current password when you are asking for new password. You can perform a text match before computing whatever hash you need to store.

I misread you, it's fine for the current password. But they can alternate between two.

Re: Password expiration is dead, long live passwords

#165

Post by louis-paul » Mon, Jun 03, 2019, 5:57 AM UTC

These “baseline rules” come from NIST SP 800-63B, Appendix A, which is a surprisingly digestible document: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

Re: Password expiration is dead, long live passwords

#166

Post by stephenr » Mon, Jun 03, 2019, 6:10 AM UTC

tomglynch wrote: post #84

LeoPanthera wrote: post #23

Earlier quoted context omitted.

What I do: 1. Check the password against the haveibeenpwned.com database. 2. Check the password with the zxcvbn password strength library. If it passes both they can use it. It's not perfect, but it's a lot better than nothing.

I don't think checking against haveibeenpwned is a good idea. They recommend against checking your current password, and you're automatically checking every users current password?

I don't think the comment you replied to was referring to checking a "current" password.

It's about checking a "new" password when an account is created, or the password changed.

Having said that - I don't see any issue with checking current passwords when the user logs in - you don't send the password to the remote service, so it can't leak that way.

Re: Password expiration is dead, long live passwords

#167

Post by aitchnyu » Mon, Jun 03, 2019, 6:11 AM UTC

idle_zealot wrote: post #135

x3ro wrote: post #124

Earlier quoted context omitted.

Can you explain why this is better than changing the configuration?

Presumably because the config option disables all access to paste events and this access is sometimes desirable.

I had to disable that extension for Facebook and MS teams or weird state happens. I would paste text, undo it all and still have text left over.

Re: Password expiration is dead, long live passwords

#168

Post by ht85 » Mon, Jun 03, 2019, 6:13 AM UTC

kavi87 wrote: post #162

malaysanghi wrote: post #159

Earlier quoted context omitted.

I would think anyone enforcing password expiration would make sure the password is sufficiently (subjective) different from current password. This should be simple to enforce by asking for current password when you are asking for new password. You can perform a text match before computing whatever hash you need to store.

You'll need to store passwords in clear for this, not a good idea.

Not necessarily, you can have the user input the old password when setting up the new one, check it against the old hash and if it matches, do whatever comparisons you need between old and new.

Re: Password expiration is dead, long live passwords

#169

Post by setzer22 » Mon, Jun 03, 2019, 6:14 AM UTC

reaperducer wrote: post #148

Aeolun wrote: post #143

Earlier quoted context omitted.

Also not helped by the fact that passwords have to include every symbol and their mother, cannot include sequential digits, cannot include sequential letters, cannot include any letter of your name, and a bunch of other inane rules that could be changed to simply having a minimum length of 12 instead of 8...

A couple of years ago one of my banks "upgraded" its web site, forcing me to change my password to comply with its revised password guidelines since my old password was no longer permitted. The result was a password that was shorter, less varied, and less secure than the previous one. Good job, Chase.

> my old password was no longer permitted.

But how did they know? They should just have the hash...

Re: Password expiration is dead, long live passwords

#170

Post by delusional » Mon, Jun 03, 2019, 6:14 AM UTC

erichurkman wrote: post #99

tty2300 wrote: post #45

Earlier quoted context omitted.

Which isn't even that bad of an idea. Some website basically use this as the only way to log in.

Slack does this exceptionally well. If you forget which accounts you have, you can put in an email address and it will email you a list of your Slack accounts. If you forget your password, you can get a magic link that automatically signs in through a deep link into the app, no password needed.

It's such a cool idea. If you can reset your password using only your email, there's no security reason you can't just log in with it. It might even be better, since you can then add more annoying steps to the password reset strategy.