[HN Gopher] Study: 'Security Fatigue' May Weaken Digital Defenses
___________________________________________________________________
Study: 'Security Fatigue' May Weaken Digital Defenses
Author : giuliomagnifico
Score : 79 points
Date : 2026-03-23 14:36 UTC (8 hours ago)
(HTM) web link (www.albany.edu)
(TXT) w3m dump (www.albany.edu)
| dijit wrote:
| thats part of why NIST updated their password rotation
| recommendations from 90 days to indefinite: people pay lip
| service to security if it is too inconvenient. you have to try to
| meet people where they are.
|
| Preaching is not a strong motivator for long.
| carefree-bob wrote:
| It's not just about "convenience", it is hard for the human
| mind to remember a truly random password. You can try all the
| mnemonic tricks you want but at the end of the day it requires
| a lot of time and repetition before entering the password is
| effortless. So what people do is create a stream of derivable
| passwords. For example, I can think of a phrase "I love beach
| balls bouncing on the ocean!" and then make a password
| "ilBBbotocean!" and when it comes time to change that password,
| I'll just add a number "ilBBbotocean!1". Studies have shown
| this is what people do. But it is easy for attackers to also
| derive these passwords once one password in the chain has been
| compromised.
|
| The effect of that is that by requiring frequent rotation, the
| organization is effectively training their users to have a
| single permanent password and to _never change it_ , even after
| a compromise. That's extremely harmful. At least with permanent
| passwords that are force rotated after they show up in database
| or there has been an incident, you have a much higher
| percentage of compliance with making new passwords, and the
| organization is safer because everyone isn't using passwords
| derived from the previous password.
| mysteria wrote:
| I remember a case where a company decided to assign employees
| random 16 character passwords with symbols and rotated them
| every 90 days or so. They were unchangeable and the idea was
| that everyone would be forced to use a secure password that
| changed regularly.
|
| You can probably guess what happened, and that was that no
| one remembered their passwords and people wrote it down on
| their pads or sticky notes instead.
| GoblinSlayer wrote:
| Also "app passwords". Not just change, you can't even
| append text to it.
| SAI_Peregrinus wrote:
| Those are just API keys people can type.
| bluGill wrote:
| Writing down a password is a great option. However you need
| to keep that paper in a secure location. Put it in your
| wallet and treat it like a $100 bill - don't paste it to a
| monitor or under the keyboard.
|
| A password manager is better for most things, but you need
| to unlock the password manager somehow.
| mystraline wrote:
| Most federal orgs still have 60 day password rotation
| requirements in place, even though NIST gave guidance almost 10
| years ago not to do that.
|
| What does that mean? Passwords are stored in textiles
| accessible by admin only, and shared. And everyone is worse for
| it.
| Joel_Mckay wrote:
| Mostly, it forces dead accounts off the system, as lay off
| notices are sent the day after.
|
| It is mostly about ensuring some busy admin doesn't have to
| inventory every user permission.
|
| Rotating domain logins form a similar function of booting
| inactive users.
|
| 2FA actually may make a system weaker, as people can MITM for
| $23 using a bogus telecom service and password reset. =3
| MengerSponge wrote:
| SMS 2FA is harmful. Fortunately, other 2FA modalities are
| susceptible to that MITM attack
| nvgrw wrote:
| Every time I log into the FTB (CA tax authority) website I have
| to set a new password. I wish there were some affirmative
| guidance to stop doing this because at the moment governments
| still think forcing password changes makes it "safer".
| dragonwriter wrote:
| > I wish there were some affirmative guidance to stop doing
| this because at the moment governments still think forcing
| password changes makes it "safer".
|
| NIST SP 800-63B-4 [0] seems to be pretty clear "affirmative
| guidance", though its only actually legally _required_ in
| certain circumstances.
|
| [0] @ 3.1.1.2: "[...] Verifiers and CSPs SHALL NOT require
| subscribers to change passwords periodically. However,
| verifiers SHALL force a change if there is evidence that the
| authenticator has been compromised. [...]"
| compiler-guy wrote:
| I have seen this phenomenon especially at a couple of FAANGs over
| the past couple of years. Things are getting locked down so much,
| and so many special permissions are required that now people ask
| for permissions to systems or procedures preemptively. Because by
| the time they know if they will need it or not, it's too late.
|
| And no one in the security business seems to consider the overall
| burden of yet another step. Each of which is simple in by itself,
| but cumulatively they are a giant hassle, and so people look for
| workarounds.
| baby_souffle wrote:
| > And no one in the security business seems to consider the
| overall burden of yet another step. Each of which is simple in
| by itself, but cumulatively they are a giant hassle, and so
| people look for workarounds.
|
| This is a tale as old as time. At a prior gig, IT took away
| touch ID for ... $reasons. ~40% of the engineering team was
| already big into mechanical keyboards so it only took one
| person to "just FYI, VIA allows you to program macros". Is it
| _as bad_ as password on a sticky note? Not quite but I can't
| imagine that touch ID was _more_ of a threat.
| sam_lowry_ wrote:
| A big use case for Yubikeys is the ability to emulate a
| keyboard and produce a string of chars on touch.
| pimlottc wrote:
| It's a very handy fea-
| ccccccvklhfgjhckcnkdnhgkcdgbruuhlfbuednrjgjr-ture
| Groxx wrote:
| gesundheit
| HPsquared wrote:
| It can be a little touchy.hunter2
| MengerSponge wrote:
| Why'd you just type a bunch of asterisks?
| baby_souffle wrote:
| You all have made me realize that bash.org is no longer
| around. Thanks for the trip down memory lane :)
| dizhn wrote:
| My pet peeves. One of the top 5 was fake. It had a typo
| in the server message.
| arcfour wrote:
| You know what's funny is that, at least by default, these
| strings have some information in them that tells you the
| serial number and model of the key, among other things.
| klooney wrote:
| Until the security team requires a password on the yubikey
| tap
| JasperNoboxdev wrote:
| Curious, why remove Touch ID? Been moving everything into it
| seems like a really good mix of convenience + security
| (especially if the alternative is copying your key into AI :)
| )
| whynotmaybe wrote:
| Not really new. A long time ago I had to wait 2 months to have
| access to a shared folder on a development server.
|
| It became so prevalent that whenever we were planning anything,
| if a task had to be done by someone outside of our team, we
| added 20 days.
|
| Security through eternity I guess ?
| alexsmirnov wrote:
| Almost instantly, compared to my experience working for a big
| health care provider... I waited 6 moths for IT department to
| allow me install development tools on work laptop.
|
| And while security rules created enormous roadblocks for
| work, whey also left enough holes to be exploited. Before
| getting required permissions, I managed to create dual boot
| with linux and share files between 'approved' and 'illegal'
| systems
| SAI_Peregrinus wrote:
| I call this sort of thing a self-DoS. If the system is unusable
| enough, it's indistinguishable from a DoS attack. This sort of
| sabotage isn't restricted to the security team, anything that
| makes the system unreliable enough from bad design through bad
| performance can have the same effects as an external attack.
| burningChrome wrote:
| >> Things are getting locked down so much, and so many special
| permissions are required that now people ask for permissions to
| systems or procedures preemptively.
|
| Currently dealing with this at our current company. People were
| clamoring for access to various LLM's. They were slow to adopt
| and since we're a huge MS client, we were granted limited
| licenses for copilot. Then more people made waves about getting
| access and they slow walked a ton of licenses until a small
| portion finally had access.
|
| Then came all the other non-MS apps that people wanted to plug
| copilot into (such as Figma) and that was another round of
| frustrations with users here as they locked stuff down, then
| slowly relented.
|
| The company is still struggling with giving access to AI tools
| and LLM's since now the company is _really_ lagging behind many
| other companies who are just running wide open with AI.
|
| We're 100% dealing with what you're saying. EIS has been making
| people jump through so many hoops that every time they add an
| LLM, its completely locked down to just the enterprise network
| and people are getting really frustrated since so many of us
| are already well along using AI at home and elsewhere. Yet here
| our day-to-day stuff using AI is an act of congress to get
| access to the LLM and tools.
| arcfour wrote:
| > And no one in the security business seems to consider the
| overall burden of yet another step. Each of which is simple in
| by itself, but cumulatively they are a giant hassle, and so
| people look for workarounds.
|
| This is certainly not true. I personally consider how much
| friction things introduce for users, things like normalizing
| having to reenter your password too much making phishing
| easier, and so on. It's well understood that you will get
| shadow IT, which is worse, if you make doing things the right
| way too difficult. I regularly advocate for streamlining
| processes and procedures, introducing more user-friendly
| systems, hosting office hours where the security team is
| available for any question or concern you have making us more
| available to the company, etc.
|
| What's the issue? Well, for one, there's a ton of incompetent
| people in the field, so they'll just do whatever to make
| themselves look like they're working. Two, most security
| departments are criminally understaffed, so even if you have
| competent people they just have to put things together quickly
| and can't clean it up. Three, there's tons of idiotic
| regulatory and legal requirements that take forever to
| modernize. And finally, half of security is playing politics
| and arguing with the rest of the company, meaning that half the
| time the solutions you get are a slop of compromise with which
| nobody is happy.
|
| TL;DR we aren't psychopaths without empathy, we struggle for
| the same reasons you developers have tech debt and other things
| that suck even though you would prefer not to.
| gz5 wrote:
| Absolutely. Easier said than done, but the best security is
| structural security - as near to invisible for end users as
| possible. This needs to be the goal, imo, even if not fully
| achievable.
| ctxc wrote:
| Fairly obvious? Or isn't it that way for everyone?
| Lerc wrote:
| Very obvious, but things that seem obvious might not actually
| be true. It is worth verifying.
|
| Getting organisations to act on the obvious if it requires
| changing is harder than you might think. Having research to
| point to and saying you are doing the wrong thing and now
| you've been told is like turning the lights on and off really
| quickly and moaning "Liability" in a spooky voice.
| ctxc wrote:
| Fair enough. I had a hard time advocating for good password
| flows because "standards" said frequent rotation etc.
|
| And tbh when you _apply_ those standards with context and are
| faced with people bare-minimum pointing at the standards, you
| sometimes come off as less knowledgeable - such is the
| authority of research /standards.
|
| Anyway, I skimmed your profile and learnt a new word,
| milquetoast - so thanks for that!
| donatj wrote:
| The level of lockdown in current years is wild. With our 2FA
| requirements and SSO, signing into GitHub every morning takes me
| something like eight clicks and a solid minute. Everything has
| gotten so locked down in recent years, people are working so hard
| to protect what are largely basic CRUD apps
| jimbokun wrote:
| That's fine as long as you are kept logged in or at least have
| an abbreviated login process after successfully authenticating
| in the morning.
|
| CRUD apps can contain very sensitive data, so not sure how
| that's relevant.
| donatj wrote:
| I'm all for protecting the data with my life, but there's
| increasingly little value in the code around a CRUD app,
| which is what we're keeping in GitHub.
| magicalhippo wrote:
| Would have been less if GitHub had just allowed proper SSO
| instead of this hybrid account mixing.
|
| I get that the hybrid method might be desirable for contractors
| or similar who have many hats, but for a regular employee it
| just adds friction for no benefit.
| nightpool wrote:
| I've never had that issue with Github--I think their account
| mixing setup reduces the amount of work I have to do to sign
| in 100x compared to other SSO systems I use.
| magicalhippo wrote:
| You must have used some weird other SSO systems is the only
| explanation I have.
|
| GitHub has all the normal SSO stuff as anything else we
| use, but on top of the GitHub-specific account login.
| Everywhere else I just log in via SSO, in GitHub I log in
| first to GitHub (with its own MFA) and _then_ the same SSO
| step as anywhere else.
| nightpool wrote:
| I've never had to log in to Github as part of my daily
| flow. Only once to set up a new computer. Are you logging
| in using an incognito window or something?
| magicalhippo wrote:
| Interesting. Perhaps it's because I'm not using GitHub
| daily, we're migrating to GitHub so I still do work in
| repos which live in the old system. Also, perhaps I'm
| more affected because I'm doing org admin stuff as well.
| languagehacker wrote:
| Nice to see SUNY Albany on here!
| onetimeusename wrote:
| I think security became part of compliance so security
| recommendations got detached from actual security. It seems like
| a lot of security recommendations are just busy work that
| justifies having a huge compliance industry. So an example of
| this might be security scanners for code where the output is not
| even useful. But using the tool, which searches for irrelevant
| findings, is required for compliance even if it basically does
| nothing for security.
| GoblinSlayer wrote:
| Who watches the compliance industry?
| Joel_Mckay wrote:
| This guy =3
|
| https://www.youtube.com/watch?v=T4Upf_B9RLQ
| general_reveal wrote:
| Just get off as many of these platform as you can. That's about
| the only security that you'll ever get. If you are still in the
| Matrix, listen the weirdos on here that take "don't trust
| anything" seriously to the point of absurdity.
|
| The Matrix was not fiction. Our modern internet _is_ a system.
| You have to figure out how to live truly free from it, because it
| absolutely owns you.
|
| __
|
| _Revelation 13:16-17
|
| "And he causeth all, both small and great, rich and poor, free
| and bond, to receive a mark in their right hand, or in their
| foreheads: And that no man might buy or sell, save he that had
| the mark..." _
| nathan_compton wrote:
| The number of times I have to "single sign on" is truly
| maddening.
| HansHamster wrote:
| At least you can tick the "stay signed in" checkbox and... get
| kicked out a few hours later with a smug "you successfully
| signed out" message.
| scuff3d wrote:
| Was talking with someone about this yesterday. From cold start,
| for me to get to the VM I do my actual work on I have to
|
| 1. Enter a password to decrypt the computer
|
| 2. Enter a username and password to log into my account
|
| 3. Enter another set of credentials to access the corporate VPN
|
| 4. Enter another username and password to access the network the
| VM is on
|
| 5. Enter another username and password to get to the actual
| machine
|
| 6. And then navigate a nest of authorization for docker/git/etc
| to actually do anything useful
| BoneShard wrote:
| Amateurs. Where is a JIT portal - to raise a ticket in order to
| access prod VMs?
| kotaKat wrote:
| At some point I need to ask Corporate IT for my justification
| logs for every elevation request. I'm certainly sure I've
| submitted at least a couple hundred "because I said so"s and at
| least three Bee Movie scripts.
| kstenerud wrote:
| And now we're at the threshold of the next level of security
| fatigue: permission fatigue.
|
| It's shocking how little people are paying attention to this
| upcoming security nightmare. It wouldn't take much for a bad
| actor to poison an AI session to wait for you to start selecting
| yes, yes, yes and then slip in something bad.
| randusername wrote:
| This is a much bigger problem than just security.
|
| Incidents are inevitable at scale, but risk management at scale
| is an append-only operation that eventually becomes so complex
| and suffocating the only recourse is noncompliance.
|
| Even going to the doctor I find myself pleading with the staff to
| just let me see my PCP instead of going through the full process.
| It takes 30 minutes now to get through the opening interrogation
| about overseas travel, human trafficking, vaccine awareness,
| anxiety and depression panels, domestic violence questions,
| multi-part questions about recent falls, and everything else that
| they keep tacking on. Usually in triplicate, waiting room forms,
| questions from the nurse, questions from the doctor.
|
| And I know behind each of these individual decisions there is a
| horror story or someone proactively trying to prevent one, but
| altogether they create their own.
| lloydatkinson wrote:
| Who could have guess bombarding users with 2FA, 3FA, MFA requests
| to their phone 20 times a day would cause fatigue!
|
| Some personal highlights spread across multiple jobs:
|
| - IT decided they'd make some awful SharePoint page the browser
| homepage for Chrome via group policy. That page required you to
| login to your Microsoft account. If it was a Monday morning you'd
| have to authenticate via SMS just to see your homepage, or, what
| I did usually was ignore it. Every time I opened a new browser
| tab I'd get a new SMS. This went on for weeks at a time, maybe 50
| SMS per day, out of spite. Eventually they disabled that crap.
| Anyone that deals with Microsoft logins knows that "Remember me"
| is almost totally a fake option that does nothing on purpose. [1]
|
| - VPN that requires logging into your Microsoft account, which
| then sends you a notification to Microsoft Authenticator app,
| which requires a face scan, followed by typing in a code,
| followed by another face scan. At no point in the design process
| of that did someone think typing the code was redundant.
|
| - Despite being a software engineer, able to produce executable
| binaries at will, which all seem to be trusted by our security
| software, I still need to talk to IT maybe 5 times a month to get
| <very popular well known widespread development tool> approved by
| the security software.
|
| - Bonus points for the previous one, I often need to manually
| provide the exact DLL's used by the above. Every update means new
| file hashes, meaning repeating it all over again.
|
| - Local admin rights to my work machine and yet for whatever
| reason IT make us type a password to open Windows Task Manager.
|
| - Telling us all they have bought Copilot licenses we should use,
| only for IT to ring you almost immediately after using it because
| their corpo-garbage firewall starts throwing a fit about
| Copilot's requests to github.com, despite us already using
| GitHub.
|
| [1]: https://www.bbc.com/future/article/20150415-the-buttons-
| that...
| GoblinSlayer wrote:
| > approved by the security software.
|
| lol, had this moment with netcat (because it can be used by
| haxorz!111)
| charlieboardman wrote:
| My Steam password is one short weird phrase that I can remember.
| I haven't changed it since high school, ~15 years ago. Never had
| any security issues.
|
| The modern landscape is frustrating because that setup actually
| works. Passwords, from a technical perspective, are actually
| great and are are bulletproof as long as they don't leak. No 2FA
| required. The entire issue is data leaks and phishing.
___________________________________________________________________
(page generated 2026-03-23 23:01 UTC)