Password expiration is dead, long live passwords
techcrunch.com
techcrunch.com
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 time. With enforced MFA, this is not possible.
There will always be a small percentage of situations where '1 person = 1 account' will never be true. Until providers add the concept of multi-logins to the same 'account' on their systems you can't wholesale move to stronger security methods.
I have the same issue with all these 'smart home' products that need an app installed onto a phone or tablet. A lot of them are bound to a single account, which means if other people in the household also want to have the app, you have to share your account details. if it's a Google or Amazon product, that means you are sharing account details of an account that you really shouldn't be.
To me, TOTP means 'Top Of The Pops', I had to Google your acronym! How is Grandma Alice going to be able to manage these extra steps? - It's already taken over 20 years to convince people that 'Password1' is not a good password.
“Scan this barcode then enter the six digit number from the app; we’ll sometimes ask for the number when you log in” isn’t particularly onerous - 1Password for example will insert your one time pass along with your password so in some cases there isn’t even an extra step to log in. I’d be more worried about people losing/wiping phones and getting locked out of their logins - who needs those backup codes, right?
After 1Password introduced MFA (TOTP) support, it has been used widely in organizations in shared vaults so multiple people can share critical logins that use MFA. This of course means that if your 1Password account is compromised it's game over.
If someone gets your vault password and can unlock your phone, you’re toast, but SMS as a second factor is then also compromised so what usable (since this thread started as trying to sell MFA to lay people) options do you have (other than maybe a Yubikey)?
1: https://caniuse.com/#feat=webauthn 2: https://caniuse.com/#feat=u2f
But the correct pattern is a formal system for delegation and/or disconnecting 'login' with 'account' (i.e. separate charging for a service from the login). This is something that AWS does very well for example.
There are so many interesting legal questions about digital assets that we're all afraid to ask, but probably should be solving today (if not yesterday).
So I register with my phone number, I get an OTP (via SMS) and login into the system to add stuff to my basket, etc. My wife also logs in from her phone, but rather than registering afresh, uses my phone number. Now I get another OTP which she uses to login from her phone. That's it. Same account is logged into on two different phones and the login persists.
I don't know if this is by accident or design, but it works. Hopefully it'll continue to work, and they don't try to "fix" it because it wasn't meant to be that way...
It's completely insane, and the closest they've gotten to adding anything like this is letting people have comment moderators on live streams, not videos where people have wanted comment moderators from day one, just live streams.
I agree, but this isn't an argument against the obsolence of expiring passwords regularly.
I imagine people sharing passwords are even MORE likely to share passwords in insecure ways if they are forced to change the shared password at a regular interval.
In real life, people share keys too. So in some cases the "key" should probably be the metaphor, and it could be implemented by a dongle.
Unfortunately, some very popular 2FA keygen apps can't handle multiple device linked to a single account. I have a well-known service provider that uses a well-known company's app for 2FA. Unfortunately, this app has to be reset to a new device code on changing of the phone's sim card. I wanted to set up two sim cards so I could switch between them for a trip overseas but this is not supported and my service provider does not support other 2FA such as Google or MSFT's app which are not tied to the sim card.
1. One time Password ?
2. Change password before/after authenticating their device
3. Improve communication with spouse regarding milk eggs crap wrap etc.?
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.
When I opened a new joint bank account with my wife, the branch manager was helping set us up for online access. I asked about having our individual logins linked to the joint account. He said they couldn't do that, and we had to share the login for the joint account. I pointed out their TOS had just forbidden us to ever do that. He agreed it was stupid, but they had no other option available.
Good riddance to password expiration.
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/
You go to the login page, and your choices are federated login, standard login, or a one-time login e-mail.
You can only login with reset emails or SMS codes, which is pretty annoying.
Assume it was due to the inconvenience of not being able to remember password/stay signed in.
Oh, it has a password. But if I remember my password I have to check my email and copy and paste a code from there. And if I forget my password I have to... check my email and copy and paste a code from there... really not much point to the password.
The result was a password that was shorter, less varied, and less secure than the previous one.
Good job, Chase.
But how did they know? They should just have the hash...
So they can just determine the password's strength at the time when the user is logging in
http://browserengine.net/dont-fuck-with-paste-for-chrome-and...
https://play.google.com/store/apps/details?id=keepass2androi...
It has a keyboard bundled into it that will ghost type in the currently opened username and password. Works awesome for stupid stuff like your story.
Since the responsibility for password storage is on the customer anyway, we might as well make our password a maximum of 6 characters!
694*C73&4:Ekp>fy>SE&o![RC
(This is an example of what password-store generates.)Not good enough, because it's too long. Nothing throws you back ten years in time like having to handcraft a password to comply with all the silly rules.
Every single time I want to login, I have to do a password reset first. Makes me which I had the phone number to every manager in the company, so I could lock them all out every day.
Also, since having the phone is the only second factor for authentication, that's all you need to access an account.
I wonder why I never pursued that.
> random array of everyday words
No, that's not how entropy works. Random characters still score better.
You might be referring to https://xkcd.com/936/
There are a couple of situations where having these symbol strings is really inconvenient. For instance, reading a password out loud to another person, or when logging in on a device where you can't (or don't want to) install your password manager on (e.g. a PS4 or an Apple TV). In those cases, "puncture-foible-irish-ducat-rejoice" is a lot easier to handle than "jh&6dQ#F]9.Z>u^t]6u+".
The "symbol" password has more entropy for sure, but the actual security benefit is essentially non-existent. No one's going to guess either password, and I'm never using the same password in two different places anyway. The extra convenience is totally worth it.
EDIT: as other people have pointed out in the thread, another example would be badly behaving sites that prevent "paste" or use other techniques to block password managers. Much easier to type in those words then.
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
* https://en.wikipedia.org/wiki/Password_strength#Random_passw...
Full post: https://blogs.technet.microsoft.com/secguide/2019/05/23/secu...
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.
In your method, you have access to all or none, for some days.
Staggered seems preferable.
Note that I’m only arguing your reasoning, not the broader point of password expiration
Hackers with access to 100 million accounts generally can use any of them, but not all of them. So, in practice access to 1% or 100% of all accounts may be equally damaging.
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).
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 breaches from spreading into your system.
Login via web browser, and sure enough it'll tell me my password expired and it's time to change it. They also occasionally enforce 2FA. Passwords are also how you connect things like Quickbooks.
When I called the bank to find out how to get notifications that a password has expired, they said there was no way. "When you change your password, set a calendar event for 60 days ahead..." they told me.
password1, password2, ... password23, password24.
This means that if you discover someone's current password, you also have their future 10+ passwords as well.
I’m not saying whether this is a good idea or not. I haven’t thought through it.
This was the middle east, and yes they refused to use password manager programs because they didn't understand them
Why am I mentioning this? Well, if you are an army leader, and you know that your soldiers in general have an IQ score of around 82; would you let them make their own decisions on the ground? How about if your soldiers were known for having almost 115?
Yeah, sure, how you decide to make your next password may of course be down to culture, and the decision to have a password manager is perhaps too. However at some point a password manager should be a requirement for even signing up to your service, much less becoming an employee, especially if you already know about the prevalent culture.
Not having it would be better, but that would be insubordination.
I get your point... but having an expiry that can't generate a notification is really bizarre. And having done enterprise financial software in a previous life (company was actually sold to FISERV, though I never went over), if our customers had been subjected to these conditions, it would have been a massive challenge.
This is a very good reason to change bank. That unacceptable answer would certainly induce me to rage quit the service, whatever the inconvenience.
FISERV is a dominant player in this space. Either this situation is a matter of configuration/settings, or a limitation of their software.
I have no idea that a different bank would have better systems, and it's a Really Big Deal to move business banking.
It's dangerous as having password stored in plain text as answers to the security questions can potentially unlock many other accounts.
I highly suggest everyone answers each of them with a unique answer.
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, the whole works).
Ultimately they told me what my mother's maiden name was: qewqewdfskjr3924kjasdf
I worry more that a particularly dull customer support agent is likely to be convinced by a random caller to reset the password if they can see that those fields are garbage.
Don’t just mash the keyboard or use random strings, as customer support will regularly accept “I don’t remember, I just put random stuff”. Make it believable but wrong.
Scammer: "I just entered a bunch of garbage."
Customer Rep.: "Yup! Thanks for verifying that Mr. Smith!"
After draining both accounts online I then called up to close them, the first question was "Who is your favorite superhero?" I blanked, no idea, I set these accounts up like 2 years ago.
No problem they just set me up some new "security" questions after confirming my name/address/dob.
Suffice to say I'm glad they're not holding any of my money now.
(The good thing is this is only an interim requirement until a proper two-factor system is implemented, as required.)
* Most are easy to remember (most of us don't use LastPass etc)
* They authenticate the user but not the service!
* They're leaky (the system tells you when you have the wrong one, facilitating several kinds of attacks)
* People leave them lying around all the time
* Changing one almost always involves using the old one (instead of starting over from first principles)
Don't get me started on usernames! If you have a large hashed password, then the username becomes irrelevant (except as a way of leaking information).
Here's a modest proposal:
* Insist on large hashed passwords (256bit or better).
* Forget about usernames. The password becomes an 'account key' and is all you need
* Allow delegation: from one account to another; enable/disable features even for the 'main' account; give away authority for delegation at the feature level
* Never deny login for any reason, because that leaks security info (e.g. 'that password is illegal' is information). Just trust every legal password, and if it doesn't exist in the system then create a new default account
When talking about your account, then -- such as when talking to Support -- how would you refer to your account? Would you be assigned an ID by the system, which you then have to save or remember?
Not saying it's good or bad or anything, just want to understand the expected user experience.
We also have a local utility that sends you a 5 letter password upon account creation through email, and that's your password. If you try to change it, they'll send you another 5 letter one.
Some of these banks expire passwords every 6 months! That's insane. I have calendar reminders set to remind me to log in and generate another password with LastPass.
I have well over $250k net worth, the vast majority of our assets are in brokerage and retirement accounts. We have only $60k in cash.
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
Hopefully we have five years before competitors catch up to us and implement this cutting edge technology!
And that's assuming it expires when I'm in the office, whereas what seems to happen roughly half the time is it expires when I'm connected via the VPN.
Twice, support resolved the issue by resetting my password and telling me the new one... which is my last name plus 4 digits. Then I can live with a very insecure password for 90 days, or try the reset app roulette again.
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/search?q="password+expiration"&lr=lang... )
Ngram plot: https://books.google.com/ngrams/graph?content=password+expir...
Unreliable tablet input compounding even less reliable short-term working memory.
And that was just one of a dozen or two customers with varied policies requiring we turn over SSNs, carry SecurID tokens, install various soft tokens on our laptops, roll passwords every so often, go through various and sundry jump hosts, etc......
When forced to do this I will use something like "B@s3P@ssw0rd1" then "B@s3P@ssw0rd2", "B@s3P@ssw0rd3" etc.
Better to use a combo of several words such as... BatteryHorseStaple. :)
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'm using Active Directory and options for extra password checks are somewhat limited.
https://docs.microsoft.com/en-us/azure/active-directory/auth...
It lets you upload your own custom list of banned passwords but it's limited to 1000 words. My impression is that this is intended to blacklist common words and things like your company name.
I see that Troy Hunt is now working for Microsoft so perhaps there's something in the works related to this. It seems like linking this Azure AD service to the haveibeenpwned API would be pretty straightforward.
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...
So for: * Password: trustno1 * Hash: 1234567890abcdefghij
You send to the api:
* Hash: 12345
And it returns all hashes it knows of that start with 12345 along with a count of how many times each hashed password has been breached.
You then compare that list to see if your full hash exists in there.
If it exists - it's been breached. If not - you're clear.
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.
Turns out he's downloaded a hashed list and is checking against that. Which is fine.
If you're using Google Accounts then they have a feature for this[1]. It detects when they enter their Google password into any other site then reports it and makes them change their password. I'd love a similar feature that somehow worked with Active Directory.
[1] Password Alert: https://support.google.com/a/answer/6197480
It's not foolproof-perfect, but from personal experience it tends to work quickly and effectively. It requires "surveillance" of your browser/computer, but you should assume that with a work device anyways, and it can work with hashes and password fields so it's not storing your actual password or logging everything else you're doing.
Personally, I reuse a simple password for very non-important services and it's very convenient. I think that's ok, or at the very least I should be able to choose to.
I work on a web based SaaS used mainly by different parts of the government and we are often asked about password policies and rotation, to which we point at the nist & nscs advice
* Test for password strength (most reused passwords are weak)
* Test for password existence in public databases (and recheck on database updates when they log in)
* Automatically generate a secure password for your users at the account creation stage and require them to use it
* Use a login method more sophisticated than just username / password to mitigate against password reuse
* Expire the first password they enter instantaneously, but then never expire again.
* Set an exact length requirement of between 16 and 20 characters inclusive. (Don't actually do this, but it's better than password expiry.)
* If your users are also your employees, make them responsible if their password is compromised while training them in proper password use.
I don't know, it just seems to me like basically any solution, including doing nothing, is better than expiring passwords. Even if it forces a few people to not reuse a password and there were no other way to achieve the same result, the tradeoff of worse security that results would make it not worth it.
While we're on the topic of security guidelines, this one really ought to be mandatory for any organization that cares about security in the slightest. It immediately invalidates the overwhelming majority of the class of laughably-insecure passwords selected by users.
Maybe you can say that it mitigates it, but I don't think it avoids it at all.
The sum of the authentication credentials passed to the application is different for each site. with 2FA you submit password + token. so an attacker who is replaying compromised credentials can't gain unauthorised access with them alone.
Or just require 2FA for everything, but that’s hard to do with a lot of software.
I'd prefer 2FA and (allowing / encouraging) longer / stronger passwords over change policies.
It is fair to point out that the relevance of this is dependent on your attack model. If you suspect someone is trying to crack your password then just a longer password is fine. If you suspect a leak then you actually need to change/update password.
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 password to be able to tell that a new password is sufficiently different from all the old ones. (Hint: probably plaintext.)
> […] "forced" password expiration [is] often the only way to ensure that the end user actually updates their password regularly.
That does not work. I have defeated it in my last gig with this simple method:
Complicatedpassword1
Complicatedpassword2
Complicatedpassword3
Complicatedpassword4
Complicatedpassword5
And I will do it again, because a complex password that never changes is much more secure than random crap that I will have to simplify just so I can remember it. Also good luck trying to defeat my strategy (or similar strategies) without storing more than a hash of the password, properly generated with a memory hard function like Argon2.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.)
Complicatedpassword1
PasswordComplicated1
Complicatedpassword2
PasswordComplicated2
Complicatedpassword3
PasswordComplicated3
And if that fails, they win. Clearly they don't care about security, so I'll use a weaker password. And I will note it on a post-it and keep it in my wallet.It's certainly true that as technology improves and the mechanisms we build to secure things evolve new keys need to be used in order to stay up-to-date. But this amounts to secret rotation that aligns with evolving systems not arbitrary 90-day expiration policies. Much different argument.
Keys should not be rotated.. security strategies should.
Users who don't care will still choose bad passwords, this is why 2FA is important :)
Forced periodic password rotation was mainly security theatre. Most users just choose sequence passwords, so an attacker who gets one can easily work out the others.
If you then take counter-measures to stop obvious sequences, you're heading into seriously user-unfriendly password policies, which is the kind of thing that gives security a bad name.
Far better to make use of 2FA at that point.
Also NIST dropped password complexity requirements. The only hard requirement is it must be 8 characters or more. New guidelines is to let users choose their own level of complexity and encourage them to make longer passwords that they can actually remember.
We would like to follow NIST 800-53, but too many customers (like Microsoft) still do not allow for the 2016 NIST changes.
The internal time management software we use at work, which I only access every few weeks always forces me to set a new password. So every time I come to log on, my password has expired. What makes it worse is that this password is connected to other work services but they're not synchronised so when I change one, the other doesn't always change for a couple of days. Sometimes, the only way to log in to my machine is to disconnect the ethernet and make sure the wifi is off. And I have to keep a document on my phone with every variation of my passwords in the last few months and even then, if I am on holiday for a while and come back to work, none of them work.
I think there is a class of companies and services (Excluding Microsoft) who just need to leave the business of user security to the user and stop trying to build walls around an enclosure that no one cares about in the first place.
I once had an investment account lock out at the start of a weekend and I couldn’t log into the damn thing for days simply because their robot shut it off and only a working human would turn it on.
Password managers are claimed to be the solution but we just aren't seeing average users jumping on board - probably due to the added complexity.
So what's the solution? How about websites begin client side hashing as well as using SSL and hashing server side. Then every users 'password' becomes unique by having a specific salt per website. This would hugely improve the current scenario in that when a site is hacked, attackers can try every users details on a range of other sites gaining access due to password re-use.
Also I don't see the advantage over just server-side hashing. Client-side hashing (without a password manager) is public, so the salt the site uses is known.
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.
For example: If there is no client side hashing: a user uses the same password for n websites. If one of the n websites gets hacked, an attacker can login to all n sites.
If one on site you have client side hashing: a user uses the same password for n websites. If one of the n-1 websites gets hacked, an attacker can login to all n sites. If the client side hashed website is hacked, the attacker can only login to 1 site.
Once each site has a unique salt, then we're secure.
Another issue is how can a website migrate over to client side hashing? I don't think there's an elegant way to do this.
The other thing what I just read recently and mentioned in this article is about storing secrets in environment variables. That's not good either because every running code and subprocess can read it...
https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
Fun anecdote... I spent 6 months last year designing and implementing a 'Self-Service' password reset portal system and password synchronisation system for 50k+ users in a large organisation, only for the organisation in question to switch to non-expiring passwords 1 week before deployment.
Needless to say... usage of the system post deployment was almost non-existent.
Ah well, at least I still got paid.
They have a guy whose job is basically to deal with unlocks after password changes.
It's a nice reminder and the option is already pre-selected so you just have to click Save. I've gotten into the habit of doing this now even before configuring domains, users, etc.
The next logical step of course is to enable/enforce MFA for all users as a thorough auth policy.
I must admit I never really understood the function of it. Obviously lifetime access is more damaging than 3 months access, but the truly devastating thing is the unauthorised access itself not the length of it. Also the policy results in really bad practices like people using summer2019 as their password or writing their current password down on post it’s. We tried blocking stuff like summer2019, but people get really creative. People also forget to renew their passwords, costing hundred of hours in the process.
We have 2FA now, which will soon be required by our adoption of the GDPR, but you have to wonder why we didn’t get that decades ago instead of the password expiration.
Probably these days if forced I would use <Prefix><Season><Year>. I don't know how much better that is. But luckily now I work for myself.
For most people, the answer is "never".
We are actually quite good at safely keeping secrets on paper in our wallets, and so generally writing down a password and keeping it there is fine, especially if the choice is between doing that with a strong password or using a weak password that you memorize.
I can see some circumstances where it could make sense, as you say where physical security concerns are less of an issue.
That said I wouldn't say a 2FA device is like a post-it note really.
Assuming you're thinking about TOTP like google authenticator, access to the codes is protected by the devices' security, which adds a bit more to it than a post-it under a keyboard.
https://www.schneier.com/blog/archives/2005/06/write_down_yo...
I don't think anyone recommends writing down the password on a post-it note and put it on the computer screen at work.
In organizations, one issue is users knowingly sharing their accounts with fellow workers. It's not because they don't know better, but because this is more convenient. Forced password changes (with limits on password re-use) can limit the risks caused by this.
The only thing it prevents is the continuation of a password-based breach.
What I mean is that if you ask your users for a password that includes lower-case letters, upper-case letters, numbers and special characters you will probably end up with something like 'Password123!'.
Instead, we could ask our users for reasonably complex passwords without requiring to include specific characters sets. Yes, I am talking about