Live data from Hacker News

Password expiration is dead, long live passwords

techcrunch.com

121–130 of 316 posts

Re: Password expiration is dead, long live passwords

#121

Earlier quoted context omitted.

And spend time training them on using it? I really wish it was a thing but people looked at me like I was an alien when I mentioned it... (I work for a Microsoft subsidiary. I also hope they adopt the new rules, I hate changing passwords every 90 days.)

I don't think it's actually possible to both (A) use unique passwords and (B) not use a password manager. If you can't provide one, don't expect the other.

In practice I'd stake money on it, even taking into account the tech-savvy users who would otherwise use password managers but are forced to log in manually every time they step away from their computer for five minutes (I'm pretty sure it is intentionally impossible that you can't use a password manager on the Windows login form, for example).

Re: Password expiration is dead, long live passwords

#123
post #36

Earlier quoted context omitted.

Unfortunately we still have to have similar authentication methods for other password resets. Users have an alarming tendency to forget their passwords after a week or two of holiday.

Some never memorize their passwords at all. Instead relying on 'forgot' emails and "Remember Me" features entirely.

It is one way to go "passwordless" .. though you're piggy backing on the security that your email system already has.

Shameless plug of old post that describes how to restrict login to only the initiator even if login is initiated via an email link - http://sriku.org/blog/2017/04/29/forget-password/

Re: Password expiration is dead, long live passwords

#124
post #39

Earlier quoted context omitted.

> and of course they also disable pasting for added security. With Firefox, you can set this about:config setting to false to give you back the ability to paste, even when sites try to block it: dom.event.clipboardevents.enabled

There's an extension called Don't Fuck With Paste, which is a better solution.

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

Re: Password expiration is dead, long live passwords

#125
post #53

"Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem." Full post: https://blogs.…

> If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen We've been seeing the point "your personal information is already out there, in the hands of hackers" recently. This cleft seems oddly blind to the possibility that a password has been stolen, but you have no evidence of the fact.

This doesn't do a very good job of explaining the actual threat modelling that goes into this policy. Password rotation helps to minimize the impact of passwords that are compromised in two scenarios:

1. If the passwords are stored improperly by the service provider.

2. If the passwords are stored properly, but are weak and easy to compromise from a hash.

The idea is that both of those problems can be better solved in other ways. Number 1 is better solved by doing some due diligence with your service providers. Number 2 is better solved by using strong passwords, where it wouldn't matter if the hashes are compromised. Number 2 comes down to encouraging better password behaviour among your users. Not enforcing password rotation is seen as a way of encouraging better password behaviour by removing onerous requirements that do not actually contribute to the desired outcomes (using stronger passwords).

In addition to that, it's believed that the theoretical trade off between the two approaches is minimised by focusing more attention onto proactive monitoring.

The reasoning is based on looking at opportunity cost, and the idea that users are more likely to comply with easier to follow policies. There are better areas of security for administrators to be focusing their attention on, and you're more likely to have a positive impact on peoples behaviour the less you inconvenience them (or ideally, your policies would actually increase convenience for them).

Re: Password expiration is dead, long live passwords

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

Re: Password expiration is dead, long live passwords

#127

Earlier quoted context omitted.

I used to also, until this blew up in my face. Put random stuff as the security answers in my Trial World of Warcraft account in 2005. In order to merge it into my Battle.net 2.0 account around 2009 I needed to know it, and even though I had the correct password there was no way to change security questions and I had to beg customer support (which was a long process, involving software serial numbers, scans of ID, th…

I assume when people suggest putting random strings in these fields, it's implied that you're supposed to save that data in a password manager or something. Mine (KeePassXC) supports storing arbitrary data as "notes" in each entry, along with TOTP information (great as a backup in case you lose your phone), and other stuff. I worry more that a particularly dull customer support agent is likely to be convinced by a ra…

Use randomly generated words. A CSR might be convinced by "idk I just put random words in there LOL" when the security question answer is uaisehf8wefjh0824m, but if they see "correct-horse-battery-staple" as the answer, it might be a bit harder to convince.

Re: Password expiration is dead, long live passwords

#128
post #114

Earlier quoted context omitted.

This ignores the fact that most people use the same password everywhere, given the opportunity, and you have no idea what website has been breached. I.e. if you don't expire passwords, most people will use the same password everywhere, and you don't know when a compromise has happened, because it happened on some totally other network.

This doesn't need to be solved via time-based expiry though - you can use a breach list (like checking https://haveibeenpwned.com on registration,login, and password change). Even an aggressive password change policy is typically one month since last change, which would give a long window for access. Secondary factors, if at no other time then on first use of a machine, are also a good technique to prevent password b…

[deleted]

Re: Password expiration is dead, long live passwords

#129

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?

The check is done locally against a hash. There's no risk of leaking the password.

Re: Password expiration is dead, long live passwords

#130

Recent, frustrating example: My (business) bank uses FISERV software, and their software expires passwords every 90 days. Their software can notify you about a million combinations of account activities and statuses, except this one. It takes 3 values to login to the account (company ID, username, password). When logging in via mobile app, it never tells you that your password has expired, so I end up trying a few ti…

I've run into this a lot in other software as well.
Post reply on HN