Password expiration is dead, long live passwords(techcrunch.com)
techcrunch.com
Password expiration is dead, long live passwords
https://techcrunch.com/2019/06/02/password-expiration-is-dead-long-live-your-passwords/
315 comments
YouTube has this problem to an insane degree, some large businesses are run from a single person's long standing Google account and there's no way to give another YouTube account any privileges you might want an employee to have without giving them access to your entire Google account and all attached services including your emails, the ability to locate and wipe your phone, all the photos on your phone via Google photos, your calendar for it's entire history, I could go on.
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.
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.
Not true. You can give people access to manage your channel. (https://support.google.com/youtube/answer/4628007?hl=en)
Can't you just convert the channel to a brand account the associate new people? Has worked for us for years and afaik people don't have access to anything other than YouTube.
You can. OP simply doesn't know that feature exists.
I agree sharing passwords is a really common thing, even among corporate / enterprise SaaS. Even with MFA people share dongles / code pads.
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.
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.
Exactly, built-in delegation and impersation features solve this. AWS IAM and Kubernetes have great implementations. Hopefully we get some more standards like OAuth so people talk about this stuff more.
On the consumer side there's also the various "Family Sharing" systems that are only now in their youth. I think that's a "digital asset rights" fight waiting in the wings that some sort of "family sharing" should probably be guaranteed (by laws, probably), including to answer questions of proper transferal of "ownership" (right now "family sharing" in most cases isn't something that you can gift in a will/estate; most digital asset accounts aren't considered survivable after the death of their original user).
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).
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).
MFA does not mean no sharing. It is trivial to setup up multiple credentials for the same account. You can easily have two different fingerprints setup as 2FA from two different devices for the same account. Most services let you have backup codes and dongles already. This is mostly an issue of education. We already see a lot of these kinds of other factors like sending a message to device 1 when provisioning device 2.
In theory you are correct. In practice very few systems are set up so that two different people can share an account without using a shared password.
> It is trivial to setup up multiple credentials for the same account.
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.
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.
This is such a ridiculously widespread problem...
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.
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.
MFA doesn't necessarily mean "1 person = 1 account". TOTP codes can be shared, there can always be copies of the certificates, multiple security devices added to the same profile, etc. It differs from case to case.
Which as I say, all depends on the provider implementing these extra options, in a way that the layperson can use.
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.
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.
Do laypeople know or care about the details of password hashing too, and if not does it matter if they know what TOTP stands for?
“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?
“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?
If your TOTP key is stored in the same place as your password, is it still in any sense a second factor?
As long as it is in a place that you 'have', I believe we can technically count it as MFA.
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.
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.
That argument surely holds if you’ve got Google Authenticator and 1Password installed on the same device?
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)?
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)?
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.
U2F on Firefox works well GitHub in my experience; it's Google that's the problem. Mozilla have added a shim to enable login to Google using a key but (due to spec deviance) if you want to add a key you still need to use Chrome :(.
WebAuthn (previously U2F) is just now gaining that support and momentum, with support both in Firefox and Android
Oh for sure, and if Safari (including iOS) gets support we'll be golden across the board [1] whereas U2F was until recently pretty much Chrome-only [2]. It just can't happen soon enough!
1: https://caniuse.com/#feat=webauthn 2: https://caniuse.com/#feat=u2f
1: https://caniuse.com/#feat=webauthn 2: https://caniuse.com/#feat=u2f
Most users with TOTP assume that TOTP is bound to their app (often Google Authenticator without a backup option / migration path AFAIK). Technically, you are of course fully correct.
> There will always be a small percentage of situations where '1 person = 1 account' will never be true.
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.
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.
I don't know, but (at least some of) the apps that need multiple logins for precisely the scenario you suggest, seem to have solved this. Here in India we have some grocery apps that deliver (mainly perishables) every morning, such as Doodhwala (https://play.google.com/store/apps/details?id=com.bangertech...) and MilkBasket (https://play.google.com/store/apps/details?id=com.milkbasket...).
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...
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...
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.
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.
Wow, you nailed it. Your post describes our household precisely. The only shared password I have is with my spouse for a grocery list app. The most annoying account problems we have are with accounts for household gear such as wifi-aware garage door opener and pool pump.
You shouldn't take that shortcut over the lawn either. There are two answers to that very basic design problem:
1. Build higher fences to force people to walk along the prescribed path. This is often met with resentment, and various attempts at climbing the fence, or even cutting it down.
2. Lay bricks along the new organic path, so that it's safer to traverse.
I like the latter choice.
The principle is just about the same in the digital world.
1Password allows me to share specific credentials with a person. And these credentials can include the generator for one-time-passwords.
> 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.
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.
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.
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.?
1. One time Password ?
2. Change password before/after authenticating their device
3. Improve communication with spouse regarding milk eggs crap wrap etc.?
The other part of this story I did not see mentioned is that I suspect that password expiration also makes organizations more vulnerable to social engineering hacks because legitimate users (I have done this) become locked out due to poorly managed password expiration, then have to call in to restore access. The use of insecure identity and authentication mechanisms like student IDs and security questions is a recipe for abuse.
Good riddance to password expiration.
Good riddance to password expiration.
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.
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...
Always a joy when your generated password is refused:
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.
694*C73&4:Ekp>fy>SE&o![RC
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.
Not so long ago I had to register to a website allowing a comma (or was it a semicolon?) in a password during registration but refusing to login using said password. Fun times.
I once spent 15 minutes trying to register in a local Domino's website which kept bugging me about lack of a special character - even though I had one in it. Turned out to be that the app truncates the entered password after the first 20 characters and only considers the first part. Thankfully the special character was after the 20th position so I noticed the error and fixed it, but if it wasn't I'd be wondering the next time I'm logging in why it's not letting me login with a valid password.
Why do you need a secure account to order pizza?
How else are they going to run pepperoni-based big data analytics?
I've had the same problem with Verizon, in the past the password would only store the first 20 characters. Took me an hour or two to figure it out and fix the problem. I'm not sure if that's still the case, hopefully not.
My issue with Verizon is they lock an account after 3 bad attempts, and the "username" is the cell phone number for the account. Which seems to be slurped into some automated brute force engine.
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.
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.
You might not even have noticed if the login form truncated the input as well before hashing it. (You probably would have noticed after some update to their website removes the truncation though.)
Presumably it also truncates the password when doing sign-in?
Hm, yes. I had that happen with a '#'. Presumably there was some nasty evaluation going on and the rest of the password was treated as a comment.
I wonder why I never pursued that.
I wonder why I never pursued that.
I've had that with work passwords - using my password generator I give them a 64-character gibberish mess, but it turns out that they only accept 16 characters, and I rendered my account useless until they could reset it for me. How frustrating.
You will usually get far better entropy by simply stitching together a random array of everyday words. Example: stitching better everyday words array entropy level. Anyway, as for the too-long problem, then I guess we're back to square one. :)
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.
I disagree. I use a 1Password, and I used to do the "totally random string of letters, symbols and digits", but I've dropped it for the "four or five random english words" alternative for all new passwords.
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.
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.
... for the same length. But length doesn't really matter unless you're manually typing it in, in which case many people will be faster at typing words than random characters.
> [...] 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
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.
For anyone keeping score at home, some handy-dandy tables with entropy per symbol:
* https://en.wikipedia.org/wiki/Password_strength#Random_passw...
* https://en.wikipedia.org/wiki/Password_strength#Random_passw...
> Far better entropy
> random array of everyday words
No, that's not how entropy works. Random characters still score better.
> random array of everyday words
No, that's not how entropy works. Random characters still score better.
Good try, but that doesn't apply to password managers. Several everyday words contain more bits than a garbled single word, but a string of dozens of truly random characters beat both.
You might be referring to https://xkcd.com/936/
You might be referring to https://xkcd.com/936/
That's the one! ^^ And you're of course correct.
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.
The result was a password that was shorter, less varied, and less secure than the previous one.
Good job, Chase.
I had a similar problem with Lloyds - every time I wanted to transfer money using the mobile app, I had to type in the password manually as they had disabled the "paste" option. Given my password was auto-generated and 16 characters long - and the password field wiped every time I did an app-switch, I just gave up.
It's very disturbing to see that your worst passwords are for your bank accounts. Each bank I've worked with has some weird limitation like this. Not to forget that the only form of MFA that most banks allow is SMS - assuming they even offer MFA.
Banks are probably still running on the old mainframe (old as in upgraded in 1998 when y2k forced it), with password storage that was state of the art in 1960 (plain text, but the file is actually protected well so hackers can't get it). That isn't to say better password cannot be used, just that they have never enabled it.
I don't understand that - I get that the system that holds the data is old, but when creating an online banking system shouldn't the piece that holds the data be a good half dozen steps removed from the website and authentication?
Not if you want a single sign on. Of course customers only use the web login, but internal people have to deal with all these different logins.
"Don't Fuck With Paste"
http://browserengine.net/dont-fuck-with-paste-for-chrome-and...
http://browserengine.net/dont-fuck-with-paste-for-chrome-and...
I have a Keepass app on my phone, Keypass2Android:
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.
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.
> my old password was no longer permitted.
But how did they know? They should just have the hash...
But how did they know? They should just have the hash...
If they implemented it properly they could have checked the current password against the revised guidelines on the next login. No need to store it in plain text
The website can check the password during login without storing it in plaintext
The login form usually sends the password in cleartext and it's then hashed on the server-side prior to comparing it to the hash stored in the database.
So they can just determine the password's strength at the time when the user is logging in
So they can just determine the password's strength at the time when the user is logging in
FirstDirect's "digital secure key" Android app, which allows me (or someone else who happens to get hold of my phone while it is unlocked) to transfer a few grand out pretty easily, limits passwords to "between 6 and 9 characters". And offers fingerprint based auth as an alternative, because we all know how infallibly secure that method is.
People were forgetting their passwords and using up valuable support time.
Since the responsibility for password storage is on the customer anyway, we might as well make our password a maximum of 6 characters!
Since the responsibility for password storage is on the customer anyway, we might as well make our password a maximum of 6 characters!
Some never memorize their passwords at all. Instead relying on 'forgot' emails and "Remember Me" features entirely.
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.
But Slack then must rely on the security of your email. If the site is dealing with sensitive information like credit cards, this could
be a no go.
Any site that has a "enter your email for a reset link" feature relies on your email security.
Almost every website in existence except the most security sensitive like bank websites will allow you to reset your password with email.
What email based log in that doesn't use 2FA doesn't ultimately rely on the security of your email?
Indeed. On sites I have to register but know I won't go frequently I enter a random password I don't even write down, relying on the Forgot password feature if I ever need to come back later.
I have wondered if some web pages effectively have this as the main log in method. If you have a hurricane tracking page, everyone is going to forget their passwords in between hurricane seasons.
Steam has nearly done this for me.
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.
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.
Bulb energy supplier in the UK trialled this - they soon switched due to complaints although I didn't really mind it.
Assume it was due to the inconvenience of not being able to remember password/stay signed in.
Assume it was due to the inconvenience of not being able to remember password/stay signed in.
Yahoo Japan (not really related to the defunct original Yahoo and still very successful in Japan) recently abolished passwords for new accounts.
You can only login with reset emails or SMS codes, which is pretty annoying.
You can only login with reset emails or SMS codes, which is pretty annoying.
I wondered about this too and asked about it on the security stackexchange forum in case I was overlooking some glaringly obvious reason not to. Turns out that most thought it was reasonable too, though maybe too frustrating for some.
https://security.stackexchange.com/q/12828/8518
https://security.stackexchange.com/q/12828/8518
I've seen Blendle and a couple of other web sites do this.
You go to the login page, and your choices are federated login, standard login, or a one-time login e-mail.
You go to the login page, and your choices are federated login, standard login, or a one-time login e-mail.
medium.com is famous for email OTP authentication. They even blogged about it (search hacker news for more information)
In India, most mobile apps have phone number for username and OTP instead of password. Makes perfect sense for mobile apps. Except when OTP doesn't arrive due to congested sms networks. Or that your account gets hacked with sim takeover or sms MitM (both are currently unheard of in India).
I think you just jinxed it.
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/
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're relying on your email security either way, since anyone can trigger the password reset email if they get access to your email account.
This breaks my workflow -- I almost never open the forgot-password email on the same machine I used to initiate the request. Usually I need to briefly access a personal account from somebody else's computer or my work computer, and when I'm told I need to check my personal email, I only want to open that on my phone.
Honestly this just seems like there needs to be a better way. Maybe some multi-factor system that requires like a physical key and either a secret and/or some identifying thing.
"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.technet.microsoft.com/secguide/2019/05/23/secu...
Full post: https://blogs.technet.microsoft.com/secguide/2019/05/23/secu...
> 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.
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).
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).
If that’s the fear then all passwords should expire at the same time. Otherwise if you reset every X days, hackers will always have access to some accounts X days.
In the current method, possible access risk is staggered, such that you only have access to some accounts, for some days.
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
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
On day zero staggered means they still have access to ~100% of accounts.
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.
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.
Doesn't that only matter if you use the same password for more than one account?
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 breaches from spreading into your system.
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.
List-checking can't help every time. Some people use "clever" tactics to use slightly different passwords (hunter2fb for Facebook, hunter2tw for Twitter).
[deleted]
Assuming there is no zero day exploit. But then I'm paranoid.
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 times before I remember it might be an expired password.
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.
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.
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.
password1, password2, ... password23, password24.
This means that if you discover someone's current password, you also have their future 10+ passwords as well.
I use a password manager. I have no idea what ANY of my passwords are, as they're very long, very random, etc.
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.
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.
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.
That is certainly how you would do password expiry if you implement it as a true security measure. However, what if you just implement it because you were told 'we need password expiry', either because bosses think it is bad practice or because of regulatory requirements. In that case, you might very well decide to implement 'any difference is fine'. And really, given what we know about password expiry, that is the better approach.
Not having it would be better, but that would be insubordination.
Not having it would be better, but that would be insubordination.
hmmm good way to get users to become heated with your customer support. i've implemented this feature and had the CEO of the company come down 15 floors and tell me personally to revert the change for him coz it was getting confusing for him to remember passwords. Everyone else in the company also demanded it once wind of this request spread...
This was the middle east, and yes they refused to use password manager programs because they didn't understand them
This was the middle east, and yes they refused to use password manager programs because they didn't understand them
It is largely agreed that Israel won the Arab-Israeli war because their NCO's on the ground were given much more leeway to make tactical decisions of their own. This was in start contrast to the top-heavy and often bureaucratic tactical decision making of the Arab League.
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.
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.
I don't work in the middle east anymore for a reason...there is no changing some things until there is leadership from the top
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.
You'd be surprised. At my uni of 50k students the running joke was you'd just add 1 to your password every six months.
I misread you, it's fine for the current password. But they can alternate between two.
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.
Even if you don’t want users last 10 passwords to be “similar” (by whatever your definition of similar is), you can still hash the similar variants when you hash the original and check them.
I’m not saying whether this is a good idea or not. I haven’t thought through it.
I’m not saying whether this is a good idea or not. I haven’t thought through it.
Yep. I think I can recall exactly one corporate network that prevented password(n+1) combinations. Most don’t and as a result my corp passwords have historically not been great.
> 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
This is a very good reason to change bank. That unacceptable answer would certainly induce me to rage quit the service, whatever the inconvenience.
This is a very good reason to change bank. That unacceptable answer would certainly induce me to rage quit the service, whatever the inconvenience.
Possibly, but... have you gone in to a bank and asked if you could test drive all web and mobile apps for some period of time to make sure everything was up to snuff?
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.
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.
I've run into this a lot in other software as well.
Another worst offender are security questions to unlock accounts. Answers to these questions are usually visible to customer service reps and similar set of questions are asked among different services. This is scary.
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.
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.
I answer these with random wrong answers and add the question/answer combo to the Notes section in my password manager.
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.
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.
I use fake answers. Treat them as basically secondary passwords. I do keep them as real words though since sometimes they need to be answered over the phone and you don't want to read a long random string of characters.
Yeah, I used to use randomly generated strings until a customer service rep asked me to recite my security question answer to them... Now I use something like Diceware for real words.
That's excellent, I had no idea that existed, I'll have to start using that. Though it is fun to do a game of security question chicken - how much letters are they going to listen to me say until they go "ok, that's good enough"?
Customer Rep.: "What is your mother's maiden name?"
Scammer: "I just entered a bunch of garbage."
Customer Rep.: "Yup! Thanks for verifying that Mr. Smith!"
Scammer: "I just entered a bunch of garbage."
Customer Rep.: "Yup! Thanks for verifying that Mr. Smith!"
"A bunch of garbage" is actually kind of a fun answer in itself. "Who was your childhood best friend?" "A bunch of garbage."
Haha that's pretty funny. "Who was your first college roommate?" "A bunch of garbage."
I recently closed a bank account I opened purely to take advantage of their decent interest.
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.
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.
My bank uses the mobile app as 2FA when you call in. You first have to login to your mobile app and then have to verify it. That alleviates the stolen phone number issue.
I've long since started just putting in random password strings for these.
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, the whole works).
Ultimately they told me what my mother's maiden name was: qewqewdfskjr3924kjasdf
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 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 random caller to reset the password if they can see that those fields are garbage.
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.
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.
This is what I do, although like others mention I still use real words. I add my bogus answers to security questions as notes in my password manager. This method has worked well for me for a long time without any risk that I have discovered.
Currently locked out of my bank for the weekend because of this :)
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.)
(The good thing is this is only an interim requirement until a proper two-factor system is implemented, as required.)
Not sure expiration is the worst problem with passwords. In no particular order,
* 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
* 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
> * Forget about usernames. The password becomes an 'account key' and is all you need
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.
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.
Any amount of profile information can be associated with an account. But a better, more secure technique than describing the account, would be to create a temporary token for the account and share it with support. That proves you're authorized to ask support to make changes in that account.
That's exciting news, though it will take a couple of years until it trickles down to financial institutions. My bank forces me to change passwords every 3 months, and of course they also disable pasting for added security.
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.
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.
> 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
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
Disabling clipboard events will break certain helpful paste mechanisms too, for example pasting images to upload.
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?
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.
Bank programmers live at least 5 years in the past.
I'd say this is because it takes that long to get a feature from design to production, in a bank.
Military programmers live 20 years in the past because the contracting system forces them too. The contracting people live in 1970. The actual flag officers in charge live like it's 1955.
Depends on the bank. I guess in US banks themselves are 20 years in the past.
My bank had this log-in setup, where you have your fixed password but also need to enter a password from your password card. This is being phased out and will not be available from Sep 1st. I myself have been using mobile signature/smart-id (https://www.smart-id.com) for years now. Other remaining options are using your ID card or passcode generators—like Google Authenticator but a physical device.
Bank programmers don't live. They exist.
PCI certification requires passwords to be rotated every 90 days.
German banks also like their 5 character passwords! Fortunately you also need a per-transaction TAN code which makes this a bit better (though many people have this on paper or via an SMS, though perhaps paper is not that bad).
If you're in need of business banking, you can use mercury.co (my company) and enjoy unlimited length, non-paste-breaking, password manager compatible, no expiration, no character restriction passwords + non-SMS based 2FA :)
Hopefully we have five years before competitors catch up to us and implement this cutting edge technology!
Hopefully we have five years before competitors catch up to us and implement this cutting edge technology!
I have 2 and 3 year CDs in a bunch of banks. (This is a common use case, people open separate accounts because of the FDIC insurance limit in any one bank). I only need to log in again 2 or 3 years after opening the account to either take the money out, or open another CD.
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.
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 can't recommend e-banking enough. Through Fidelity you can purchase CDs from a number of banks across the country, shopping for the best interest rates. And you can create an auto-rolling CD ladder if that's your thing. I presume other e-banks like Schwab have similar features. Then you can manage all these things in one place, while getting the benefit of having your funds FDIC insured because they're technically CDs at multiple banks behind the scenes.
I would think money market mutual funds are a more liquid, easier, higher yielding version of that. They don’t have the FDIC insurance, but they’re well diversified and invest in the highest grade of bonds, and “breaking the buck” (holding less than enough to redeem all deposits) is extremely rare.
From 2008 - ???, money market accounts were offering 0% interest, while CD's provided some small rate of return.
*A common use-case for millionaires. FDIC limits are $250,000 per-institution, per-account owner, per-account type (CD, money market, savings, checking) and my understanding is joint accounts are considered separate owners so two spouses could have up to $750,000 in CDs at a single bank and be fully insured.
30% of households have an aggregate net worth above 250k. So the situation GP in describing is probably very common.
But the majority of that 30% with a net worth above $250k have most of it in the form of their house, not CDs.
The portion of households that have $250k in the bank is no doubt much less than 30%.
I don't believe that most high net worth households are that cash heavy.
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.
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.
I think my credit union expires every 90 days :-/
I've always wondered how many engineer hours have been lost on the phone with helpdesks sorting out expired passwords.
I did some lunch table math a few weeks ago. Assuming it takes on average 30 min for an employee to rotate a password (reboots, re-logins, etc.), assuming an average $50/hr across all employees, ~600k employees @ 4 changes per year (my current company policy is ever 80-ish days) = $60MM of human time spent per year making the company less secure.
It doesn’t take 30 minutes to change my password from ‘password5’ to ‘password6’ though.
If I don't restart my laptop after changing my password, I'm saving up for a whole load of shit. The proxy logins may, or may not, continue to work, but it's highly likely that at some point in the next few hours, Outlook is going to trigger 3 failed password checks and lock me out of my mailbox.
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.
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.
You're assuming it works. Where I work we have an intranet-based web app that pushes the new password to all the various corporate systems. We're forced to choose a new password every 90 days. I'd say 1 time out of 3 something doesn't work, and I have to open a support ticket. While I'm waiting for support, I'm not getting emails, or can't log in to some systems, etc. Multiply that by hundreds of users at my company.
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.
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.
It's an insane amount. I've worked on writing helpdesk software for almost a decade now, and from time to time we are asked by our customers to run some analysis on their data; password resets are usually from 25% to 50% of the total requests to the system.
I work in the identity management space of a household name financial institution. We have varying levels of outages, but the top priority one is if people are unable to reset passwords through our UI. It's an absolute nightmare.
The real problem? People introduce password expiration to improve security, but the means of producing a new unexpired password after being locked out is less secure than the password itself creating a net loss in security.
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?
I don't know the origin story but (U.S.) National Institute of Standards and Technology (NIST) recommending password expirations from 2003 until 2016 played a part in propagating them. But I think that recommendation was largely based on was already fairly common, I think Microsoft Windows and Active Directory accounts expired by default well before 2003 (at least Windows NT and its successors).
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/search?q="password+expiration"&lr=lang... )
Ngram plot: https://books.google.com/ngrams/graph?content=password+expir...
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...
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
Unreliable tablet input compounding even less reliable short-term working memory.
http://shop.oreilly.com/product/9781565921481.do
My favorite one was when I supported a customer who expired our passwords every 60 days, and resetting it involved calling Sweden (from the US) between roughly 10:30pm and 7am Pacific. Needless to say, of the 40 or so people who should have been doing this, few of them were.
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......
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......
Ah good stuff. Password expiration is a pain, but it's worse for Windows login because I can't even open Keepass until I get in!
When forced to do this I will use something like "B@s3P@ssw0rd1" then "B@s3P@ssw0rd2", "B@s3P@ssw0rd3" etc.
When forced to do this I will use something like "B@s3P@ssw0rd1" then "B@s3P@ssw0rd2", "B@s3P@ssw0rd3" etc.
That's still a weak password. Letter substitution doesn't increase the difficultly, as password crackers try all the variants as a matter of course.
Better to use a combo of several words such as... BatteryHorseStaple. :)
Better to use a combo of several words such as... BatteryHorseStaple. :)
The point was changing the number at the end to work around the requirement to change the password. My real pw was better.
I still expire passwords on a yearly basis for the sole reason that users have complained to me that it stops them from using the password they use for everything else.
That's amusing but... those same users are likely to be using just altering their passwords a little like "passwd1" "passwd2", etc. You aren't gaining anything.
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.
TOTP or other forms of 2FA are the best way of avoiding the very real problem of user password re-use.
I don't see how TOTP/2FA can avoid the problem of user password re-use. The password has still been reused, whether an extra layer of authentication is used or not.
Maybe you can say that it mitigates it, but I don't think it avoids it at all.
Maybe you can say that it mitigates it, but I don't think it avoids it at all.
I'd say it avoids it, mitigates would work fine.
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.
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.
There are two slightly overlapping ways to actually solve this problem: 1. Use a password manager. 2. Have the tools, knowledge, capability, and willingness to use secure passphrases.
One other way. Websites could hash and salt the users password client side, then proceed as usual (SSL and hash it server side). Means the users password is effectively a long, secure passphrase and is unique. What do you think?
Testing against known password lists is a huge win.
Yes, this is the right answer. See https://haveibeenpwned.com/Passwords
I came here to say this. I can't think of another way to guarantee that they aren't using the same password that they use on every website they've visited since 1997. If anyone has suggestions on this I'd love to hear it.
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.
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?
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
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
From memory their system works by a using a partial-hash, minimising the leak of the password.
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.
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.
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.
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.
Yeah I know - checking a new password is worse!
Turns out he's downloaded a hashed list and is checking against that. Which is fine.
Turns out he's downloaded a hashed list and is checking against that. Which is fine.
The “regular” api works on a hash of the first handful of characters - in no scenario do you send the actual password to a remote service, so what is your concern?
The check is done locally against a hash. There's no risk of leaking the password.
Ok, that is fair. I thought you were skipping this rule from Troy Hunt (HIBP creator): "Do not send any password you actively use to a third-party service - even this one!"
How are you implementing these checks?
I'm using Active Directory and options for extra password checks are somewhat limited.
I'm using Active Directory and options for extra password checks are somewhat limited.
Microsoft has a pwnedpasswords-like service you can use:
https://docs.microsoft.com/en-us/azure/active-directory/auth...
https://docs.microsoft.com/en-us/azure/active-directory/auth...
I don't think this (Azure AD Password Protection) actually implements a pwnedpasswords-style check.
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.
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.
* If you use Azure Active Directory
On-premises AD has the same functionality but it is a pain to set up and so limited as to be not worth the effort
You can use a dll to do additional security checks on a domain controller base. Check this
https://github.com/JacksonVD/PwnedPasswordsDLL-API
The problem is the password change UI on Windows systems is terrible. It does not give users any clue why their password was not accepted other than "Unable to update the password. The value provided does not meet the length, complexity, or history requirements of the domain."
If you have the DS-Replication-Get-Changes permission, you can exploit dc-sync through something like mimikatz [0] to grab the password hashes out of Active Directory, so you can run your checks.
[0] https://github.com/gentilkiwi/mimikatz
[0] https://github.com/gentilkiwi/mimikatz
Oh sorry I'm not using AD, it's just a web service.
I disagree.
I feel it's not a site's responsibility to stop users from reusing their passwords if they choose to. It has no relation to the security of the service. As a metaphor, a good lock maker protects their customers from lock picking, not from a key left under the mat.
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.
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've never heard of a website implementing something like this. Password rotation requirements are usually found in corporate or government settings, for logging into your workstation, email and internal applications.
"internal" and line of business apps are not provided as cloud hosted SaaS yet?
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
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
This is definitely a dilemma.
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
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
Yup, this type of feature is the answer.
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.
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.
The requirements are actually using Google accounts, and requiring all your employees to use Chrome.
Not sure about the legality of this, but trying to log in to a a couple of services would be an easy test.
A secure service wouldn't have an easy way of getting at a user's password. They'd store the salted hash of a user's password, and not the password itself.
You mean hash it in the browser? That's rare. Otherwise, you have the plain text password in the request you do the hashing and writing the hash to storage in.
If services were secure then password re-use would not be such a problem.
Some possibilities off the top of my head (some suggested here already):
* 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.
* 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.
> Test for password existence in public databases
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.
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.
I'm not an expert, but you could integrate DBs like https://haveibeenpwned.com/Passwords to make sure users don't use exposed passwords?
Strong password policy. Reused passwords are often simple.
I guess other options could be not allowing the users to set their own password but instead generating a password for them.
Or just require 2FA for everything, but that’s hard to do with a lot of software.
Or just require 2FA for everything, but that’s hard to do with a lot of software.
Require all employees to use a password manager?
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).
If your profile is up to date: why are you including password reuse attacks in your threat model?
I'm not entirely sure that I'd agree with this mentality. Sure, at a glance it sounds good. If the password has been safeguarded, there's really not much reason to force expiration. However, wouldn't the age of the password reduce the security of it by default? The longer a password exists for, the more likely it is that it can be cracked, discovered by a misplaced Post-It note, or compromised by some other unknown security issue. With all the other security and privacy concerns in this thought process seems contrary.
I flat out do not buy the argument that by virtue of existing a secret becomes less secure. It's just not practically true. The assumptions needed for this to make sense are that people are actively attacking a given secret, that the new secret will be generated from arbitrary entropy (not depend in any way on the previous secret) and be a secret an attacker has already tried (otherwise the rotation was pointless). Furthermore, all keys already exist. When you "generate" one you simply pick from a large domain. The probability that two people (attacker and defender) pick the same key from the same domain does not change because someone already picked a key from the domain.
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.
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.
Reality is that a password expiration policy quite often leads to password simplification (e.g., having an incremented number in the password, post its on the screen,
...).
I'd prefer 2FA and (allowing / encouraging) longer / stronger passwords over change policies.
I'd prefer 2FA and (allowing / encouraging) longer / stronger passwords over change policies.
At one of my previous employers the default password set by the help desk was [company_name]@123. They did a password audit and a full third of the employees had a variation of this password for their real password. It's not Google, but if it were, passwords were things like: google@321, google@456, etc.
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. There are definitely better ways than raw expiration. Why not present the user with a screen that basically says "hey, your password hasn't been changed in __ time, you'll need to fix that now to access the system" when they log in after the set time period?
> 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 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:
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
> 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.)
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.)
Crap, I forgot about that. I guess I'll have to swap words if that ever happens:
Complicatedpassword1
PasswordComplicated1
Complicatedpassword2
PasswordComplicated2
Complicatedpassword3
PasswordComplicated3
> it's often the only way to ensure that the end user actually updates their password regularly
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.
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.
This is largely true, but we also exist in a day and age where computing clusters can fire off billions of guesses per second. Anything less than 16 digits takes a questionably small amount of time in comparison, when paired with some of the more advanced attack vectors.
This is the wrong argument here. With regards to brute force attacks changing password is only relevant if the attack time is comparable to the password turnover. If it takes one week to crack a simple password but you only change it every six month then you have ~1/24 chance to actually increase the attack time.
2FA is the solution. That way the password is only to protect against someone who physically has access to your keyfob (nosey coworker, thief, etc). Thinking of passwords as the solution to protect against sophisticated actors is the mistake.
Properly implemented 2FA, for sure. Having been on both sides of various types of 2FA failures, but I definitely agree.
I'd suggest that users who care , when no longer forced to periodically rotate passwords, will likely choose better passwords (I know I have, where I'm no longer required to do so).
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.
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.
You can't force entropy out of people when there is only so much, regardless of how often you believe you're make them "change" passwords.
I think password expiration came about before two-factor authentication was as easy to use as it is now. Security concern around password age would be mostly obviated by 2FA.
Mostly, if implemented properly, sure. I would agree with this.
Even if that natural decline in security was significant, it wouldn't be as significant as the insecurity introduced by forcing the user to change it.
You're ruining this for everyone.
So does this mean they also changed the guidelines in the SSPA? This is their security framework / certification for vendors doing business with Microsoft.
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.
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.
I wish every compnay that does this will stop too. It's so frustrating and annoying having to change my passwords so regularly.
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.
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.
Not only are expirations pointless but it’s ridiculous that a 24-hour expiration system is often paired with a “Monday-Friday, 9-4 Eastern” kind of phone call.
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.
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 expiration made average users need to remember more password combinations and resulted in them using the same password for each website they use. This is a serious issue, especially when sites the size of facebook are accidentally logging plaintext passwords on their servers.
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.
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.
That relies on every website implementing this solution, and I don't think such coordination is possible.
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.
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.
Well any website serious about security - yes. But if a single website decides to do it it would work fine. It would be quite easy to just add a js file with this. For example this one for the Stanford JS Crypto Library: https://github.com/bitwiseshiftleft/sjcl/blob/master/core/sh...
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.
How would protecting a single website help? If the password is shared among different sites, and one of the sites turns out to be malicious, I'll be able to access your single website just fine by typing the sniffed password into your textbox, whereupon it can use however much hashing and encryption as it wants and it won't help.
Ah I see what you're saying. You're right, in the interim period before everyone changes to client side hashing that is an issue. Though there's no loss to implementing it, but it's just not as beneficial until more sites have it.
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.
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.
This has known for years now, but unfortunately, takes a long time to change.
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...
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...
As an ignorant person who doesn't do multiuser anything, how is this a problem if you are sure you're the only user of a physical system? The moment my computer is compromised by anyone else I'd think all bets are off then.
I think the recent compromise at matrix.org [1] is a good example of how better defence in depth could have mitigated the damage done by an attacker who compromised a trusted machine. Specifically, access to a developer's SSH agent was the critical privilege escalation vector in this attack.
[1] https://github.com/matrix-org/matrix.org/issues/371
[1] https://github.com/matrix-org/matrix.org/issues/371
A malicious third-party package (example: https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_st...) could read well-known environment variables like AWS credentials or something. I don't understand why we didn't heard about this kind of attack yet :D
The first time I came across password expiration was on a login I was given to someone else's windows server. I only needed to log in once a month or less and every single time I got the message, your password has expired and must be changed, it was laughably pathetic how they ever expected people to remember a new hard to guess password every month. So of course I did what others have said and tagged on a 1 each time to the end.
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've been using lastpass for 6+ years now and its never asked me to change my master passphrase, let alone every 180 days.
Very strange, I wonder if there's anything special about my account. Here's the message I'm getting, when I log into the web console:
https://ibb.co/5vMVyJ4
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.
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
And the UK equivalent from the National Cyber Security Council is at:
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.
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.
I sent in the NIST announcement to enterprise sysadmins last year as an opportunity for improvement. They closed as wontfix. I dont blame them for moving slow. This hopefully will move them a little.
They have a guy whose job is basically to deal with unlocks after password changes.
They have a guy whose job is basically to deal with unlocks after password changes.
Great but this still exists in outlook online, Amazon, and probably other places. If Microsoft is really serious about this, they would get rid of password expiration everywhere. It actually leads to less secure passwords as combined with their shitty ui and multiple password change systems, each with its own password rules (another stupidity that needs to die), it leads one to ignore the password generator and manager and just use a simple password that can be remembered and changed by one number when it expires. This way I'm not updating multiple clients constantly and can actually change the password on the first try. I'm glad such insecure and stupid practices are finally going away.
When signing into Office 365's admin portal for the first time, "Set passwords to never expire" is actually the first and only wizard-type suggestion that's presented as a best practice to get out of the way.
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.
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.
Surprisingly, the most important organizations (like banks and government departments who have critical data) who need to ditch this practice, embrace it like the holy grail.
I'm in the camp where I don't want systems to do fancy validations on passwords but I do think expiring passwords is not a bad idea. The thing is that many times your password can get stolen and you might not even know it. I've seen people writing down their passwords on sticky notes, saving in Chrome, get stolen by fake apps etc. At least for Windows, expiring passwords wasn't huge pain because of integrated authentication everywhere.
We’re required to have password expiration by law in the public sector of Denmark. So I’m sure we’ll continue to have it for at least some years to come.
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.
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.
Writing passwords on paper is recommended by security professionals, in the common case where your physical security is far more trustworthy than your digit security, because it supports the use of long, strong password. A 2FA device is very similar to a Post-It note.
Actually most security professionals have a serious downer on writing passwords down.
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.
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.
For example Bruce Schneier recommends writing down the password and keeping it in a relatively safe place like the wallet (where people keep other sensitive information like credit card numbers).
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.
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.
Even then, if it's an OS password (drive encryption n/inc) and they have physical access to the disks containing assets then it's already game over.
I briefly worked at a place that enforced quarterly password changes and I literally used <Season><Year> as my password. I am not good at remembering passwords and I don't think I'm that unusual. Writing them down seemed worse than using a poor password that I can at least remember.
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.
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.
How often have you had information stolen off a credit card, passport, driver's license, insurance card, or other item with sensitive information printed on it that you routinely carry around in your wallet?
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.
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.
Plus, people usually have a better memory that they give themselves credit for. With reasonably short random password (say, 10-12 chars, uppercase, lowercase, digits) that you use often, you will memorize it after a week, at which point you can simply destroy post-it note you carried in your wallet.
Plus if your wallet gets stolen, you will know someone potentially has your password, and change it.
Writing down is much better than using a guessable password. Your physical location is more secure than a password in a rainbow table
This should be coupled with the usage of multi-factor authentication and making users aware of when and where their accounts have been used.
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.
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.
Can we stop linking to Oath family websites until they sort out the cookie policy UI?
There's so many better ways to identify an account than a string of characters. Just like we shouldn't be using an integer for Credit card numbers or Social Security (or Social Insurance for the Cdn's)
Can't we say good riddance to all passwords yet? I yearn for the day where I can log-in everywhere using public key cryptography.
Not yet, I'm afraid. Passwords are the best of the bad solutions people came up with. For public key cryptography, the problem remains, as always, key exchange. How can one be sure you are who you say you are?
But this only concerns the first usage. Once a public key has been acknowledged there is never further need for a password. It is only you who has the private key.
At work a client pushed new security protocols on us and of course management allowed it. Now I get to update my password every 30 days.
Yes! I actually got into an argument with our IT team about this.
The only thing it prevents is the continuation of a password-based breach.
The only thing it prevents is the continuation of a password-based breach.
A benefit of enforced password changes is that you can use it to practice those keys that you are weakest at touch typing.
For those of us who have to remain PCI compliant the tyranny of password expiration will remain. 90 days unless I am mistaken?
Nice. So how many years will it take until someone realizes that asking users to include specific character classes actually decreases password security too?
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
https://www.xkcd.com/936/
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
https://www.xkcd.com/936/
for any password that requires capitals and numbers I always start it with the capital and end with the number to make it easier for me to remember.
And I am sure at least 95% of the populace does the same, and that such passwords are usually quite short. We need a better solution for passwords than we do now.
With MFA it reduces the risk of losing password. Without MFA - what if you don't know your password is stolen?
[deleted]
MFA is annoying too.
I’d like to know why info sec has traditionally been anti-science to begin with, and if they are going to adopt data backed approaches to backup their theories, what other old wives tales will they’ll be addressing next?
If your want to version secrets, environment variables and code together... you can, just make sure to use a proper solution such as http://configrd.io.
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.