Live data from Hacker News

Password expiration is dead, long live passwords

techcrunch.com

291–300 of 316 posts

Re: Password expiration is dead, long live passwords

#291

Shifting from passwords to more secure systems such as MFA ignores the elephant in the room about passwords that no-one wants to acknowledge: People share passwords. A simple example is this: A couple do online grocery shopping every week or so, depending who has time to do it, one them will log into the 'account' and build the basket. Maybe the other will then amend the basket a few hours later before the cut off ti…

late to game, but ideas...

1. One time Password ?

2. Change password before/after authenticating their device

3. Improve communication with spouse regarding milk eggs crap wrap etc.?

Re: Password expiration is dead, long live passwords

#292
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.

It's just too difficult to memorize a completely new, randomly generated password every 90 days. People will have to write them down, and then there's a whole new way for them to be compromised.

Re: Password expiration is dead, long live passwords

#293
post #273

Earlier quoted context omitted.

I thought Yubikeys and other hardware keys were best practice?

They might be a preference but I don’t see how they can be best practice when they’re barely supported on a lot of platforms - Firefox has some support (but doesn’t work with, for example, Github), no/limited support in Safari, no/limited support in mobile devices.

WebAuthn (previously U2F) is just now gaining that support and momentum, with support both in Firefox and Android

Re: Password expiration is dead, long live passwords

#294

The article recommends LastPass but ironically LastPass still asks you to change the master passphrase every 180 days. I've complained about this a long time ago and they didn't seem to take my request seriously despite my sending them links to the NIST recommendations.

I second @traydee — this has never happened to me either. Do you turn on the option to have the app remember your master password? If so, maybe that's why they ask you to change it; don't use that option.

Re: Password expiration is dead, long live passwords

#295

Earlier quoted context omitted.

How did this idea of expiring passwords arise in the first place? Misguided intuition or did the infosec people back then just get it wrong?

It's existed in some form since at least the 1990s, likely through institutional or government practice. A (possible) example from a 1997 Sybase manual: https://books.google.com/books?id=GzGuPO5fKOEC&q="password+e... I just checked Simpson & Garfinkel's PUIS, which does mention forced changes, but not scheduled expiry. Also 1997. (Google Book Search is badly polluted by mis-dated publications: http://www.google.com/s…

The man's name is Simson Garfinkel — no "p" and no "&". (Your brain is probably confusing him with Simon & Garfunkel.)

Re: Password expiration is dead, long live passwords

#296

Earlier quoted context omitted.

I'm sure they are, but I think predictability is slightly less bad than being distributed across every single service they've ever used. There's only so much I can do about people not giving a crap.

Testing against known password lists is a huge win.

Yes, this is the right answer. See https://haveibeenpwned.com/Passwords

Re: Password expiration is dead, long live passwords

#297

Earlier quoted context omitted.

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?

You can download a database from haveibeenpwned of SHA-1s of all the passwords, which is the only way you should be checking user passwords against an external database. It's also a good way!

Downloading the database is best, but you can also safely use their range API [1]. This can be run either client-side or server-side.

I built a toy webpage using the API [2], and you can see how straightforward the API is to use by checking the script [3].

[1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...

[2] https://safepasswordchecker.hashbase.io/

[3] https://safepasswordchecker.hashbase.io/script.js

Re: Password expiration is dead, long live passwords

#298
post #225

Earlier quoted context omitted.

Strings of everyday words are better than the passwords most people choose, they're memorable, and they're often good enough from a practical perspective. But if you're using a password manager and don't have to remember passwords, you might as well use truly random passwords, which have more entropy.

> [...] you might as well use truly random passwords, which have more entropy. At what point is more entropy simply diminishing returns? Five random words gives you 64 bits, and six gives you 77 bits (each word = 12.9 bites): * https://en.wikipedia.org/wiki/Diceware * https://www.rempe.us/diceware/#eff

The primary benefit of Diceware over a "random" string of characters is that it is easy to remember and truly random. With a password manager you don't need to remember the password and it will be generated truly randomly. A string of 11 random alphanumeric charatcers has more entropy than a 5 word diceware passphrase with the added benefit that it is less to type if you need to do so manually. But diceware can be a good idea for creating the master password for your password manager and if you do that you should probably use a 10 word passphrase rather than 5.

Re: Password expiration is dead, long live passwords

#299

Earlier quoted context omitted.

It's existed in some form since at least the 1990s, likely through institutional or government practice. A (possible) example from a 1997 Sybase manual: https://books.google.com/books?id=GzGuPO5fKOEC&q="password+e... I just checked Simpson & Garfinkel's PUIS, which does mention forced changes, but not scheduled expiry. Also 1997. (Google Book Search is badly polluted by mis-dated publications: http://www.google.com/s…

The man's name is Simson Garfinkel — no "p" and no "&". (Your brain is probably confusing him with Simon & Garfunkel.)

Spafford and Garfinkel was what I'd meant to write.

Unreliable tablet input compounding even less reliable short-term working memory.

http://shop.oreilly.com/product/9781565921481.do

Re: Password expiration is dead, long live passwords

#300

Shifting from passwords to more secure systems such as MFA ignores the elephant in the room about passwords that no-one wants to acknowledge: People share passwords. A simple example is this: A couple do online grocery shopping every week or so, depending who has time to do it, one them will log into the 'account' and build the basket. Maybe the other will then amend the basket a few hours later before the cut off ti…

That still doesn't mean forcing frequent password changes becomes better... Usually it means COMPLEXPPASS!### where ### is incremented through each refresh, until you can reuse 1 again.

What would be better is forcing a passphrase change when a user on an account leaves.

This does not negate other security practices... however, frequent changes leads to less security, not more, generally speaking.

Post reply on HN