Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach.
Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
I belonged to an organization that had password complexity requirements. That's normal and understandable. However one requirement was that no part of my password could contain a three character subsstring that was included in my full name. I won't give my real name here, but sadly it includes some three letter subsequences that are somewhat common in many English words. I can understand a policy that prevents someone from using "matthew1234" as Matthew Smith's password, but this rule also prevents such a person from using "correcthorsebatterystaple" because it has 'att' in it.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
> Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!
and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.
Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep track of the change interval. It also adds no security whatsoever! A user could almost certainly get away with Password2025-06, etc.
I just let the keyring roll a completely new password. For some reason, all of my employers do require this insanity, but not on the one password I have to actually type.
When I first set up an account at a new org or whatever, I don't think about the possibility of rotation later, but once I get my first "your password has expired and needs to be reset" message, I just add a counter to the end of the password that I increment each time I'm required to change it. Successive passwords have no less entropy than the original password, anyway.
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
> But these don't seem to be authoritative enough for IT / security,
As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.
Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.
Sometimes when I log into a random website and I see a forced password reset, I wonder if it has been compromised, rather than setting a time-based expiry.
If a site owner knows that certain accounts are part of a database breach or something, a reasonable step would be to force the users to change the password at next login.
Another common reason to do a force password reset is if they've moved authentication providers and were not able to bring their hashes along. Some providers don't allow for hash export (Cognito, Entra).
Last time I brought this to our cyber folks, they pointed out that PCI standards require password rotation. So it depends upon which auditors you care about more.
This requirement is in section 8.3.9 of the PCI DSS[0], and only applies to single-factor authentication implementations, two-factor auth removes this requirement.
I’ve always said “lockout turns a possible password guessing attack into a guaranteed denial-of-service attack”.
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
I think a lot of people in IT know these things but having a 'strict' auth policy makes them seem competent so they just go with that. Besides there is not much incentive to make authentication efficient since the frustrated users are a captive audience not paying customers.
I just had this argument with a state wide government website. I have to log in to this site maybe once per year to update contact information and update a few fields. Unfortunately, that site silently deactivates your account automatically every 90 days. So I'm forced to change the password literally every time I log into the dumb thing.
They refused to establish MFA or passkeys - and instead insist that "NIST is the minimum recommendation for cybersecurity... and we take cybersecurity very seriously... to ensure the safety and security of the citizens... therefore we will not change our policy on mandatory account lockouts or password change requirements."
if my password has not been leaked it's insane that providers think i should rotate it, but this still seems to be standard practice for some completely baffling reason
There’s weird math that says your password or generally a secret key is more secure if it’s existed for less time (generated fresh) because there hasn’t been as much time to brute force it. I don’t believe it but some hardcore types do.
Stuff like ISO27001 still demands it. We have to rotate passwords, against modern cybersecurity practice, in order to comply with an information security standard.
Most frameworks, at least most that I am aware of (north america) have removed password rotation requirements entirely, or have exemptions in place if you have MFA, use risk-based access policies, etc.
Often when people say this, they are parroting their assessor. But not every assessor graduated at the top of their class, or cares to stay updated, or believes that they know better, etc.
These recommendations live in a mythical world, but not in a company.
In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.
In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.
This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).
A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.
And then you have trauma that will say "we cannot change the password because we don't know where it is used".
Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.
Password rotation does nothing more than get you to use
1234abcd@
1234abcd@1
1234abcd@2
1234abcd@3
I'm becoming pretty convinced that at least in the corporate space, we'd be way better off with a required 30 character minimum password, with the only rules being against gross repetition or sequences. (no a * 30 or abcd...yz1234567890 ). Teach people to use passphrases and work on absolutely minimizing the number of times people need to type it by use of SSO, passkeys, and password managers. Have them write it on a paper and keep it in a safe for when they forget it.
This is a better use of the finite practical appetite for complying with policies than the idiotic "forcibly change it every 90 days" + "Your 8 character password needs to have at least one number, one uppercase, and one of these specific 8 characters: `! @ # $ % ^ & *`"
By the way, to quote Old Biff Tannen, "oh, you don't have a safe. GET A SAFE!"
You don't really need to convince people who implement it. You need to convince people creating certification/law, so PCI/SOC2/whatever. I'm still posting every time something like "for the record, I know we have to legally do this, but it's pointless and actually makes us less secure" for a few things.
> Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
That is extremely annoying.
On the other hand if I was a manager and that happened to someone I managed we'd definitely have a conversation where I would acknowledge that forced password rotation is idiotic, but also point out that our password expiration is 90 days after the most recent change, which is 12 weeks and 6 days, and ask how come they don't have a "deal with stupid password expiration" event on their calendar set to repeat every 11 weeks?
That gives them 13 days warning. Vacations can be longer than 13 days, but I'd expect that when people are scheduling vacations they would check their calendar and make arrangements to deal with any events that occur when they won't be available. In this case dealing with it would mean changing the password before their vacation starts.
I don't expect people to go all in on some fancy "Getting Things Done" or similar system, but surely it is not unreasonable to expect people to use a simple calendar for things like this?
The fact is that you might have an employee who is a real expert in 3rd century archaeology, but scheduling and password changes just aren't what they are here to do. They don't want to do it, don't know how to do it, and don't want to learn how to do it.
I hate Apple products for this.
I see this pattern across all apple products - not one.
On my mac, I setup my touch ID, and log in to my Apple account on the App Store. Time and again, when I try to install apps, it keeps repeatedly prompting for my password, instead of letting me just use my touchID. This applies to free apps as well, which is again silly beyond what is already enough silliness.
I briefly see this on my spouse's iPhone as well. Almost felt like Apple hasn't changed a bit after all these years. It keeps fucking prompting for password over and over, randomly when installing apps. although the phone is secured with a touch ID.
This happens especially when you reset the phone and starting from scratch - it keeps prompting for the Apple password again and again.
And it's even worse if you are accessing Apple services on a non-Apple device. No matter how many times I click "trust device" when logging in to icloud.com it will still make me do the password + one-time code song and dance the next day.
Another pointless annoyance - if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password. Why?? And of course when you're on that prompt there's no way to open your password manager without cancelling out of it entirely. Makes for a fun experience at the checkout counter...
Why in the world does it need you to type a code id you have already accepted it at the other device? This whole flow is stupid, I guess they want to cover their asses.
It often falls back to PIN if you retry faceid three times. But if the app is using faceid as a biometric second factor, in addition to or instead of as a password caching mechanism, then a device PIN is not biometric attestation and so it downgrades to full password.
Microsoft crap is similarly broken. After each and every login there is the question whether it should remember me and whether it should ask that question again. It doesn't matter at all what you answewr there, it changes absolutely nothing.
Dismiss the password prompt and reinitiate the auth, FaceID will work again. I’m not sure why Apple doesn’t let us retry FaceID on the get go, but at least theres this method.
related pet peeve: faceid is often (but unpredictably) really slow - like, I'm looking at the phone and in a hurry and would prefer to enter my pin but touching the screen goes back to the lockscreen, and swiping up starts faceid again.
> if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password.
What? FaceID will prompt for a re-try. Always. It will never fail once and then refuse to do FaceID.
If you can't figure out to lift the sunglasses off your face or sit up in bed for a second, that's not anyone's fault but your own.
Also, FaceID will never fall back to your account password for Apple Wallet transactions with a physical credit card reader.
Are you sure you have enabled TouchID for purchases (Settings > Touch ID & Password)? If you don't, I guess it might prompt for passwords. I just need to authenticate once on restart but can pretty much use TouchID almost all the time after that anywhere auth is expected.
I have on mine, and yes it always prompts for a password anyways if I haven't used the App Store extremely recently (like within the past 24 hours).
I'd assume it's a straight-up bug on Apple's part, but they haven't fixed it for years and years, so at this point I think they're just being sadistic.
Because yes TouchID works everywhere else. This is App Store-specific. It's literally the only reason I keep a password manager app on my home screen, since it autofills everywhere else but not there so I have to always copy my Apple password manually from the password manager app.
Also, every time I plug my iPhone into my Mac for syncing it asks "Trust this Device" both the Mac and the iPhone. I click "yes" and yet it asks again next time.
Help yourself to the system setting "Privacy & Security -> Allow accessories to connect". The sane default is "ask every time", and you probably want "ask for new accessories".
I'm not surprised that it occasionally prompts for a password (about once or twice a week for me), because otherwise people will forget their passwords and bug them about it.
The problem I have is that it doesn't explain who wants the password or why, and the prompts aren't associated with any particular action on my part. Instead, Apple is conditioning people to mindlessly type in their password on demand. Why in the world are they doing a stupid, dangerous, counterproductive thing like that?
People are supposed to have extremely complicated passwords, which are impossible to remember. The security is in your biometric ID. There is no reason for a person to ever have to remember any password except their login password, as long as they are using a device with biometric ID. And as far as I know, almost all Apple devices currently for sale have biometric ID.
iCloud is the only login that regularly breaks biometric ID functionality, and it's super annoying.
I have a very old iPad that my kid uses. It’s stuck to iOS 10.3. Also, it can’t use my password manager. The browser is so old that the website won’t load (32-bit app). And the PW manager app isn’t made for this old a device.
So Apple wants me to type in my 50+ character password every time I use the App Store app. It’s such a pain.
Then why'd you pick a 50+ character password? No one made you do that. That's your fault, not Apple's.
- As you said, it's a multi-platform account, so probably multiple devices in multiple locations will need the password. Meaning you won't have easy access to your password manager.
- Popular account, so you'll likely be using it often, probably re-typing or pasting it.
Common sense says that manually typing out a password was a likely scenario.
Switch to a phrase-based password. It'll still be really secure, and you'll be freed from your self-inflicted woes.
The various stores use their own biometric auth (the abstraction over touch ID and face ID) settings, which can cause this based on user config, particularly if you're using family accounts of any kind.
The most likely issue is one of these is set to ask every time as many families that share devices with kids consider that a feature, not a bug.
If all possible places are set to accept biometric ID (there's always one more setting than you think to check), it can be something about your network or device itself, particularly if for some reason you show up as if rotating through random geographies or from "unknown" devices.
Modern-ish auth systems (e.g., authentication mechanisms for Google, Microsoft, and Apple) also have a "risk based authentication" ratchet that re-prompts if enough data points are abnormal. Depending on your level of access to admin panels, you may be able to identify what is flagging to re-prompt.
Usually this sort of thing can be traced to something like a per-request VPN with no geographic affinity option, or an ISP (especially mobile ISP) that exits you from random cities across border lines.
I don't have a problem with reauth if the action(s) in question requires a sudo-like operation with a time-out window. It's just a matter of grouping such actions together in manner that requires the least amount of reauth prompts.
At least for Apple I can see this being a way to avoid account lock out. Your Apple ID password would otherwise almost never be used so when people finally go to factory reset their device or something they would realise they long since forgot their password and now have an expensive brick.
I think free apps are still scrutinized because they don’t want attackers to install known-compromised apps or trackers. Like a controlling spouse sneakily face IDing a sketchier Life360 while “making a phone call”.
Could be wrong, but that’s the only thing I can think of.
For sure. They don't really need to protect your credit card in that way, since if a silly kid bought $300 worth of Super Gems or installed a paid app (are there even any normal paid apps now?) Apple has full control, if you call support, to just say "nope" and take the money back and refund you. But sneaking any random app onto the phone of someone else for nefarious reasons is something Apple is super paranoid about.
Which is also why I will get random popups every few weeks for the rest of my life saying things like "Google Maps has been using your location for 179 days." with a "scary" little map of where I've been. No amount of saying "yes, i meant to do that" can convince Apple that it's intentional.
Indeed. And I have several Apple mobile devices around the house that just decide they need the password entered just for general reasons, without any specific triggering action! And those pop up modal dialogs in front of what you're doing (super dangerously, as that teaches users that it's plausible that they might be on the Web, and get a popup asking them to enter a password, that they should click on to lead them to a password-entering place!)
The extreme security of iCloud accounts is good, given that iMessage, photos, etc. are all in there. The need to re-authenticate your iCloud account to purchase $0.99 app is eyebrow-raising but understandable. But the need to 2FA to download a free app is insane.
I wonder if what you're seeing is geographic. I'm in Scandinavia and authentication lasts a decent while for me, with strict settings. I tried a few things with my SO's iPhone and iPad and they behaved the same.
It's because an average Apple engineer has to enter his password at least 10 times a day and it's kind of no big deal for them. Source: I was an Apple eng.
this is only because of all the lawsuits about apple store chargebacks because they allowed kids to make purchases.
article is shot Enterprise software and you're talking about games and predatory dark patterns in consumer devices. or do you company distribute software to employees via app store?
> it keeps prompting for the Apple password again and again
pro tip (for mac desktop, not iphone): drag the dumb prompt off to the edge of the screen ( i drag from top left of the window and drop it to the bottom right of the monitor )
it will not give a 2nd prompt if the first prompt is closed
=> i do this specifically when the 'apple accounts' crap has some issue and forever prompts me to re-login.
Also, on both macOS and Android, there's a time component to device unlocking. You would sometimes get this stupid "your password is required to enable touch ID" or "extra security required, pattern not used in a while" thing with no way to disable it. It's beyond infuriating to me. It's my device. It should not tell me what to do. I get to tell it what to do and it obeys, unquestionably. I'll evaluate my own risks, thank you very much.
The people who need to read these articles are the auditors. Until they change their expectations, the many businesses who have to pass audits are still going to be stuck doing a lot of things that are industry-standard but also very stupid. This is the case even for small businesses in certain fields where security audits are valued. We have at least half a dozen measures in place that we know aren't actually helpful but we also know auditors won't budge on right now.
Makes sense. The thing people forget about SOC2 is that it's very not-technical and very much so written by CPA's. No two SOC2's are identical. Hell the same companies SOC2 done by different auditors will be different.
Saying "The United States of America National Institute of Standards and Technology says X on page 423 of Special Publication 800-53 revision 5" is a really awesome "We're doing things the RIGHT way".
No, you’re right. Though I think there’s definitely a gap between standards bodies like NIST and the AICPA or whoever sets the SOC2 standards these days. I think some of the answer is just momentum. Customers have come to expect it of their vendors, specifically because it is security theatre, something they can point to if anything goes wrong.
Came here to say this, upvoted. Both Apple and Microsoft have "corporate IT" settings that can be used to turn off "trust my device", "remember me", etc. Auditors and CISO offices tend to lean in on checklist security - in other words it doesn't matter if it's actually more secure, it only matters that it passes the checklist audit. Many of the settings are user hostile and incentivize users to work around them. Making real security worse of course...
I’m not sure how one changes the mind of auditors who are just there for a job and who aren’t actually interested in the field? IME, the only auditors who are knowledgeable are those overseeing the folks with checklists — and they rarely seem to have the time to correct the folks they’re overseeing.
It seems like the problem here isn't the use of checklists, it's that the checklists in question contain questionable stuff like "enforce frequent reauth". Systematically checking for the presence of good things and the absence of bad things seems like a good idea both from a security and consistency perspective. Of course the trick is making sure your "good" and "bad" lists are well thought out and appropriately applied.
Something related that's barely touched in the post:
Bad UX is potential security vulnerability. If your system behaves in unreasonable ways, users are much less likely to notice when it behaves in a slightly different unreasonable way, this time because of a spoofing/phishing, etc.
The obvious example: if your system frequently asks for passwords, re-entering passwords becomes a habit (read system one from "thinking fast and slow"), and the user is less likely to use judgement each time they enter the password.
But also, if an OS makes it hard to find all startup applications, allows untrusted code to run in the background without any visible signs, allows terminal code to access all local files by default, etc etc these all can be abused.
One problem is that human psychology is rarely considered as important a factor as it should be by the average security expert. The other is the usual suspect: incentives. The right chain of responsibilities is missing when things go wrong for people because of mistakes that would be avoidable by proper product design.
Regulation should enforce that, but while everyone would benefit from regulation, no one likes the regulation that will regulate the product/services they offer, and the supplier has upper hand when a change in regulation is being considered because they are focused and motivated.
This is a great take! Similarly, I've seen shadow IT and sneaky work around type stuff crop up a lot before because the "official" way of doing something has picked up too much friction.
Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.
You only have to do that if you must validate a token, without having access to session data.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
This is an implementation detail in my opinion. There are cases where having the capability to force a refresh is desired. There are also cases where you want to be able to lock out a specific session/user/device. YMMV, do what makes sense for your business/context/threat model.
This is really just an optimization. It means that you don't need to do an expiry check on the regular token, only on the refresh token. It doesn't change the fact that you should be able to revoke a session before it naturally expires.
Frequent reauth only makes people figure out hacks to work around it.
Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works
Because much of what passes as "security" is a bunch of theater.
> SMS gets forwarded to e-mail, TOTP codes get sent over Wechat,
Here we are deep into 2FA land. Where you have institutions blocking SMS/MMS to IP telephony because they want to capture real people (and this locks out rural customers). Using your cell phone was never a suitable 2nd factor and now it is evolving into a check to make sure you're not a robot/script.
Passkeys are adding another layer to this... The police department getting a court order and forcing you to unlock your phone and then everything else is coming. Or here if you live in some place with fewer laws.
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
You say users don’t notice much of this - I disagree. I had to authenticate with our SSO provider 9 times yesterday (I started counting because it’s getting so frustrating). All on the same device; once on initial login, once on VPN connect, once to the SSO dashboard, twice (!) to Microsoft for Outlook and Azure access via our IDP, once for perforce (no 2FA required thankfully) and three times to Jenkins because it doesn’t remember the OIDC token if you close your browser. IT say it’s normal and here I am spending 10 minutes a day waiting for my Authenticator app to log in.
I work on a corporate controlled machine, with a corporate VPN app and custom certificates installed. I’m pretty sure it knows when I sneeze, but yet remembering who I am for more than 15 minutes seems out of scope.
It's a balancing act. The more annoying your auth requirements are, the more likely users are to look for insecure shortcuts that make using their computer less miserable.
Now that most OSes can unlock with just a fingerprint or face,
there's no reason to leave your screen unlocked when you walk away.
This statement seems to be unaware that workstations are a thing. In 30 years of onsite support, I think I've seen one desktop PC with a fingerprint scanner.
Cameras aren't ubiquitous either. Across the 5 locations I currently service, less than 2 percent of desktop PCs have a camera.
Past that, I believe there is a secondary challenge with face scanning; it's the unsettlement factor. I suggest that discomfort with face scanning is reasonable and earned.
The reason: We're constantly subject to face scanning that is non-consensual, intentionally hidden from us and is probably exploitative. Cams also enable snoopy bosses, school admins, corps, LEO and Govs to endlessly peer where they should not.
And even where we own our devices, we don't fully control them. Software corps have no ethical boundaries. Any assumptions that they'll respect us - at all - isn't based on reality or history.
If an organization wants fingerprint scanners, they just have to provide them. It's about $15-50 per workstation, if desired. The main problem is they use up an increasingly scarce USB port. Some scanners also rely more on security by obscurity rather than protecting the channel. https://www.google.com/search?q=windows%20hello%20fingerprin...
It would be worth doing research to find the best fingerprint scanner that implements this well.
Face scanning is a poor solution because desktops usually do not have Hello-compatible scanners and the scanners on the Windows laptops aren't very good. They frustrate users who prefer darkened rooms or who sit in places with varying contrast from the windows. It is also weird the way the camera is constantly trying to find you, and so it blinks its red LED frequently until the computer goes to sleep.
Just really agreeing with you on security keys, but we also have to make sure they are really secure. Also, like the article says, they give you the device possession part, but not the user ID part, unless they have a biometric device built in.
> The main problem is they use up an increasingly scarce USB port.
This logic I do not understand. USB hubs exist and are more-or-less commodity parts these days. [0]
I'd be surprised if the fingerprint reader was anything faster than USB 2.0, and deeply offended if the reader did anything other than idle on the bus when it's not being used... so you're not going to be suffering any real bandwidth contention by putting that guy and a USB 3.x device on the same hub.
[0] They're also usually how motherboards that have a whole bunch of USB ports hook those ports into the onboard USB controller(s). (Do folks usually think that every one of the 10gbit/s ports on one's desktop machine could be simultaneously run at 10gbit/s?)
A client of mine has a 30 min timeout on basically all their systems. I hate using Jira as it is, but having to login pretty much every time I need to go look at my tickets just makes it awful. And then I end up on Hacker News instead of doing actual work.
Industry-wide IT security is driven by the "nobody got fired for buying IBM" phenomenon.
It doesn't matter if things are broken. It matters that you did everything by the book. And the book in this case was written 30 years ago and is woefully inadequate. But try convincing your VP of information security that employees shouldn't have to change their password every 3 months...
Readit News
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
https://pages.nist.gov/800-63-3/sp800-63b.html
Or by Microsoft
> Password expiration requirements do more harm than good...
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/p...
But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).
It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach.
Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!
and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.
"Why did this stupid shit happen? Oh, it's money again."
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.
Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.
If a site owner knows that certain accounts are part of a database breach or something, a reasonable step would be to force the users to change the password at next login.
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
They refused to establish MFA or passkeys - and instead insist that "NIST is the minimum recommendation for cybersecurity... and we take cybersecurity very seriously... to ensure the safety and security of the citizens... therefore we will not change our policy on mandatory account lockouts or password change requirements."
Often when people say this, they are parroting their assessor. But not every assessor graduated at the top of their class, or cares to stay updated, or believes that they know better, etc.
In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.
In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.
This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).
A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.
And then you have trauma that will say "we cannot change the password because we don't know where it is used".
Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.
This is a better use of the finite practical appetite for complying with policies than the idiotic "forcibly change it every 90 days" + "Your 8 character password needs to have at least one number, one uppercase, and one of these specific 8 characters: `! @ # $ % ^ & *`"
By the way, to quote Old Biff Tannen, "oh, you don't have a safe. GET A SAFE!"
Sometimes you just cant convince people that something is no longer recommended.
thankfully my current company let me keep my password for the last 3 years
That is extremely annoying.
On the other hand if I was a manager and that happened to someone I managed we'd definitely have a conversation where I would acknowledge that forced password rotation is idiotic, but also point out that our password expiration is 90 days after the most recent change, which is 12 weeks and 6 days, and ask how come they don't have a "deal with stupid password expiration" event on their calendar set to repeat every 11 weeks?
That gives them 13 days warning. Vacations can be longer than 13 days, but I'd expect that when people are scheduling vacations they would check their calendar and make arrangements to deal with any events that occur when they won't be available. In this case dealing with it would mean changing the password before their vacation starts.
I don't expect people to go all in on some fancy "Getting Things Done" or similar system, but surely it is not unreasonable to expect people to use a simple calendar for things like this?
Dead Comment
Dead Comment
Another hot take, calling them passwords instead of pass phrases was a mistake.
People have no problem making a secure pass phrase like 'apophis is coming in 2029’.
It uses special chars and numbers, but some websites would reject it for spaces and some for being too long.
I say these are hot takes despite aligning with NIST because I've never seen a company align with them.
It only makes sense in HTTP basicauth and other system that keep plaintext passwords.
On my mac, I setup my touch ID, and log in to my Apple account on the App Store. Time and again, when I try to install apps, it keeps repeatedly prompting for my password, instead of letting me just use my touchID. This applies to free apps as well, which is again silly beyond what is already enough silliness.
I briefly see this on my spouse's iPhone as well. Almost felt like Apple hasn't changed a bit after all these years. It keeps fucking prompting for password over and over, randomly when installing apps. although the phone is secured with a touch ID. This happens especially when you reset the phone and starting from scratch - it keeps prompting for the Apple password again and again.
Another pointless annoyance - if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password. Why?? And of course when you're on that prompt there's no way to open your password manager without cancelling out of it entirely. Makes for a fun experience at the checkout counter...
What? FaceID will prompt for a re-try. Always. It will never fail once and then refuse to do FaceID.
If you can't figure out to lift the sunglasses off your face or sit up in bed for a second, that's not anyone's fault but your own.
Also, FaceID will never fall back to your account password for Apple Wallet transactions with a physical credit card reader.
I'd assume it's a straight-up bug on Apple's part, but they haven't fixed it for years and years, so at this point I think they're just being sadistic.
Because yes TouchID works everywhere else. This is App Store-specific. It's literally the only reason I keep a password manager app on my home screen, since it autofills everywhere else but not there so I have to always copy my Apple password manually from the password manager app.
Unless it's related to advertising. Then it works flawlessly and sometimes survives device transfers and factory resets.
The problem I have is that it doesn't explain who wants the password or why, and the prompts aren't associated with any particular action on my part. Instead, Apple is conditioning people to mindlessly type in their password on demand. Why in the world are they doing a stupid, dangerous, counterproductive thing like that?
iCloud is the only login that regularly breaks biometric ID functionality, and it's super annoying.
Deleted Comment
So Apple wants me to type in my 50+ character password every time I use the App Store app. It’s such a pain.
- As you said, it's a multi-platform account, so probably multiple devices in multiple locations will need the password. Meaning you won't have easy access to your password manager. - Popular account, so you'll likely be using it often, probably re-typing or pasting it.
Common sense says that manually typing out a password was a likely scenario.
Switch to a phrase-based password. It'll still be really secure, and you'll be freed from your self-inflicted woes.
The various stores use their own biometric auth (the abstraction over touch ID and face ID) settings, which can cause this based on user config, particularly if you're using family accounts of any kind.
The most likely issue is one of these is set to ask every time as many families that share devices with kids consider that a feature, not a bug.
If all possible places are set to accept biometric ID (there's always one more setting than you think to check), it can be something about your network or device itself, particularly if for some reason you show up as if rotating through random geographies or from "unknown" devices.
Modern-ish auth systems (e.g., authentication mechanisms for Google, Microsoft, and Apple) also have a "risk based authentication" ratchet that re-prompts if enough data points are abnormal. Depending on your level of access to admin panels, you may be able to identify what is flagging to re-prompt.
Usually this sort of thing can be traced to something like a per-request VPN with no geographic affinity option, or an ISP (especially mobile ISP) that exits you from random cities across border lines.
I do not run into this at all across my apple products.
Same with the forced emails you get ANYTIME you login to iCloud via web.
Could be wrong, but that’s the only thing I can think of.
Which is also why I will get random popups every few weeks for the rest of my life saying things like "Google Maps has been using your location for 179 days." with a "scary" little map of where I've been. No amount of saying "yes, i meant to do that" can convince Apple that it's intentional.
The Mac pops those up too, now. Utter insanity.
How is this a thing?!
I use TouchID to log in several times per day, and am required to enter a password "to enable TouchID" about once per week. iOS and macOS both.
This feels reasonable to me.
article is shot Enterprise software and you're talking about games and predatory dark patterns in consumer devices. or do you company distribute software to employees via app store?
pro tip (for mac desktop, not iphone): drag the dumb prompt off to the edge of the screen ( i drag from top left of the window and drop it to the bottom right of the monitor )
it will not give a 2nd prompt if the first prompt is closed
=> i do this specifically when the 'apple accounts' crap has some issue and forever prompts me to re-login.
edit: clearification
It seems like insane friction for something that is making them a lot of money
Dead Comment
> It's my device.
There is your dissonance.
Saying "The United States of America National Institute of Standards and Technology says X on page 423 of Special Publication 800-53 revision 5" is a really awesome "We're doing things the RIGHT way".
It seems like none wants to actually justify their decisions to auditors as its more time critical when the audit happens.
I'd say you want to send these articles to the people writing such guidelines.
What am I missing?
Bad UX is potential security vulnerability. If your system behaves in unreasonable ways, users are much less likely to notice when it behaves in a slightly different unreasonable way, this time because of a spoofing/phishing, etc.
The obvious example: if your system frequently asks for passwords, re-entering passwords becomes a habit (read system one from "thinking fast and slow"), and the user is less likely to use judgement each time they enter the password.
But also, if an OS makes it hard to find all startup applications, allows untrusted code to run in the background without any visible signs, allows terminal code to access all local files by default, etc etc these all can be abused.
One problem is that human psychology is rarely considered as important a factor as it should be by the average security expert. The other is the usual suspect: incentives. The right chain of responsibilities is missing when things go wrong for people because of mistakes that would be avoidable by proper product design.
Regulation should enforce that, but while everyone would benefit from regulation, no one likes the regulation that will regulate the product/services they offer, and the supplier has upper hand when a change in regulation is being considered because they are focused and motivated.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
Dead Comment
Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works
> SMS gets forwarded to e-mail, TOTP codes get sent over Wechat,
Here we are deep into 2FA land. Where you have institutions blocking SMS/MMS to IP telephony because they want to capture real people (and this locks out rural customers). Using your cell phone was never a suitable 2nd factor and now it is evolving into a check to make sure you're not a robot/script.
Passkeys are adding another layer to this... The police department getting a court order and forcing you to unlock your phone and then everything else is coming. Or here if you live in some place with fewer laws.
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
Deleted Comment
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
I work on a corporate controlled machine, with a corporate VPN app and custom certificates installed. I’m pretty sure it knows when I sneeze, but yet remembering who I am for more than 15 minutes seems out of scope.
Cameras aren't ubiquitous either. Across the 5 locations I currently service, less than 2 percent of desktop PCs have a camera.
Past that, I believe there is a secondary challenge with face scanning; it's the unsettlement factor. I suggest that discomfort with face scanning is reasonable and earned.
The reason: We're constantly subject to face scanning that is non-consensual, intentionally hidden from us and is probably exploitative. Cams also enable snoopy bosses, school admins, corps, LEO and Govs to endlessly peer where they should not.
And even where we own our devices, we don't fully control them. Software corps have no ethical boundaries. Any assumptions that they'll respect us - at all - isn't based on reality or history.
For workstations, I like security keys.
It would be worth doing research to find the best fingerprint scanner that implements this well.
Face scanning is a poor solution because desktops usually do not have Hello-compatible scanners and the scanners on the Windows laptops aren't very good. They frustrate users who prefer darkened rooms or who sit in places with varying contrast from the windows. It is also weird the way the camera is constantly trying to find you, and so it blinks its red LED frequently until the computer goes to sleep.
Just really agreeing with you on security keys, but we also have to make sure they are really secure. Also, like the article says, they give you the device possession part, but not the user ID part, unless they have a biometric device built in.
This logic I do not understand. USB hubs exist and are more-or-less commodity parts these days. [0]
I'd be surprised if the fingerprint reader was anything faster than USB 2.0, and deeply offended if the reader did anything other than idle on the bus when it's not being used... so you're not going to be suffering any real bandwidth contention by putting that guy and a USB 3.x device on the same hub.
[0] They're also usually how motherboards that have a whole bunch of USB ports hook those ports into the onboard USB controller(s). (Do folks usually think that every one of the 10gbit/s ports on one's desktop machine could be simultaneously run at 10gbit/s?)
Fortunately these days most services will cache your work.
It doesn't matter if things are broken. It matters that you did everything by the book. And the book in this case was written 30 years ago and is woefully inadequate. But try convincing your VP of information security that employees shouldn't have to change their password every 3 months...