[HN Gopher] Frequent reauth doesn't make you more secure
___________________________________________________________________
Frequent reauth doesn't make you more secure
Author : ingve
Score : 1127 points
Date : 2025-06-12 19:05 UTC (1 days ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| hacker_homie wrote:
| But it is easier to implement and maintain so it will continue to
| be the default.
| lapcat wrote:
| OMG I wish that someone would tell this to Apple.
|
| Apple's developer services, such as App Store Connect, actually
| use _session_ cookies. It 's infuriating.
| andrewmcwatters wrote:
| Uh, session cookies being one of the most fundamental pieces of
| authentication tech, there's nothing wrong with them. This is
| like saying, "example.com actually uses _HTTPS._ It 's
| infuriating."
|
| Do you mean that you have to reauth across domains? Those still
| use session cookies.
|
| Edit: I'm dating myself here, but as far as I can tell
| apparently sometime between 2010 and 2011, developers started
| referring to session cookies as cookies with the lifetime of a
| browser session and not to cookies which contain session data.
|
| If anyone can correct me on that timeline, I'd appreciate it.
| Sorry for the confusion in my comment.
| paxys wrote:
| No, sites use _persistent cookies_ , which remain on your
| browser after you have closed the tab. Session cookies are
| wiped out automatically after every session.
| koakuma-chan wrote:
| I set my browser to clear cookies on exit so that my
| cookies cannot be stolen by malware.
| dylan604 wrote:
| how often are you exiting though?
| koakuma-chan wrote:
| Every day
| paxys wrote:
| Why do you think malware can't steal your cookies when
| the browser is open (and I assume it is open for most of
| the day)?
| koakuma-chan wrote:
| Because (at least less sophisticated) malware just steals
| your browser files which contain cookies. I am assuming
| of course the browser is smart enough not to write
| cookies to disk if I set it to clear cookies on exit.
| ffsm8 wrote:
| I think some developers will interpret the term "session
| cookie" differently then that, because a "session" is
| usually just something that's tracked in a backend, and an
| identifier for this session is often written in a cookie
|
| Hence... Session cookie, even if set without expiration
| date
| thaumasiotes wrote:
| Session cookies are cookies that identify a session. They
| last however long you specify. A bank forces quick session
| expiry. Amazon doesn't.
|
| Compare
| https://docs.djangoproject.com/en/5.2/topics/http/sessions/
| .
|
| > To use cookies-based sessions, set the SESSION_ENGINE
| setting to
| "django.contrib.sessions.backends.signed_cookies".
|
| > When using the cookies backend the session data can be
| read by the client.
|
| > A MAC (Message Authentication Code) is used to protect
| the data against changes by the client, so that the session
| data will be invalidated when being tampered with. The same
| invalidation happens if the client storing the cookie (e.g.
| your user's browser) can't store all of the session cookie
| and drops data.
| jadamson wrote:
| No, they're not. This terminology is well-established.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Guides/Coo...
| thaumasiotes wrote:
| You can believe what you like, but that won't change what
| people mean by the term "session cookie".
|
| If you try to communicate with other people using that
| definition of "session cookie", your communication will
| fail.
| lcnPylGDnU4H9OF wrote:
| It's just a difference of context. If one is talking
| about their application and they say "session cookie",
| they probably mean "cookie that stores session data". If
| one is talking about different classifications of cookies
| in a browser, GP's definition of "session cookie" is
| correct.
| chowells wrote:
| Note that modern web browsers do not define a session end
| as "when you close your browser" unless you hunt for and
| enable settings to make them do that. Session cookies will
| happily survive a browser restart by default, because
| browser makers know that most users don't consider closing
| their browser to be ending any kind of session.
| voxic11 wrote:
| > Session cookies are temporary data files stored on a user's
| device to maintain a user's session on a website or
| application. They are automatically deleted when the user
| closes their browser or exits the application, unlike
| persistent cookies which can store information across
| sessions.
|
| Most sites do not use session cookies for auth, they use
| persistent cookies.
| cosmic_cheese wrote:
| Google's the one I have the most trouble with in this regard.
| The more things you sign into the worse it gets, seemingly,
| which really sucks if for example you've got a bunch of Android
| test devices and simulators sharing test accounts. A high
| profile example is how on the WAN Show, Linus or Luke always
| get booted out of the show Google Doc and have to sign back in
| at some point during.
| gsa wrote:
| Google is pretty frustrating. I switch between my desktop and
| laptop frequently and sometimes browsers as well. The reauth
| dialog pops up two weeks for every login - usually just when
| I'm about to hop on a meeting.
| clvx wrote:
| This reads like paraphrasing of SPIFFE. I'm down for it but I
| wonder of compromised devices that can figure it out how to keep
| the auth alive (or replicating user behavior). In those cases
| expiration still sounds like a good idea.
| d4mi3n wrote:
| 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.
| the8472 wrote:
| You don't need reauthenticate for that, you just need to renew
| existing tokens. Separate the timeouts for authentication and
| authorization.
| antihero wrote:
| 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.
| kevin_thibedeau wrote:
| That's a great way to interfere with local work when the
| network goes down.
| rafaelmn wrote:
| Access tokens are used for network calls so if the network
| is down nothing works anyway ?
| dylan604 wrote:
| You mean the power going out is related to why my
| computer will not respond and the screen went blank?
| That's strange
| bravesoul2 wrote:
| Sounds like you want local-first offline-first apps? Me
| too.
| freedomben wrote:
| If you've built a local app that has to authenticate you
| against a remote web service even when offline, and all the
| actual work is being done locally, you have much bigger
| design issues than authn IMHO
| d4mi3n wrote:
| 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.
| SOLAR_FIELDS wrote:
| It is, but its an architectural decision that forces expiry
| by default. So you should probably even have both. AWS runs
| 12 hour session tokens, but you can still revoke those to
| address a compromise in that 12 hour gap. The nice thing
| that forced expiry does is you just get token revocation
| For Free by virtue of not allowing renewal
| ars wrote:
| 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.
| fastball wrote:
| Not having to start all my API handlers with a call to the
| DB to check token validity significantly improves speed for
| endpoints that don't need the SQL db for anything else, and
| reduces the load on my SQL db at the same time.
| ars wrote:
| Does it actually improve speed though? The DB check is
| simply "does this key exist", it can be done in a memory
| database, it doesn't have to be the same DB as the rest
| of your data.
|
| Validating a token requires running encryption level
| algorithms to check the signing signature, and those are
| not fast.
| kevincox wrote:
| 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.
| catlifeonmars wrote:
| Having a short session expiry is a workaround for not being
| able to revoke a token in real time. This is really the
| fault of stateless auth protocols (like OAuth) which do
| offline authentication by design. This allows
| authentication to scale in federated identity contexts.
| apitman wrote:
| OAuth2 is not inherently stateless.
| catlifeonmars wrote:
| Good call. I said OAuth but what I meant was OIDC and
| specifically JWT. OAuth (not OIDC) implementations MAY
| use opaque access tokens that require server side state
| to validate.
| apitman wrote:
| Ah makes sense
| antihero wrote:
| Yeah but depending on how you set it up, you could have a
| very short expiry. If your auth system is as simple as:
| Verify refresh token -> Check a fast datastore to see if
| revoked -> Generate new auth token, this is very easy to
| scale and and you could have millions of users refreshing
| with high regularity (<10s) at low cost, without impacting
| on your actual services (who can verify the auth token
| offline).
|
| Say you had 1,000,000 users, and they checked every ten
| seconds, that's 100,000 requests per-second. If you have
| 1,000,000 users and can't afford to run a redis/api that
| can handle an O(1) lookup with decode/sign that can handle
| that level of traffic, you have operational issues ;)
|
| It's all a tradeoff. Yes, it means some user may have a
| valid token for ten more seconds than they should, but this
| should be factored into how you manage risk and trust in
| your org.
| dheera wrote:
| 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
| zer00eyz wrote:
| 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.
| yawaramin wrote:
| > The police department getting a court order and forcing
| you to unlock your phone
|
| If you live under a tyrannical regime, neither passkeys nor
| passwords will help you. The police state will find a way
| to do what they want with you.
| jesseendahl wrote:
| Whether or not you can be compelled to unlock your phone
| doesn't really have anything to do with passkeys. If you
| can be compelled to unlock your phone, then whatever you
| have on your phone (including the stuff in your password
| manager/credential manager) is potentially up for grabs. In
| this threat modeling scenario there's nothing unique about
| a passkey vs. a password.
|
| And if you're against using credential managers at all,
| because you only want to have the password stored in your
| brain and nowhere else.... then that creates different
| problems, namely it dramatically increases the odds that
| you will use the same password across multiple services,
| which is bad because then attackers can steal your password
| from one service and use it to login to a bunch of other
| services.
| catlifeonmars wrote:
| > SMS gets forwarded to email
|
| 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.
| tetha wrote:
| I was somewhat pondering along these lines.
|
| 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.
| maccard wrote:
| 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.
| tetha wrote:
| That sounds like a horrible setup though and is a good way
| to MFA fatigue and other security issues.
|
| In our case - I counted this morning too - I have 2 MFA
| authentications (VPN and the IDP used by Keycloak) until I
| have my Keycloak session. This session has an idle timeout
| of I think 2 hours, so if I don't do anything for 2 hours
| I'd have to re-auth. And it has a max session length of 10
| or 11 hours so it lasts even for long workdays. This has
| been setup so users generally have to login via MFA once a
| day in the morning. Since we're using the same
| authentication and setup, we know this works.
|
| Further token refreshes and logins then bounce off of that
| session. So our Jenkins just bounces us over to Keycloak,
| we have a session there, it redirects us right back. Other
| systems similarly drop you to the Keycloak on first call of
| the day and Keycloak just sends you back. It's very nice
| and seamless and dare I say, comfortable to use.
|
| It is however supposed to be easy and we spent some time
| getting it working this well.. because now people just
| integrate with the central auth because it's quick and easy
| and we have full control and tracking of all access :)
| babypuncher wrote:
| 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.
| timewizard wrote:
| > What are we really checking?
|
| That the security policy for the user and the resulting access
| key hasn't changed their level of access?
|
| Identity, while the most common use case, is only half the system
| when federating logins.
| paxys wrote:
| Why would you need to reauth for that?
| creamstout83 wrote:
| Validated the user that logged in is still the same person.
| msgodel wrote:
| Please just talk to my ssh agent and stop harassing me with
| authentication modals asking for tokens and fingerprints.
| throwforfeds wrote:
| 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.
| nkrisc wrote:
| Few things worse than spending 30 minutes writing something
| only to be asked to login when you submit it.
|
| Fortunately these days most services will cache your work.
| zelphirkalt wrote:
| Though to rely on Jira to respect your work or your browser
| functionality is madness.
| xyzzy123 wrote:
| This depends on your "world model", that is, what situations do
| you anticipate the people using your web site / application are
| in?
|
| The assumption that basically, device = same person (browser
| session really) over a long period of time is the right one, 99%
| of the time.
|
| Sometimes it's appropriate to make much more conservative
| assumptions. People might be in bad family situations (where not
| everyone with access to a shared device might be entirely
| trustworthy) or using a shared computer because they access
| things from a library, etc.
|
| You can't help much (the computer might as well be compromised)
| but short session timeouts can make sense.
| kevincox wrote:
| > People might be in bad family situations (where not everyone
| with access to a shared device
|
| Then they should configure their browser to log them out. Not
| hope that every site has good settings for their niche
| scenario.
| paxys wrote:
| Corporate IT still makes you change your password every N months.
| Tell them to extend the max session length beyond a day and some
| VP will have an aneurysm.
| jeremyjh wrote:
| There is very little incentive to actually do information
| security correctly - because hardly anyone can tell if you have
| - consequently there are very few people who try. It is all
| just theater to cover their asses, and they'll admit it under
| the right circumstances.
|
| They don't want to change idiotic policies like this because it
| means they'd have to admit they've been dogmatically enforcing
| counter-productive policies for decades.
| kevincox wrote:
| Hardly anyone can tell, until everyone can tell, because you
| have a breach.
|
| It's similar to the idea that if you aren't doing restore
| drills you aren't really taking backups. But people rarely
| test their auth rules.
| jeremyjh wrote:
| You could do everything correctly and still have a breach,
| so practitioners are quite fatalistic about it. The key is
| to diffuse decision making responsibility so that its not
| clear who can be fired.
| kiitos wrote:
| No modern IT organization mandates periodical password changes
| since, I dunno, mid-2000's.
|
| _edit_ : please note the "modern" qualifier, tons of IT orgs
| continue to mandate this anachronistic policy, sure, but those
| orgs aren't modern, the policy isn't a requirement for e.g.
| SOC2 or whatever, it's purely historical inertia.
| MBCook wrote:
| Ha ha ha ha ha.
|
| Where do you live? That's absolutely not my experience.
| staplers wrote:
| Is this rage bait?
| nijave wrote:
| Yes
| joshstrange wrote:
| Nope, not even close. IT depts continue this practice to this
| day.
|
| I had a friend in ~2015 that said they all had barcode
| scanners plugged into their computers (not 100% what they
| used them officially for) and so people would print their
| password as a barcode and stick it under their desk so they
| just had to scan the barcode to login (most/some/all? USB
| barcode scanners present as a keyboard and simply send scans
| as keypresses) due to silly password rotation rules. He said
| the people that didn't use the barcode trick would instead
| just have a post-it note on their computer or, at best, under
| the keyboard or in a drawer.
| kiitos wrote:
| Yes, many anachronistic and out-of-date IT depts continue
| this practice, indeed.
| paxys wrote:
| No true scotsman mandates password changes
| MBCook wrote:
| Genius. I love it.
|
| I was reading about keyboard firmware last night and saw
| the ability to do "tap dances", where a series of specific
| key presses in short order can trigger a predefined action.
|
| It instantly occurred to me how useful it would be to be
| able to quickly type "QWE" and have one long complex
| password input for you automatically. Then "ZXC" for
| another, etc.
|
| Of course flashing your passwords directly into your
| keyboard firmware is probably a pretty big security no-no.
|
| But all the places that love to enforce constant password
| changes with super specific rules sure make something like
| that sound appealing.
| paradox460 wrote:
| You don't even need to go full keyboard. You can flash
| qmk or similar firmware to a single key device. You now
| have something like a yubikey, that only ever outputs one
| password
| ExoticPearTree wrote:
| We deployed the barcode scanner with passwords too. It
| works wonders. People that use the system are super happy
| they don't have to type in "secure passwords" and some
| security auditors are happy we have the "enable password
| complexity" checkbox ticked.
| inglor_cz wrote:
| My Microsoft account is definitely bothersome like this. I
| never searched for the root cause (tenant policies? some
| default value somewhere?), but I have to refresh my password
| every 4 months or so.
| qualeed wrote:
| It's a setting in the admin.microsoft.com portal (Org
| settings -> Security & privacy -> Password expiration
| policy).
|
| The setting, funny enough, is literally "Set passwords to
| never expire (recommended)".
|
| They also link to "Learn why passwords that never expire
| are more secure" in the same place.
|
| Anyone who is forcing expiry is specifically going against
| recommended policies (Microsoft's, NIST's, and any serious
| security person) for some reason or other.
| ExoticPearTree wrote:
| We had to prove we have a password expiration policy for
| a compliance audit, showed them that MS recommends not to
| have passwords expire and the NIST guidance and the
| auditors were supper happy.
| qualeed wrote:
| Several frameworks are (finally) catching up to modern
| day understanding, and have either forgone the
| requirement for password rotation or have various
| exemptions if other technical measures are in place. But
| I agree, for those that haven't changed, it's incredibly
| frustrating to hamstring your own security so that you
| can pass a compliance or security audit.
|
| I obviously don't know which framework you are auditing
| against, so can't be specific, but it may be worth
| double-checking the requirements rather than relying on
| the assessor's word (if you aren't already). It is not
| unheard of for assessors to be behind on their
| understanding of best practices (especially those who've
| been an assessor for a long period of time - they may be
| going more by habit and previous engagements instead of
| the most up-to-date documents).
| kiitos wrote:
| Seconded, to repeat an earlier comment, I've been a
| member of multiple organizations that satisfied SOC2 and
| PCI and etc. without requiring password rotation...
| MBCook wrote:
| Every four months? If only. I'm required to do it every 30
| days for a number of systems. The good ones are every 90
| days.
| icedchai wrote:
| I have one that emails me every 3 months to change my
| password. Very annoying.
| thyristan wrote:
| Even worse. NIS2 in the European Union makes password changes
| legally required for many organisations.
|
| https://eur-lex.europa.eu/legal-
| content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)
| MBCook wrote:
| I've been told PCI does as well, though I don't know if
| that's really still true.
|
| Edit: jjav beat me to it below, confirming it is.
| qualeed wrote:
| PCI DSS 4.0 does not require password rotation unless the
| password is the only authentication (i.e. no MFA).
|
| Use MFA, and you don't need to rotate.
|
| _> Clarified that this requirement applies if
| passwords/passphrases are used as the only authentication
| factor for user access (i.e., in any single-factor
| authentication implementation).
|
| >Added the option to determine access to resources
| automatically by dynamically analyzing the security
| posture of accounts, instead of changing
| passwords/passphrases at least once every 90 days._
| bux93 wrote:
| Yikes, whoever wrote that should be ashamed of themselves.
| On the bright side, it doesn't specify how long the
| predefined interval should be, and says entities are to
| 'ensure the strength of authentication is appropriate to
| the classification of the asset to be accessed' - so, in
| order to ensure the appropriate strenght the interval
| should be 100 years is totally defensible IMHO. The whole
| paragraph doesn't take MFA in account anyway, and FIDO2
| does provide for key rotation (even if it's not widely
| implemented, maybe something to consider if you're covered
| by NIS2 - or manually rotate keys once every year).
| thyristan wrote:
| 11.3. (a) mandates multi-factor auth for priviledged and
| sysadmin accounts, and 11.7. requires multi-factor auth
| depending on criticality determinations. All in addition
| to whatever is in 11.6.
|
| But the thought about the non-specified intervals in
| 11.6. is great, nowhere in there are any numbers to be
| found. So basically one can do the sensible thing, set
| some huge numbers that are no problem in practice and
| everything is fine.
| bux93 wrote:
| I mentioned MFA because 11.6 says to change
| "authentication credentials", but with MFA that could
| mean both factors or either. So key rotation without
| changing the "what you know" factor would arguably also
| satisfy the requirement; the term 'credentials' is not
| defined, and especially not defined in relation to MFA.
| jjav wrote:
| > the policy isn't a requirement for e.g. SOC2 or whatever
|
| It is a PCI requirement and probably from other sources.
|
| Of course it is brain dead and we even have authoritative
| documentation from NIST explaining why it is stupid, but
| nobody at PCI has any technical skills to understand that so
| the madness lives on.
| kiitos wrote:
| It is for sure not a PCI requirement that user system
| passwords need to be changed on any kind of interval. At
| least, I've been a member of several PCI-compliant
| organizations that did not have or enforce this policy.
| qualeed wrote:
| > _It is a PCI requirement_
|
| The only requirement for password rotation in PCI DSS v4.0
| is if the password is the _only_ form of authentication
| (i.e. no MFA). Use MFA (which you should be anyways) and
| you don 't need to enforce password rotation.
|
| > _Clarified that this requirement applies if passwords
| /passphrases are used as the only authentication factor for
| user access (i.e., in any single-factor authentication
| implementation)._
|
| _> Added the option to determine access to resources
| automatically by dynamically analyzing the security posture
| of accounts, instead of changing passwords/passphrases at
| least once every 90 days._
| paradox460 wrote:
| No true Scotsman
| al_borland wrote:
| It's all theater so they can sell the idea that they're doing
| everything they can, and if something does happen they can
| shift blame.
| Freebytes wrote:
| In many cases, it may be to fulfill rules associated with
| PCIDSS requirements, even if the company never sees the
| credit card. This all originates from consultants, and the
| consultants are engaged in security theater.
| FrancoisBosun wrote:
| Heroku's 25 hours comes to mind... this is so infuriating and
| annoying.
| valenterry wrote:
| This is spot on. And it's a general misunderstanding of security
| in practice. _Availability_ is often missed /ignored (but it is
| part of security) and attention is an important currency that
| needs to be treated carefully - or you and up with the mentioned
| MFA fatigue attacks or people writing down their passwords.
| jeremyjh wrote:
| The most secure thing would be to unplug the servers.
|
| edit: I'm agreeing with parent. Availability is part of
| security. If it weren't, you could unplug the server and call
| it a day.
| circular_logic wrote:
| I have tried to point out that poorly implemented or non
| contructive security controls reduce system availability. As
| employes are not able to get to the information they need in a
| timely manner.
|
| But it's been a dead end to many an argument. For some the
| underlying issue is a refusal to accept that product usability
| and security are not mutually exclusive and a difficult to use
| system just leeds to grey IT in the org.
|
| The most odd reply I have received was pedantics on the
| definition of security availability, i.e.,
|
| "Ensuring data and network resources are accessible to
| authorized users when needed"
|
| Beacause it contains the word "authorized" any controls for
| authorisation can therefore never affect availability as they
| have to be authorized before we can consitter it an impediment
| to availability...
|
| If anyone has a reply better than that's ridiculous, please
| help me here
| Spooky23 wrote:
| Only if you make a bunch of assumptions that may not apply. My
| employer allows BYO and has a default Outlook Web session
| timeout.
|
| Is it ok that my son stopped at my desk at home and saw customer
| PII that was left open?
|
| I enforce these kinds of policies at my company even though I
| find them personally stupid. I do so because I'm the custodian of
| my customers property and have a duty to minimize risk of
| employees or contractors acting poorly.
| paxys wrote:
| Is it ok that your son stops at your desk to see PII while the
| session is still active? And how does reauth even help with
| this case? Do you expect your session to expire every 15
| minutes while you are taking a break?
|
| The problem here isn't auth expiry but you not locking your
| computer when you step away from your desk.
|
| Your policies aren't enforcing security, just security theater
| (and making a lot of employees very annoyed in the process).
| Spooky23 wrote:
| Who said it wasn't locked?
| nijave wrote:
| >Is it ok that my son stopped at my desk at home and saw
| customer PII that was left open?
|
| In practice/reality, probably. Most employers will disagree.
|
| Consider your son could just as easily over hear a phone call,
| see a piece of paper, etc. If your son was actively malicious,
| there's all kinds of things from cameras to video splitters to
| key loggers he could do. If he's not actively malicious, who
| cares if he sees something
|
| If you're in a line of work worried about shoulder suffering,
| then you should really consider whether BYO is a good idea.
| zelphirkalt wrote:
| "Shoulder suffering" a funny one ; )
| nijave wrote:
| Whoops missed the autocorrect on that one _facepalm_
| Spooky23 wrote:
| In fairness, accurate. Anyone choosing to read my work
| email is certainly embracing suffering.
| JackSlateur wrote:
| Also, there are shields for screens which basically hide it
| from anywhere not directly in front
|
| Very useful for people who work in trains and stuff: their
| neighbors can't see things
| harshaw wrote:
| My problem is that there is a reauth FOMA that gets copied with
| the most trivial of applications. A good example is the Electrify
| America charging app. It's job is to be available so you can
| charge. But they log you out frequently - and they want to do
| second factor with email. Guess what - that doesn't always work.
| My wife was trying to charge the other day, was logged out, and
| couldn't get the email verification to go through. So I had her
| login with my credentials and I answered the email verification
| and gave her the token over the phone. super annoying.
|
| But more importantly- mobile phones already have good security
| mechanisms. It's like all these shitty apps copied web based auth
| mechanisms with timeouts when they could do something better (and
| probably are built on web technologies with cookies instead of
| using the trusted store on the phone).
|
| There are precious few apps out there that tell you ahead of time
| that reauth is happening (Zoom does this - kudos). But even so -
| I don't think it's necessary most of the time.
| MBCook wrote:
| I don't need to charge often, but I'm logged out of every
| single one of my charging apps for that reason. They kick me
| out constantly.
|
| If you want me to auth to make a payment when starting a
| session, fine. I'll hate you, but whatever.
|
| Nope. Can't even get into the app. Want to see where their
| stations are? Too bad. Sign up, sign in, or hit guest mode and
| prepare to be annoyed.
|
| I can stay signed into Amazon with a credit card set up for
| years at a time.
|
| God forbid I ever want to charge a car.
| tonymet wrote:
| Yahoo published these findings over 20 years ago , that frequent
| re-auth made customers less secure because it encouraged poor
| password hygiene like short passwords, writing them down, etc.
|
| It's also risky to have the primary password credential
| transmitted instead of temporary tokens.
| al_borland wrote:
| On the side of things, the risk of never needing your password
| is people tend to forget it.
|
| Just the other week I was helping someone setup a TV and they
| thought they didn't have an Amazon login, because they never
| needed to login. This was a Prime member.
|
| 1Password defaults to having users reauthenticate every 2
| weeks. I do find this a bit annoying, but I find the occasional
| reminder of my password to be a necessity evil. Even doing it
| every 2 weeks for years, there are some days I have trouble
| bringing it to the front of my mind. And that would mean a
| hidden piece of paper somewhere with the password written down
| in case it's forgotten. As I get older I should accept the idea
| that I should have these emergency systems in place if my mind
| does go, but it makes me uncomfortable.
| tonymet wrote:
| It's a good point on password usability. Signal app
| periodically prompts you for the encryption PIN to make sure
| you don't forget it.
|
| I think this should be handled out of band of the login
| process. Similar to "is xxx still your phone number?" --
| companies could do periodic password hygiene and freshness
| checks.
|
| Context matters. Companies forget that people are trying to
| get something important done, and blocking them for other
| attention is a huge frustration.
| cesarb wrote:
| > Signal app periodically prompts you for the encryption
| PIN to make sure you don't forget it.
|
| At least Signal does not block the app until you enter the
| PIN. WhatsApp forces you to enter it before you can reach
| your messages, which not only is annoying when you're in a
| hurry, but also forces you to type the PIN even when you're
| in a place where it might be seen by someone else.
|
| On the other hand, on Signal it's possible to leave the
| warning forever at the bottom of the screen without
| acknowledging it and typing the PIN, which kind of defeats
| its purpose.
| tonymet wrote:
| good point
| tonymet wrote:
| Apps need to treat these experiences more critically. I
| had a similar forced re-auth with Gaia when i was
| offline, losing my maps.
|
| So here I am, lost, trying to find my way using a
| downloaded map, and the app won't let me in.
|
| These are no longer casual entertainment experiences we
| are dealing with. Many of these apps are central to
| carrying on with life. And they are introducing new and
| unanticipated failure modes.
| nijave wrote:
| Our work SSO is set to 12/24 hours in most places which seems
| like a decent compromise. Auth once a day
|
| In a corporate environment, ideally your workstation password
| is tied to SSO and you have a short but reasonable lockscreen
| timeout where you need to re-type your password.
| Sjoerd wrote:
| Do you have a link to that Yahoo publication? Or any more
| information on it?
| tonymet wrote:
| probably not
| czk wrote:
| user clicks a phishing link and is asked to login to M365 again,
| they do it without hesitation because they are used to doing this
| 5 times a day
|
| logging into phishing links would make more people pause if they
| didnt have to login constantly to get work done
| zelphirkalt wrote:
| Especially with Office 365 this is the case, because of their
| ridiculous amount of scripts from tons of domains. They are
| very far removed from making a good product.
| princevegeta89 wrote:
| 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.
| paxys wrote:
| 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...
| thyristan wrote:
| 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.
| count wrote:
| Disable anti-tracking features and ad blocks, it turns out
| cookies and temp storage for ad tracking are how IDPs track
| your choice to trust the device too.
| thyristan wrote:
| Adblocking and anti-tracking are mandatory on my company
| laptop, cannot switch those off. And I wouldn't want to.
| notpushkin wrote:
| This is actually one great use for an MDM policy.
| xp84 wrote:
| Most adblockers etc are pretty selective about cookies.
|
| I guess if you got really aggressive like an allow-list
| approach, you could have friction, but just using
| ublock's defaults I don't get 'unrecognized' from
| anything any quicker than I do on a device without it.
| wycy wrote:
| I wonder how many millions of productivity hours have been
| lost due to millions of people having to click through
| these stupid, useless prompts countless times per day.
| antod wrote:
| That is the single most useless dialog/question in IT. I
| wonder how much money that costs the global economy a year.
| mlinhares wrote:
| 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.
| reddalo wrote:
| I agree with you, but it's the same reason why Microsoft
| asks you to type a numeric code generated by their Outlook
| app in order to login. It's to prevent people from
| dismissing the alert by clicking "OK" without even reading
| (especially if they're in the middle of something else,
| e.g. during a scam phone call).
| brendoelfrendo wrote:
| Right, the numeric code is proof of intent. In theory,
| tapping "ok" or "yes, this is me" should be proof of
| intent. In reality, it's common for those who have
| compromised someone's password to flood people with these
| notifications and auth prompts to get them to eventually
| say "ok," even if by accident.
| deepsun wrote:
| Duo Mobile at least make it two clicks (on Android at
| least). So a distracted user would likely to swipe off
| the notification, instead of tapping through and clicking
| "Yes, it is me" on the next screen.
| mrandish wrote:
| > it's common for those who have compromised someone's
| password to flood people with these notifications and
| auth prompts
|
| And by excessive reauthing, legit platforms and apps are
| helping scammers by conditioning users to click "OK" or
| enter a passcode reflexively just to get on with their
| lives. Frequent reauth makes everyone _less_ secure.
| mlinhares wrote:
| TIL, this now makes a lot of sense, won't be as mad about
| it anymore.
| munk-a wrote:
| It does also increase friction for non-first party
| applications and Apple has a strong history of using
| product design to discourage non-first party apps.
| felipeerias wrote:
| To prevent an attack where someone steals your username and
| password, triggers the 2-factor notification, and waits for
| you to accept it. This can be automated and repeated until
| you eventually click the wrong button for one reason or
| another.
|
| By requesting a short-lived code, attackers now need to
| communicate with you at the same time of the attack and
| somehow convince you to give them that code. Much harder.
| altairprime wrote:
| 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.
| whiplash451 wrote:
| In 2025, I don't think that accessing apple accounts on a
| non-apple device is a happy path for apple anymore.
| apitman wrote:
| "Trust this device" is the modern day elevator door close
| button.
| princevegeta89 wrote:
| Haha
| arccy wrote:
| I've found that it's only american elevator door close
| buttons that don't work.
|
| The rest of the world manages to keep them operational.
| pests wrote:
| On US elevators there is a minimum open duration to
| accommodate the handicapped or disabled. The door close
| button can't force the door closed any faster.
|
| Then most set the auto-close duration equal to this
| minimum open duration and you get this appearance of
| buttons doing nothing.
| chrisweekly wrote:
| 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.
| KennyBlanken wrote:
| > 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.
| apenwarr wrote:
| You're right except in the very specific case of the App
| Store purchase or download process. You only get one chance
| at FaceID and then it demands a password. But, if you
| cancel and do it again, you get another chance at FaceID.
| It's mystifying why they'd make that UX choice.
| vachina wrote:
| 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.
| MBCook wrote:
| Really? I never have to re-auth unless I get a new device.
| quesera wrote:
| Same behavior here.
|
| 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.
| ziml77 wrote:
| It's annoying to ever have to enter a password manually,
| but it does make sense every 1 or 2 weeks to force it. Not
| even as a security thing but as a memory thing. It's
| incredible how something that you seem to know so well can
| get flushed from your memory after you stop recalling that
| knowledge regularly.
| quesera wrote:
| Exactly. I have enabled TouchID for a couple of banking
| apps, and I am dreading the likely need for the password
| reset dance when the time comes (it's been years).
|
| I use a password manager, but I've always kept the
| _actually_ important passwords in wet memory only. When I
| used the web interface regularly, that was not a problem.
| However... :- /
| grishka wrote:
| 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.
| 1718627440 wrote:
| > macOS and Android
|
| > It's my device.
|
| There is your dissonance.
| yard2010 wrote:
| This is just enshitification in a mask. Next thing you know,
| guess what? Your device is not yours, you just rent it from
| the feudal.
| socalgal2 wrote:
| 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.
| grishka wrote:
| Remembering things reliably must be the most unsolvable
| problem in computer science.
|
| Unless it's related to advertising. Then it works flawlessly
| and sometimes survives device transfers and factory resets.
| falcor84 wrote:
| "The best minds of my generation are thinking about how to
| make people click ads."
|
| -Jeff Hammerbacher
| olddustytrail wrote:
| I saw the best minds of my generation destroyed by
| madness, starving hysterical naked, dragging themselves
| through the negro streets at dawn looking for an angry
| fix
| Y_Y wrote:
| How is that supposed to make anyone click on an ad?
| falcor84 wrote:
| Just to expand upon the reference, the comment you
| responded to is the first stanza of Allen Ginsberg poem
| "Howl" [0] published in 1956, which is what Hammerbacher
| paraphrased in the quote that I shared. "Howl" is amazing
| on its own though, and I highly recommend that people
| read the whole thing and/or watch the 2010 film about
| Ginsberg's life where James Franco recites it in its
| entirety[1]. And as a follow-up, I also highly recommend
| Scott Alexander's "Meditations on Moloch" that takes
| inspiration from the poem to analyze societal failures of
| coordination.
|
| [0] https://www.poetryfoundation.org/poems/49303/howl
|
| [1] https://www.imdb.com/title/tt1049402/
|
| [2] https://slatestarcodex.com/2014/07/30/meditations-on-
| moloch/
| Y_Y wrote:
| Thanks for adding the background, much more helpful than
| my glib nonsense.
|
| I feel that Meditations on Moloch should be mandatory
| study for anyone who lives in a society.
| babypuncher wrote:
| I hate how in macOS, I can double click a window's title
| bar to maximize it, and five minutes later the original
| window size will be forgotten so you can't restore it.
|
| Windows 95 had this shit figured out on systems running a
| 486 and 6MB of RAM.
| happymellon wrote:
| Not just the window size, but if you have more than one
| monitor, it won't always remember the screen.
|
| Oh, you double clicked to make it bigger? How about
| making it postage stamp sized in the bottom left of a
| different monitor...
| duxup wrote:
| I feel like advertising relies on getting it right "enough"
| not for everyone and ... they don't care.
|
| Auth and settings people will tell you when it is wrong and
| that is generally thought of as a problem. Yet advertising
| doesn't care.
|
| For years Amazon kept showing me women's products. I never
| once bought any or looked them up but man they were sure I
| wanted to buy some.
|
| Google thought I was a Nebraska Cornhuskers fan but really
| I'm a fan of a rival, that's why I had to google a few
| things about them, but my old google news feed was sure I
| was a fan... even when they gave me a chance to say "no
| news about this team" they kept doing it ...
| hamburglar wrote:
| It's worse if you say no. It just keeps asking you. I don't
| plug my phone into my Mac to charge it anymore. It's just too
| annoying.
| baggy_trough wrote:
| This is seriously annoying.
| daneel_w wrote:
| 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".
| phire wrote:
| That stops the computer asking, but it doesn't stop the
| phone asking.
|
| Apple changed this a few years ago, because of a potential
| security venerability: https://imazing.com/blog/ios-backup-
| passcode-prompt
| socalgal2 wrote:
| It's a known solvable problem though. Both devices can
| exchange public keys and every time they're connected
| they can validate those keys with each other.
| sircastor wrote:
| 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.
| paxys wrote:
| If it helps there's no security advantage of a 50+ character
| password over a suitable 16 character one.
| mikepurvis wrote:
| Remember how 1Password used to install itself as a custom
| keyboard that could "type" your passwords into arbitrary
| text fields anywhere in the OS, before password management
| specific hooks were added?
|
| It would be nifty if your phone could just connect to other
| devices as a BT keyboard and type in passwords there too.
| Probably not worth the actual fuss of pairing a BT device,
| but if that part were not so painful it could be quite a
| nice solution.
| alasarmas wrote:
| One major flaw in this approach is the one-way channel
| (keyboard input) prevents the password manager from
| knowing if it is supplying credentials to the correct
| recipient. Phishing attacks are relatively common and
| users expect a password manager to know these things,
| even in situations like you have described where it's
| clearly impossible. I think this is why this approach
| hasn't succeeded in the marketplace and FIDO2/WebAuthn
| support seem to be table stakes.
| mikepurvis wrote:
| Yeah, certainly a proper security module / passkey-type
| approach is ideal, it would be hard to justify all the
| bother of developing a bluetooth typer if really the only
| use-case for it is legacy devices that are old enough to
| not have an OS supporting the client app, but new enough
| to still pair with a device pretending to be a bluetooth
| keyboard.
| mbreese wrote:
| Yeah, but passphrases don't require switching keyboards as
| often in mobile. And if you're using a 16 character
| P@s5w0R6, a 50 character passphrase can be just as secure.
|
| What I can't stand if when I'm prompted to type a password
| on my Apple TV and can't use my phone for some reason.
| Scrolling across the alphabet for a passphrase is torture.
| happymellon wrote:
| My work switched our passwords from minimum 8 digits of
| upper, lower, numeric and special (requires all 3
| present) to a passphrase.
|
| Now its 21 minimum but requires upper, lower and numeric.
| I guess at least I don't have to stick an exclamation on
| the end.
| Xevion wrote:
| 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.
| crazygringo wrote:
| > _Switch to a phrase-based password._
|
| I assume _that 's why it's 50+ characters long_, as opposed
| to 20 gibberish characters. Because phrase-based passwords
| are longer. And whether it's 40 or 50 or 50+ doesn't even
| matter, the point is it's not short like a 6-digit PIN.
|
| I have the exact same problem. It's still incredibly
| annoying to type on a touchscreen keyboard. If you mistype
| _one_ character...
|
| So no, it's not the commenter's fault. And it's certainly
| not mine. I'm doing the best with the tools I have
| available. It's Apple's fault, mainly.
| CamperBob2 wrote:
| 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?
| hamburglar wrote:
| Yes, it's really bad for security. I just deny it if I don't
| know what it's for. I'm sure I'm missing out on some very
| important functionality.
| CamperBob2 wrote:
| My understanding is that iCloud backup requires it, among
| who-knows-what other things. So I've been reluctant to hit
| "Not now."
|
| I just have to trust their security model to not allow
| random apps to pop up and issue those prompts.
| ryandrake wrote:
| I'd be surprised if there aren't malicious apps that pop
| up their own counterfeit version of Apple's "Just enter
| your password again, trust me bro" dialog that looks just
| like the real thing, and then do nefarious things with
| the trusting user's input.
| xp84 wrote:
| Not only apps, webpages can easily do it too! I know that
| sophisticated users might think to themselves "hey why
| didn't it play the correct app-switching animation after
| I clicked 'Open Settings' to enter my password" or
| something, but normal users could be fooled simply by
| loading the password-entering UI lookalike right there in
| the browser, probably more than half the time, which is
| way more than enough.
|
| Apple's continued drive toward having UI disappear when
| not "in use" makes this so much more trivial. Currently,
| as long as you've scrolled down an inch or so, Safari's
| chrome consists of a single line of ~5 point text, the
| hostname, on a plain background at the bottom of the
| screen. So, "Wait, i'm still in the browser" is the kind
| of thing only nerds would think. Normal people would just
| ignore the tiny text saying "apple.com.account-
| verification-system.cgi-bin-iphone-3cabcdef38673824.xyz"
| and assume they're looking at legitimate UI as long as it
| roughly approximates iOS.
| carlosjobim wrote:
| 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.
| makeitdouble wrote:
| People are _required_ to have complicated passwords in most
| services.
|
| Yet they'll still make you type it out in so many
| situations, including on account creation confirmation
| where some service will even block copy/paste to push you
| to type it.
|
| Services will accept losing an user over password grating
| issues ("no compromise on security"), so it just gets worse
| and worse.
| carlosjobim wrote:
| It's much more practical for me as a user to use
| biometric identification to fill in passwords. That means
| I can have different auto generated passwords for each
| service, that are impossible to crack. And if one gets
| leaked, then that's the only password that gets cracked.
| The security benefits are enormous, and the ease-of-use
| benefits are enormous.
|
| I haven't seen any service block paste when filling in or
| making a password for at least the past 8 years. Any such
| service would instantly lose all their customers with
| iPhones or other Apple devices. Not good business.
| xp84 wrote:
| I get absolutely enraged at sites that block pasting. The
| two I know of are Quickbooks when paying an invoice with
| ACH and my tax collector website.
|
| I'm pasting in a bank account number and some dumb person
| somewhere though, "Our users might be pasting in a bank
| account number... from... a 'bad' copy of it. Let's force
| them to potentially have to app switch repeatedly, and
| type 3 numbers at a time, from a 12-digit number they
| don't know well. Because we don't trust this 'Paste'
| voodoo!"
|
| Even if I'm on a PC with windowing and don't have to app
| switch, the amount of misguided paternalism needed to
| tell me I _cannot paste_ fills me with rage.
| projektfu wrote:
| I'm very happy with this extension:
|
| https://chromewebstore.google.com/detail/dont-f-with-
| paste/n...
|
| https://addons.mozilla.org/en-US/firefox/addon/don-t-
| fuck-wi...
|
| https://greasyfork.org/en/scripts/36928-don-t-with-paste
| (works with Safari)
|
| I get frustrated by having to retype routing/account
| numbers, or not being able to paste them in the first
| place. And the ubiquitous e-mail address confirmations.
| (Given that I still get dozens of e-mails sent to me
| intended for other people, not spam, just sent to the
| wrong address, this isn't working. People mistype their
| e-mail addresses multiple times. You really need to
| verify the e-mail address by sending an e-mail and asking
| for a code or a click.)
| sangeeth96 wrote:
| 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.
| crazygringo wrote:
| 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.
| sangeeth96 wrote:
| Hmm, might be worth reporting if you haven't already. I
| just tried installing something with IAPs, which usually
| triggers the prompt. I had the option to use FaceID on my
| phone. I tried the same on macOS and I had the prompt to
| use TouchID. I'm on Tahoe beta right now but it worked the
| same even while on Sequoia. It's once in a blue moon I see
| the password prompt, not sure exactly what causes it to
| appear.
| dwaite wrote:
| Are you using a single Apple Account for both the primary
| account on device (iCloud, etc) and for iTunes? That is the
| other scenario where I see people hitting this.
| duxup wrote:
| Is this for a particular situation(s)?
|
| I do not run into this at all across my apple products.
| mountainriver wrote:
| I have to change my apple password every single time I need to
| download an app.
|
| It seems like insane friction for something that is making them
| a lot of money
| croemer wrote:
| Same. And annoyingly you're not allowed to reuse old
| passwords, so you have to keep inventing (and remembering)
| new ones.
| daneel_w wrote:
| 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.
| out-of-ideas wrote:
| > 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.
|
| edit: clearification
| SchemaLoad wrote:
| 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.
| NL807 wrote:
| 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.
| everforward wrote:
| 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.
| xp84 wrote:
| 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.
| xp84 wrote:
| 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 Mac pops those up too, now. Utter insanity.
| Wowfunhappy wrote:
| The _really_ annoying thing is that when I purchase an app on
| my watch, it makes me type the password _on my watch_...
|
| How is this a thing?!
| dcow wrote:
| Something is mis-configured. This isn't the default experience.
| TouchID works just fine for AppStore purchases.
| ValleZ wrote:
| 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.
| b0a04gl wrote:
| apple's auth team optimises for their own paranoia, not the
| user's threat model. i'm sitting there trying to install a damn
| app, and the system treats me like an intruder on my own phone.
| if the goal is friction, mission accomplished. but if it's
| trust and safety, they lost me at the 7th password prompt
| nofunsir wrote:
| It literally is Jennifer Lawrence's fault. No joke.
|
| Same with the forced emails you get ANYTIME you login to iCloud
| via web.
| Terretta wrote:
| This is not Apple's intended default behavior.
|
| 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.
| closeparen wrote:
| 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.
| paxys wrote:
| 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...
| lxgr wrote:
| At least for that one, you can now point to NIST
| recommendations, which finally discourage rotating passwords.
| LordDragonfang wrote:
| There's supreme irony with Tailscale being the one posting this
| -- because one of my biggest annoyances with the service is that,
| afaict, there's no way to set up a device so that it never
| expires.
|
| I just had two devices - one of which was my main server - I was
| using it with require re-auth out of nowhere and break one of my
| workflows. If I had not already set up separate remote access to
| the server, it would have been really annoying.
| 0xQSL wrote:
| There's "disable key expiry" per machine in the tailscale admin
| panel
| haiku2077 wrote:
| https://tailscale.com/kb/1028/key-expiry#disabling-key-expir...
| HeavenFox wrote:
| Yes, and it's especially frustrating for tailscale, since when
| it signs you out on the server you are often not in a position
| to re-auth
| haiku2077 wrote:
| Just disable key expiry for the machine in the admin console
| bgirard wrote:
| The flip side of this is that I had a Ring doorbell in a home I
| lived in. Moved out and split up with my ex. Years later I
| installed a new Ring doorbell and I got a message from her
| shortly after installing it saying she was getting notifications
| again from my new Ring camera.
|
| Kind of scary now to wonder if there's any loose accounts
| somewhere that's leaking sensitive information due to never
| requiring reauth.
|
| I think the worse offender is iMessage. It's very easy to not
| understand that your SMS messages are -sometimes- going over
| icloud and can be seen on old apple devices you might have given
| up. I tried to unregister my phone number from iMessage about 5
| times and it just doesn't work for me.
| pqdbr wrote:
| I'm trying to understand why my Rails application constantly logs
| me out in my iPhone/Chrome.
|
| The same web app stays logged in forever in my mac and I access
| both of them with the same time intervals.
| NoMoreNicksLeft wrote:
| They've got the google mail here at work set to make me change
| the password once per month. The 100-character, unguessable, un-
| shoulder-surfable password that isn't reused anywhere. In
| addition to the 2fa I have to use with it. And it will now ask
| for reauth once per week, which just happens to somehow be 2
| minutes before the important weekly meeting I'm supposed to
| attend which kicks me out of calendar for the link to the Google
| video meeting.
|
| But at least it makes me reauth.
| twodave wrote:
| 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.
| dstroot wrote:
| 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...
| Henchman21 wrote:
| 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.
| nightpool wrote:
| Stop paying them, I guess, and find a different audit firm
| that's more knowledgeable. Just like anything else--you get
| the level of competence you pay for. (Although I guess
| there's probably a "sweet spot" at which you can pay less
| AND get better first-level auditors if you're not looking
| at the biggest firms that are going to charge the most
| money and also have the most churn)
| immibis wrote:
| In a free market, you don't - you start your own company
| that doesn't waste half of everyone's time on security, and
| do stuff twice as efficiently, for half the price and
| outcompete the other one.
|
| Then you get outcompeted by a company with no security at
| all, which is twice as efficient as you until they get
| hacked.
| spacebanana7 wrote:
| Good security, the stuff that actually stops you from
| getting hacked, shouldn't be considered wasteful. And
| eliminating good security shouldn't be considered an
| improvement in efficiency.
|
| Ideally we should use the word "waste" to narrowly point
| at activities that are entirely pointless. Like requiring
| password rotation every 7 days.
| catlifeonmars wrote:
| There is no incentive to do so when the shareholders are
| only interested in the next quarterly earnings report.
| twodave wrote:
| Customers need to ask for these changes, which is why this
| is hard to solve. At least in my field, many of the
| measures we end up having to fall in line with are the
| result of our customers deciding that those who bid on
| their contracts must have these certain credentials. If
| those same customers had more competent decision-makers
| determining technical qualifications then this would be
| less of an issue. Unfortunately, that also means that we
| will be stuck with these audits in their current form until
| the vast majority of our customers first decide they're not
| needed.
| rainsford wrote:
| 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.
| smallerfish wrote:
| I've been pushing NIST on SOC2 auditors for years. They always
| accept it once given a link.
| notTooFarGone wrote:
| Yes, it's this rolling on your back and preemptively trying
| to cover all eventualities that does stuff like this.
|
| It seems like none wants to actually justify their decisions
| to auditors as its more time critical when the audit happens.
| HauntedKiwi wrote:
| If only everyone involved with security compliance could
| learn the lesson that John learned in The Phoenix Project,
| developers and ops folks would experience a lot less
| pressure to treat the pantry like Fort Knox. There is not
| only evidence that goes against the expectations of many
| auditors, but there's also no requirement that compliance
| of everything be implemented through costly software and
| network changes, because physical security and process can
| be used for compliance as well.
| ShakataGaNai wrote:
| 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".
| mooreds wrote:
| The auditors aren't writing the compliance guidelines, are
| they? Just enforcing them.
|
| I'd say you want to send these articles to the people writing
| such guidelines.
|
| What am I missing?
| twodave wrote:
| 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.
| mooreds wrote:
| > because it is security theatre, something they can point
| to if anything goes wrong.
|
| Yeah, there is space between "this is a good practice and
| it's nice to be able to check the box" and "this is a
| standard someone else dictated but it will cover my butt if
| anything happens" unfortunately.
|
| I get it, I depend on standards all the time (food safety,
| equipment certification) so I understand the desire, but
| darn it's frustrating when they are viewed as a cure-all.
| 0xQSL wrote:
| My employer just started doing daily reauth for all microsoft
| logins (teams, ...). The worst thing is that it's just 24h not
| start of day, so it may just be five seconds before you want to
| join a meeting.
|
| They haven't found the setting for mobile yet, so I might just
| stop using desktop teams.
| eddythompson80 wrote:
| Had that on the WiFi system at a facility I used to work from
| for a while.
|
| When you connect to their WiFi, you go to a guest portal to
| connect to the internet. The guest portal grants your MAC
| address 24 hours of access. Meaning one day you get to work at
| 9, the next day you get in at 8:55, you'll have 5 minutes more
| of WiFi before things just stop working and your system takes a
| minute to realize you need to reauth with the captive portal
| paxys wrote:
| And successfully opening a wifi captive portal is the most
| difficult thing to achieve in all of tech for some reason.
| 6LLvveMx2koXfwn wrote:
| man, I thought that was just me.
| marcosdumay wrote:
| It's even harder than moving a file from a desktop into a
| telephone on the same LAN with an USB cable plugging both.
|
| Computer security has a problem.
| lxgr wrote:
| This is why 24 hours is a particularly bad timespan for
| reauthentication. With e.g. 16 hours, you'd at least get a
| predictable prompt on each new workday.
| steadicat wrote:
| One time I led a project and ran daily standups by screen-
| sharing our Asana board so the team could review in-
| progress tasks. Every day, right in the middle of the
| meeting, Asana logged me out. I'd rush to log back in to
| finish the review, thus ensuring we'd repeat the cycle
| exactly 24 hours later. This silly dance lasted the whole
| project.
| nofunsir wrote:
| Ironically, daily
| standups:project_management::frequent_reauth:security
| arccy wrote:
| Didn't you take weekends off?
| Marsymars wrote:
| I've been complaining about this exact thing at my company for
| _years_. The worst is, they actually had it at 12h but rolled
| it up to 24h after some exec complained he had to sign on twice
| in one day.
| gs17 wrote:
| This also just happened to me too, except we only use Outlook.
| Web Outlook handles this state really poorly for some reason.
| It doesn't kick me out, it just pops up a little banner.
| thway15269037 wrote:
| I hate how prevalent it has become and it's getting even worse.
| One company that is buying our product has enforced SSO in theirs
| installation, making access_token lifetime of 15 seconds and
| refresh_token 4 minutes. For those unaware of OIDC/OAuth/SSO
| terminology, basically it means "if you lost access to internet
| for 4 minutes, invalidate your session, invalidate everything,
| make user go to auth, pick up 2fa, input everything...".
|
| It causes incredible amount of stress in end users, who keep
| spamming us with tickets how our product logs out them every
| minute, like when they closed laptop for a minute, went from one
| building to another or when their VPN simply lost connection
| while they were on a lunch. It's like hundreds tickets per day
| when normally it's 3-4 per week.
|
| And you can't really do anything about it, because "muh security
| standards", "we need to pass audit" and whatever.
|
| I actually want to sit down and calculate how much working hours
| of everyone involved are wasted every single day, day after day,
| it's completely bonkers.
| MBCook wrote:
| 15 _seconds_?
|
| I've never heard of anything like that. The recommendation I've
| always seen is 15 minutes.
|
| Seems like you could quickly run afoul of that just from a
| spotty Internet connection.
| carra wrote:
| I don't get why asking for a password multiple times is perceived
| as more secure. It's the same password. If an attacker was able
| to find it and input it once, surely they can do it multiple
| times too...
| stavros wrote:
| It's not about asking for the password, it's about expiring
| sessions frequently. Nobody is going to steal sessions, of
| course, but the cargo cult security remains.
| artursapek wrote:
| I was working at a crypto exchange for years and completely
| burned out on reauth. VPN session would die, 20 different SaaS
| products would log me out, constant interruptions. I'm amazed I
| never got phished.
| Henchman21 wrote:
| Remember when it was called SINGLE sign on? Emphasis on SINGLE? I
| mean, this whole idea has been such a mess forever. Why am I
| prompted to SSO hundreds of times a day?
| c17r wrote:
| As far as I've understood/remember SSO was logging on with a
| single ID and not logging on a single time.
| bithive123 wrote:
| You are describing "same sign-on", which is generally less
| desirable than single sign-on, but at least users only have
| one set of credentials to remember.
| cesarb wrote:
| > As far as I've understood/remember SSO was logging on with
| a single ID and not logging on a single time.
|
| What I remember is that the promise of SSO in the 1990s and
| early 2000s was that you would login only ONCE, onto your
| desktop. The operating system would use that login to acquire
| NTLM or Kerberos tokens, which would then be used to
| authenticate everything else: shared drives, printers, even
| web sites would be authenticated using that token (there's a
| way to pass through your desktop NTLM authentication to a web
| site, which IME is slightly annoying because it authenticates
| the _connection_ and not the request, and therefore needs
| keep-alive HTTPS connections to work correctly).
|
| Of course, that only really works that well in an homogeneous
| environment, for instance one in which everyone is using a
| few Windows NT versions on the desktops and all the servers,
| or one in which both the desktops and servers use the same
| specific proprietary Unix variant. What instead happened was
| the rise of heterogeneous systems, which do not share that
| common authentication mechanism. To make things even worse,
| each piece of software has its own separate authentication
| database, often (but not always) a pluggable one which might
| perhaps be coerced to forward the authentication attempts to
| another system, instead of directly using the operating
| system's centralized authentication mechanisms. AFAIK, you
| can still make it work, but it's a lot of work (for instance,
| IIRC forwarding NTLM credentials to web servers is disabled
| by default, and has to be manually enabled and configured to
| allow a given web server).
| marcosdumay wrote:
| > Of course, that only really works that well in an
| homogeneous environment
|
| It works if no monopoly abuses their position by sabotaging
| the standard.
|
| OAuth is getting a chance to work because neither Google,
| Apple nor Facebook are big enough, and they don't play well
| with each other. At least right now.
| notfed wrote:
| Well, for phones: phones can be lost or stolen. For desktops:
| an uncomfortable number tend to log in to public computers (eg
| libraries) without logging out and without understanding the
| implications.
| manish_gill wrote:
| Okta / Lumos are the biggest offenders of this.
| mook wrote:
| I suspect in that case it's to get their name in front of
| people's faces for marketing purposes. If things are actually
| seamless enough that you don't need to re-auth, you won't be
| reminded that their company exists.
| sangeeth96 wrote:
| I disagree with the general advise behind this, even when I'm in
| a household with trusted (most of the time) family members.
| Forcing a re-auth ensures that even if I forget to lock my
| machine/browser, someone can't snoop around. I want this to be
| the norm especially for my Macbook since for whatever reason, I
| might forget to lock or have some program running that'll force
| the laptop to not auto lock out (e.g. while downloading something
| that takes a long time) so I don't want someone to be able to
| seize that opportunity.
|
| It's the same reason I intentionally lock up apps with TouchID
| when there's remotely anything sensitive in there. I just don't
| want someone to be able to snoop if I forget to lock my phone.
|
| I'll say however, there should be easier ways to reauth in such
| scenarios. Like in my case, TouchID is not very disruptive to my
| work even if a prompt appears. I'll also say it's probably stupid
| to lock out when there's continuous activity (should lock based
| on inactivity period).
|
| The worst offenders in my experience are banking apps. They:
| - Force logout sometimes regardless of ongoing activity -
| Log out as soon as I close the tab - Log out when I press
| the back/reload button - After logging out, impose a
| mandatory inactivity period before I can login again (this is
| just the most idiotic thing EVER) - Use JS to block any
| kind of copy/paste operation on username/password fields -
| Never integrate with modern auth mechanisms, not even app-based
| TOTP! - Have crazy password expiry windows (like every
| quarter) and force password change when your previous password
| expires, regardless of how strong they are
| gs17 wrote:
| > Log out as soon as I close the tab
|
| For a banking app, I think this is fine. A lot of people aren't
| aware closing a window isn't logging out. The rest of that is
| dumb, though.
| sangeeth96 wrote:
| Nah, that is dumb too. I get what you're saying though. They
| could even ask and confirm if that's the case while logging
| in and let me have a persistent session on my own machines.
| gausswho wrote:
| Pretty rich coming from a company that only let's you create an
| account via SSO from the largest offenders of this.
| tayiorrobinson wrote:
| and also requires you to relogin every so often (to be fair
| it's 90 days not 24h)
|
| and you can just use a custom OIDC IDP with tailscale, for all
| 15 of us that have custom OIDC IDPs
| pfych wrote:
| It at least got me to learn how to self-host my own identity
| provider!
| gausswho wrote:
| Do tell!
| pfych wrote:
| I set up Authentik[^1] on my NAS in a docker container and
| went from there! Just had to add a .well-known webfinger
| file to my domain that pointed to the Authentik instance
| and it "just worked" with Tailscale.
|
| [^1]: https://goauthentik.io/
| radicality wrote:
| This has been bothering me for a while now (few years maybe ?) -
| websites repeatedly expiring my login for who knows what reason.
| Sure, maybe I can understand for high value trading platform or
| something. But no - most mundane sites which most people wouldn't
| at all consider sensitive, like HomeDepot / BHPhotoVideo /
| various online shops, will expire my session within like 24h -
| seriously, wtf. And significantly more sensitive sites, eg
| Meta/FB, are usually able to keep my auth for months/years.
|
| I haven't chatted about it with anyone, as I partly wasn't sure
| if something in my setup has changed and whether I'm a minority
| that fell into some constant reauth bucket. Or whether most of
| site owners have slowly been using lower and lower auth
| expiration, causing me a bunch of frustration and friction.
| bdangubic wrote:
| _...high value trading platform or something_
|
| those are actually ones that don't do stupid shit like expire
| passwords... I have had one password for vanguard... and I am
| in my 50's :)
| nathansherburn wrote:
| Wouldn't frequent reauth be beneficial for stolen sessions?
|
| E.g. If you set your session timeouts to a ~1 day then by the
| time your session cookies are up for sale on the dark web, they
| will be expired.
|
| The article doesn't mention this and it's the main reason I
| advocate for auth sessions that are as short as practical.
| throw14082020 wrote:
| If your session cookies were stolen, they can be stolen again
| and again too? Timeouts of 1 day assumes the cookies can only
| be stolen once.
| yusyusyus wrote:
| I have really strong opinions against the device-secured
| biometric stuff. On my own devices, I will never use it as it
| dramatically lowers my security posture.
|
| Further, the development of this ecosystem is to the exclusion of
| alternative OSes. Windows Hello and whatever apple wants to call
| their suite of biometric goo is elevating them to a place in my
| life that is unacceptable by virtue of the unwarranted trust
| granted to them.
| doodaddy wrote:
| Zero trust states that you don't implicitly trust an entity even
| if they were previously authenticated. So is this a critique of
| zero trust? More productive might be to say that we shouldn't
| blindly force reauth if our risk profile doesn't warrant it -
| just like any security mechanism.
| rob_c wrote:
| Please repeat this to every moron involved in security theatre.
| This is turning into a pain in the ass in the industry for no
| reason
| exabrial wrote:
| lol tell that to the people that want 15 day length TLS Certs.
| thwarted wrote:
| The MFA is getting out of control too. Go to vendor's
| tool/website, which uses some SSO method and redirects/prompts me
| to login with the SSO provider. Authenticate to SSO providers,
| which requires an MFA. Redirects me back to the vendor's
| tool/website, which prompts for its own MFA. And the vendor's
| tool's configuration has a security setting that requires all
| accounts to have MFA, even if they are authenticated via other
| means.
| MBCook wrote:
| I need to use SSO with MFA for something. So I sign in.
|
| Every once in a while, the token attached to that somehow
| expires. Which means that once I have successfully signed in
| (but before doing MFA) I am redirected to a DIFFERENT SSO
| system.
|
| I get to login to that and enter its MFA code.
|
| Having now completed all security requirements. I get to enter
| the MFA code for the original SSO.
|
| Double SSO. Double MFA.
|
| Boy don't we feel secure.
| bravesoul2 wrote:
| They dodged what to do about SSO and SAML. With SAML I don't
| necessarily know (as a coder) who will be the IdP or what
| protocol there will be for up to date authorisation info.
| hashstring wrote:
| There's another closely related one, changing passwords
| periodically.
|
| A lot of infosec authorities move away from this.
|
| However, I always wonder, does it make sense for an org to stop
| with periodic password resets if: 1. the org is not very capable
| in detecting all account compromises; 2. in practice, users leak
| their passwords (e.g. by getting phished) and not all of them
| lead to direct intrusions, some credentials are sold first and it
| may take weeks/months to cause an intrusion.
|
| I believe that in practice, forced password changes at least
| ensure that unknown compromised passwords will become outdated at
| some point in time, and I think that this is positive.
|
| Ultimately, I believe the best thing to do is to move to
| FIDO2-authentication here.
|
| But I do wonder what are other peoples takes on this topic?
| awesome_dude wrote:
| > I believe that in practice, forced password changes at least
| ensure that unknown compromised passwords will become outdated
| at some point in time, and I think that this is positive.
|
| password
|
| password1
|
| password2
|
| password!
|
| Password1!
|
| People get predictable on how they modify their passwords when
| that policy is instituted. Mostly because it's a royal pain in
| the ass to have to generate a new password AND remember it.
|
| That was one of the reasons that browsers (etc) began offering
| users randomly generated passwords that either the browser, or
| a 3rd party tool/service recalling the password on demand.
|
| However that then means the password to the browser/service
| becomes the unchanging password...
|
| > Ultimately, I believe the best thing to do is to move to
| FIDO2-authentication here.
|
| Passkeys are an attempt to circumvent this by having
| (effectively) a key that's attached to some physical device
| that the user must have access to to prove that they are the
| authorised user... but... people are circumventing those by
| storing them in cloud services... which means that the password
| to the cloud service is... yet again.. the weak point.
|
| > But I do wonder what are other peoples takes on this topic?
|
| For my money, the problem that's being attempted to be solved
| is unsolvable.
|
| In the physical world we determine identity by citing documents
| that verify the identity as far as a trusted institution like a
| government or bank is concerned, and those documents are
| predicated on documents that may or may not exist (birth
| certificates) and the assurance that those documents are for
| the person presenting them, from other people that have been
| through the same procedure.
|
| The digital world is even more difficult to prove identity
| with, because everyone looks exactly the same, ones and zeros,
| the order might be different from one person to another, but
| they're mutable.
| hashstring wrote:
| On the password1, password2, password2! flow, yes this
| happens and is bad, but not everyone is like this. I would
| say, any change (even a weak one) to a compromised password
| helps (even a bit). Because it requires attackers to test
| more passwords, providing more opportunity to detect them.
|
| I agree, on moving the weak point to certain service
| providers when doing this.
|
| Unsolvable: hm, but isn't the idea to make it more secure,
| not necessarily solve it completely?
| almosthere wrote:
| Finally someone said it. This is a relic from when a row in a
| database table for a session id cost about $400. I'm joking of
| course but that's what literally was on the mind of early
| internet engineers. The only company that fights this is Google
| and apparently tailscale.
| MBCook wrote:
| Microsoft does too. And Apple (but they're not big in
| enterprise, of course).
|
| Unfortunately lots of compliance people/orgs don't seem to want
| to give it up.
| eab- wrote:
| The same Google that makes you log in again on like every other
| `gcloud` call? By copy pasting your password into the shell
| prompt?
| redsymbol wrote:
| Zoom has been driving me nuts with this lately. I have to reauth
| with OTP 3 times a day, while logging in on the same computer on
| the same LAN with the same browser. I spend over $1500 a year
| with Zoom, and this issue is seriously making me think about how
| I can migrate to something else.
| vizzah wrote:
| I just can't stand email OTP. Before we had passwords, now we
| have passwords + email OTP. And doesn't matter if you forgot
| password - you will receive password reset to the same email. You
| already prove email ownership by resetting or using password -
| why sending another useless "security token" to the same email.
| Pure nonsense. Whoever designs all of this clearly has little
| idea of what they are doing :(
| TylerE wrote:
| I've kind of become a fan of the sites that don't even have
| passwords but just email you a "magic" link. If my account
| security is tied to my email why make me do extra song and
| dance if I'm gonna have to fish out an email for every login
| anyway?
| kevincox wrote:
| I despise this. With username and password my password
| manager just fills it in and it is one click to click
| "login".
|
| With email magic link I need to enter my email (it seems to
| rarely auto-fill for some reason), then wait (often it takes
| 10s for the email to be sent for some reason), then if I was
| logging in on something that isn't my default browser I need
| to copy+paste the link (often just clicking the link
| authorizes the source session but not always and you don't
| know what this site does so you need to do it to be safe).
| Now you are finally logged in but probably have two tabs
| open. Either you need to find the first one to continue your
| session (if it logged that one in) or close it and lose your
| history for that tab (and hope that the website actually
| maintained your target page which more often than not it
| didn't).
| radicality wrote:
| And on top of that, the session is probably gonna expire in
| less than day. I hate logging in to Anthropic because of
| this signin-email dance
| TylerE wrote:
| My point is that on sites that force email 2FA you have to
| do the email dance anyway. A username and password are
| basically theater.
| kevincox wrote:
| That's true. Although pasting the code into the existing
| browser tab is a bit smoother in my workflow. And at
| least the form autofills properly when they ask for email
| and password.
|
| I'd much prefer if they could just trust my password. But
| I know the unfortunate truth is that the majory of people
| just reuse a password across most sites. So these
| measures are intended to raise the baseline difficulty,
| not to improve the security of those with good habits.
| ddejohn wrote:
| Nothing tempts me so strongly to give up and leave a site
| than needing to use a magic link to get in.
|
| Sometimes it takes _minutes_. I have, on more than one
| occasion, given up on buying a product because of this. It
| 's actually insane to me how much effort sites put into
| preventing users from using them.
|
| I get it, most people are idiots with completely non-
| existent security hygiene, but man does it suck being
| punished because of just how low the common denominator is
| here.
| frankish wrote:
| My preferred workflow as well, but now many websites are
| starting to do this thing where you have to enter only your
| username, hit next, and then the password input shows up;
| however, the username only input breaks my password manager
| from trying to autofill! Argh
| tpxl wrote:
| Google has been doing this for years, if not over a
| decade at this point. Password managers have gotten wise
| about it though, so for some websites it actually works.
| radicality wrote:
| HomeDepot's is even crazier. You input just your email
| and hit Next. Then a button appears to "Send magic link"
| to login via that annoying method. And then there is a
| tiny text below: "Want to use a different login method?
| Wait 10s...9s...8s...". Only after 10s are you able to
| select a tiny text link "Use Password" to unlock using
| the password field
| jesseendahl wrote:
| FYI Home Depot supports passkeys which are a
| significantly better* sign-in user experience than magic
| links.
|
| *faster + easier (fewer steps)
| spacebanana7 wrote:
| Email OTP can be useful as a layer in risk based
| authentication.
|
| If someone tries to log on to your site from a low reputation
| VPN, throwing an email OTP challenge can give some assurance
| it's a genuine user logging in. Rather than a spammer or
| something like that.
| Freebytes wrote:
| Yes, it makes sense if the environment has changed, the
| device has changed, or if the person is logging in from a
| higher threat source such as a VPN IP address. However, if
| nothing changed, it is a waste of time in many cases.
| notfed wrote:
| I'm confused by this comment. Can you clarify exactly which
| poor design flow you're talking about?
| tpxl wrote:
| 1. Input username/password -> get email otp code.
|
| 2. Forget password -> get email for new password -> input
| username/new password -> get email otp code.
|
| The only actual security factor here is your [email, email
| password], everything else is just silly rigamarole.
| tzs wrote:
| Note that by doing it that way they don't have to have a
| special case for handling input of username/password when
| that password is a new password. Making security critical
| code simpler is generally a good idea.
|
| Whether it is worth annoying some users in the password
| reset case to avoid making the login code slightly more
| complicated is going to depend on your specific situation.
| runeb wrote:
| I read their point as why have passwords at all when the
| security is you having access to your email account.
| paradox460 wrote:
| The biggest pet peeve of mine in this area is "magic link"
| auth. Instead of letting you use a password and otp, which can
| be managed by a password manager, they send you an email so you
| can click a link to get into their app
|
| That's right, you have to wait for an email to arrive, make it
| through the spam gauntlet, and then click the link in the
| email, likely covered in trackers, just to get into a website
| or app. And here I thought people wanted to keep you in their
| site as much as possible
| arianvanp wrote:
| And then there is AWS which has 3 different products to log in
| and will sign out randomly and then redirect you to the wrong
| login page seemingly at random whilst in the middle of incident
| response
| montebicyclelo wrote:
| 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)
|
| 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).
| throwaway843 wrote:
| 1234abcd@ it is then for all my accounts.
| xp84 wrote:
| 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!"
| kobieps wrote:
| Preach. Gmail doesn't force password rotation, and one can
| just imagine the type of attacks they must sustain...
|
| Unfortunately corporate policies evolve at glacial
| speeds...
| Retric wrote:
| I'm doubtful a 30 digit minimum password is a meaningful
| improvement over a 20 digit password here. Meanwhile
| actually typing in very long passwords adds up across a
| workday/year especially with mistakes.
| xp84 wrote:
| I think if done right, typing that password should be
| more like a once a quarter exception rather than a daily
| occurrence.
|
| Granted - there are blockers to getting there. IDK why
| for example, macOS can't use Touch ID from a cold boot,
| that's stupid, at least when there haven't been too many
| failed attempts or anything.
| Retric wrote:
| Touch ID isn't that secure. It's fine for personal
| devices, but I wouldn't trust it alone in a government or
| cooperate environment.
|
| A ~1:50,000 error rate per finger added sounds fine, but
| lose a few laptops and have multiple valid fingerprints
| etc and the odds quickly look significantly worse. Or a
| janitor could end up trying to log into a significant
| number of machines etc.
| zimpenfish wrote:
| > macOS can't use Touch ID from a cold boot
|
| Isn't that because the Secure Enclave (the only place
| which contains the Touch ID biometric data) is locked by
| your password?
|
| "When a user's password is set up on an Apple Silicon
| Mac, the password is passed through a one-way hashing
| algorithm that produces a key used to encrypt the Secure
| enclave's key."[0]
|
| [0] https://blog.greggant.com/posts/2023/04/14/the-
| security-encl...
| imtringued wrote:
| You're only supposed to type your password at most once a
| day to sign into SSO.
| Retric wrote:
| Then how do you suggest authenticating not just in the
| morning but after lunch, going to the bathroom, any
| physical meetings, etc?
| TZubiri wrote:
| "Your password is too similar to your previous password"
|
| Hmm, how would you know that.
| tharkun__ wrote:
| By making it less secure. Like those auth schemes back in
| the day that sounded great in theory until you figured
| out that in order to implement them the provider had to
| store them un-hashed. No thanks.
| Uvix wrote:
| Don't you generally have to enter the current password to
| change it to a new one?
| TZubiri wrote:
| Interesting. I guess you could do it on the frontend by
| asking for old and new passwords simultaneously and
| sending the hashes to the backend.
|
| That said, it means that you can skip this check by
| hacking around the front end check haha
| throwaway843 wrote:
| Hash each character.
| bigfatkitten wrote:
| In the corporate space you should move away from passwords
| entirely.
|
| Smart cards have had pretty solid ecosystem support for the
| past two decades thanks to the U.S. Government and HSPD-12,
| and now we've got technologies like webauthn that make
| passwordless authentication even easier.
| majkinetor wrote:
| And require smart card, reader, drivers etc... nah
| bigfatkitten wrote:
| Or a yubikey, or a webcam, or a fingerprint sensor...
| imtringued wrote:
| Every work laptop I've used had a smart card reader
| directly built into it and I've never used smart cards.
| osigurdson wrote:
| In the enterprise, the cost of inconvenience to users is
| effectively zero. Perhaps even negative as security theater
| can be a pretty effective way to convince management that
| _something_ is being done.
| tharkun__ wrote:
| Don't tell them. I don't want to have to enter 30
| characters. And it does not help for the people you'd need
| it for anyway.
| 1234567890a1234567890@1234567890
|
| Better?
|
| No, just longer to type. You can't fix stupid people by
| making the life of non-stupid people worse.
|
| All you do is for non-stupid people to stop caring and do
| the easiest thing possible too.
| wycy wrote:
| Correct-horse-battery-staple!! is 30 characters and quick
| to type
| tharkun__ wrote:
| Which does nothing for the "stupid people". I.e. the ones
| that we put these rules into place for. They'll do what I
| posted instead (or something else easily guessable and
| the cycle continues - technological solution to a people
| problem, i.e. doesn't work)
| MrDrMcCoy wrote:
| That's why we recommend passphrases. That 30 character
| requirement becomes much easier when it's 3-4 words with
| a separater. Faster to type, too.
| tharkun__ wrote:
| Which does nothing for the "stupid people". I.e. the ones
| that we put these rules into place for. They'll do what I
| posted instead (or something else easily guessable and
| the cycle continues - technological solution to a people
| problem, i.e. doesn't work)
| pylotlight wrote:
| I would hate to be labeled 'stupid' everytime I don't
| want to type some 30 dumb characters everytime I login.
| How about no?
| tharkun__ wrote:
| Different difference ;)
|
| I also don't want to type 30 chars, when 15 _properly
| randomly chosen_ characters would suffice but the "stupid
| people" chose those 15 characters as "passwordP@55w0rd"
| and now everyone requires us to write 30 instead because
| it's "so much more secure" when they write
| "passwordP@55w0rdpasswordP@55w0rd"
| eru wrote:
| There's one weird trick to get people to have strong
| passwords (even if you force rotation): don't allow them to
| pick their own passwords. Randomly generate the passwords
| for them.
| pixl97 wrote:
| Also don't allow them to copy paste the password. And
| especially don't allow them to use any kind of password
| wallet. They will really love you for this and you won't
| get an excessive number of calls to reset forgotten/lost
| passwords.
| asveikau wrote:
| 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.
| mooreds wrote:
| 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).
| account42 wrote:
| Or just if they changed to a more secure hash algorithm
| themselves and want to upgrade users still on the older
| insecure one.
| RealStickman_ wrote:
| They could do that by comparing against the old hash and
| if it matches generate the new hash to store somewhere.
| blueflow wrote:
| This can be done at login time without the user noticing,
| as you have the plaintext password for a moment.
| mooreds wrote:
| Yeah, this is the best practice. We offer that in our
| product.
|
| But it's possible that you could follow the best practice
| and still force a reset. This could be because:
|
| * the customer or provider doesn't want to wait for
| everyone to log in
|
| * they've waited for N months and now there is a block of
| users who have not logged in yet and they think it is
| worth the user annoyance to just force them all to reset
| their password
| thousand_nights wrote:
| 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
| dcow wrote:
| 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.
| benlivengood wrote:
| That might apply to short passwords but passphrases are
| recommended and if they're >20 characters then brute
| forcing is not going to make meaningful progress toward
| them while we are all alive.
| fsckboy wrote:
| > _I don't believe it but_
|
| you have to believe it, it's true, you just think it's not
| the greatest threat or that the response to mitigate it
| (for example, using a pattern of temporary passwords to
| facilitate remembering them) would be worse than the
| disease.
| lurking_swe wrote:
| if it causes 90% of people to just enter a simpler
| password, out of frustration and "fatigue", then this is
| irrelevant IMO. Theory doesn't take into account human
| behavior.
|
| It's especially annoying when a company enforces these
| brain dead policies on employees. You want people to
| waste mental effort changing their passwords by 1 letter
| every 3 months, just to appease some IT manager? Give me
| a break lol.
|
| I'd rather have a long complex password that i remember
| and remember ONCE.
| eru wrote:
| For most people, writing (most of) their password on a
| piece of paper that they keep in their wallet would be
| pretty good security.
|
| Paper can't be hacked, and writing down the password
| allows for more complicated passwords. In case someone
| gets access to your wallet, you still keep a portion of
| the password not written down.
|
| (And if someone gets physical access to your stuff, you
| are hosed in general, because they can just install a
| keylogger. So even keeping your password fragment on a
| post-it under your keyboard would be fine-ish.)
| psychoslave wrote:
| It really depends on what password. At home our wifi
| password is on a paper, right there on the office board.
| If you landed in the room, I won't feel more in security
| if you need other actions to get the password out of me.
| NitpickLawyer wrote:
| > At home our wifi password is on a paper, right there on
| the office board.
|
| You probably should know that recent smartphones (the
| most likely devices to ask for a wifi password at home)
| have features to share a password right in the settings.
| iPhones will simply ask you (or anyone connected) to
| allow them, and androids have some sort of sharing
| enabled (via qr code generally).
| mrbungie wrote:
| That's what baffles me. Somehow security NEVER
| acknowledges that security theater, cognitive overload
| and constant friction makes users more inclined to make
| bad decisions, repetition over months make this even
| worse.
|
| Hackers need just one chain of tired persons to breach a
| system. Sometimes length(chain) = 1, that's when bad
| things happen.
|
| Anecdotal PS: I used to work at a bank and had to rotate
| my password monthly (sometimes even more, because there
| were unfederated systems that required another password,
| also with rotation). Eventually all my passwords became
| [short STRING] + [autoincremental INT]. We had MFA, so it
| didn't matter that much, but that makes it even more
| hilarious.
| somenameforme wrote:
| I think directly caused by the fact that at large
| companies, the best way to get ahead is to be seen as
| doing things. It doesn't matter if those things are
| completely harmful, so long as they sound good. With
| password changes you now have company wide visibility,
| with regularity, doing something that to somebody who's
| not thinking much would probably be suggestive of doing a
| very thorough job.
| dcow wrote:
| No, like I don't believe the math. It's not about not
| wanting to believe the math. I don't believe the
| mathematical conclusion is practically true even if there
| may be something theoretically interesting to talk about,
| like the monty hall problem.
| deathanatos wrote:
| > _I don't believe it but some hardcore types do._
|
| ... which is why the password has sufficient entropy such
| that it will take until the heat death of the universe to
| brute force it. We're 3 months closer to the heat death of
| the universe ... oh no?
| efitz wrote:
| Time based expiry ("freshness") is not about likelihood of
| brute force. Brute force prevention is handled by
| delay/lockout policy for online systems, and by password
| complexity rules or key length/cipher combinations. Nobody
| sane uses such rules in such a way that make brute force
| "slightly impractical"- security practitioners always
| choose lifetime-of-the-universe-scale complexity if given a
| choice.
|
| Instead, expiry is about "what are the chances that the
| secret has already leaked" and about choosing an acceptable
| compromise between rotation frequency and attacker loiter
| time - assuming that the system hasn't been back doored,
| let's put an upper limit on how long an attacker with the
| secret has access. And incidentally it also means that if
| you somehow fail to disable access for ex-employees, that
| lingering access will eventually take care of itself.
|
| But as the article points out, expiry has always been
| controversial and it's not clear that on balance expiry is
| a good control.
| numpad0 wrote:
| it's BSD /etc/passwd being 666 or something, so anyone
| could brute force it in 180 days, therefore passwords has
| to have max complexity within 8 bytes limitation and
| rotated every 180/2 days... who's even started using
| computers before it was patched?
| flerchin wrote:
| 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.
| clwg wrote:
| 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.
|
| [0] https://docs-
| prv.pcisecuritystandards.org/PCI%20DSS/Standard...
| throwaway72046 wrote:
| Your broker/bank still needs to do it, unfortunately...
| someone please fix this :(
|
| [0] https://www.finra.org/filing-
| reporting/entitlement/password-...
| Mtinie wrote:
| > If the password length is 12 to 15 characters, it will
| be valid for 180 days
|
| > If the password length is 16 to 32 characters, it will
| be valid for 365 days
|
| Madness.
| lofties wrote:
| I'm a big fan of "should not include profanity, words of
| a vulgar nature". It's not unthinkable my password
| manager comes up with a chain of letters that at one
| point will include "fuck".
| tiltowait wrote:
| This comment reminded me of a talk I saw[1] about Apple's
| password generation algorithm. Apparently (and
| unsurprisingly), they have a list of offensive terms the
| system is designed to avoid. I expect this is common-
| enough practice in most popular password managers, but
| probably not all.
|
| [1] https://www.youtube.com/watch?v=-0dwX2kf6Oc
| notpushkin wrote:
| It would be fun to make a passphrase generator that
| _always_ includes a profanity.
| HPsquared wrote:
| So long as they factor that into the "bits of entropy"
| calculation.
| WarOnPrivacy wrote:
| > I'm a big fan of "should not include profanity, words
| of a vulgar nature".
|
| On my first Wireguard testbed, WG's keygen dropped one at
| the front of the key. It remains my most treasured
| digital possession.
| seadan83 wrote:
| It kinda is good personal policy IMO for passwords you
| have to type to be positive affirmations. I used
| 'Fuckthis1!' for a moment; funny enough it was not the
| most moralizing thing to type all the time! OTOH,
| 'H@ppyH@ppyJoyJoy!!' was always a small mood lift.
| dmoy wrote:
| What's the scope of that? Not consumer accounts I
| imagine? I haven't had to change my bank account
| passwords in over a decade.
| free652 wrote:
| Jesus, it was so annoying so I kept appending a letter after
| each password reset -> a through z
|
| thankfully my current company let me keep my password for the
| last 3 years
| sakesun wrote:
| Password similarity rule was not enforced ?
| lytedev wrote:
| Doesn't enforcing this require storing the password in
| cleartext somewhere, which is a much more dangerous concept
| to begin with?
| eru wrote:
| In practice, that's probably how it's done. But in
| theory: no.
|
| Assume you keep the hashes of the last few passwords
| around. Then you can search in the 'neighbourhood' of the
| new password to check if any of this matches the old
| password's hash.
|
| By neighbourhood, I mean something like within a small
| edit-distance, where the kind of edits depend on what
| measure of similarity you want.
|
| If you only care about similarity to the last password
| (or care about that one specifically), then that's even
| easier: during the password change procedure you can have
| clear text access to both the old and the new passwords
| without storing them anywhere unhashed: because the user
| has just entered both passwords.
| apitman wrote:
| Wouldn't this be super slow if you're using a proper
| password hashing algorithm?
| eru wrote:
| Yes, if it takes one cpu second to hash a password, it'll
| take a while to try a few like this.
|
| You can do a quick check against the last password (which
| you have in clear, because it was just entered), though.
| sakesun wrote:
| Interesting perspective. Wonder why so many SaaS service
| currently enforce this.
| Mtinie wrote:
| Cargo culting.
| medvezhenok wrote:
| It probably requires some sort of decreased security (if
| the password hash is truly slow & secure, it would be
| hard to enforce dissimilarity); but there might be other
| methods that leak less than cleartext (like salting and
| storing hashes of overlapping/separate n-grams from the
| previous password and checking for number of similar
| n-grams; etc). Or as another commenter suggested checking
| all passwords within edit distance 1 (though if you can
| do that, your password hashing algorithm is likely too
| fast).
| tbrownaw wrote:
| Similarly of new vs current password is simple enough by
| just requiring the current password as part of the
| password change call. Which is a good idea anyway so
| someone can't just walk up and change your password if
| you forget to lock things over lunch.
|
| Similarly vs older passwords is what would be an issue.
| tiltowait wrote:
| > Similarly vs older passwords is what would be an issue.
|
| Which isn't unheard of, though it's been years since I've
| seen it.
| yardstick wrote:
| Not if they ask for the current password at the same
| time.
|
| https://news.ycombinator.com/item?id=44265372
| SAI_Peregrinus wrote:
| 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.
| repeekad wrote:
| I've personally experienced the password change require that
| "more than X characters be different than the old password"
| valleyer wrote:
| Um, that's a really bad sign...
| klysm wrote:
| To elaborate for the uninitiated, that means they are
| storing it in plaintext somewhere.
| mx_03 wrote:
| Is there any way to check that with non-plain-text
| password?
| jchw wrote:
| Actually it _can_ be trivial as long as you can require
| the user to re-type the current password when entering a
| new password; check hash first, then check edit distance
| with the entered "current password" (and, of course,
| promptly throw it away once you know the edit distance.)
| nullify88 wrote:
| Ohh. I guess that's what Windows does when a user wants
| to change their own password in the domain.
| mrspuratic wrote:
| It does more than that, it keeps a hashed password
| history (which used to be in the user attr
| ntPasswdHistory, but is now "somewhere secret" afaik)
| according to the value of ms-DS-Password-History-Length
| attribute. OpenLDAP keeps these (ppolicy overlay) in the
| user object.
|
| So, it can hash any proposed password and compare the
| history to make it's not been seen $recently (as an exact
| match, since it's comparing hashes).
|
| It could also perform some minor permutations of any new
| password, and do the same history check to make sure
| you're not just changing the first or last character or
| digit. I don't know if it does this, but it could.
| _moof wrote:
| Unless they ask you for your current password as part of
| the password change flow.
| mattmanser wrote:
| No it doesn't. Shows you how complicated all this is and
| how the un-initiated (including me) should learn to not
| give their two cents.
|
| When you do the password change it asks you for the old
| one, that's how it knows.
|
| So it asks for old + new, checks old is correct against
| the hash, and then compares old + new likeness.
|
| So it all happens in memory.
| rocqua wrote:
| No, you can do it safely. The idea is to have the
| password renewal process also ask for the previous
| password.
|
| This means the password changing method doesn't need to
| store a plaintext password, but still has access to the
| old plaintext password when changing. It's still not a
| great idea, but that's because nagging your users will
| see them choose worse passwords.
| _dark_matter_ wrote:
| Oh so trivially bypassable by changing your password
| twice.
| dspillett wrote:
| Not if the check is done client-side, so the plain
| password never leaves you local domain. Of course the
| check being done client-side means that it isn't
| difficult to skip if you are inclined to make a smidgin
| of effort.
| thih9 wrote:
| It can be done server side too, the old password can be
| sent along the new one and the server can verify it.
| deathanatos wrote:
| 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.
| bisby wrote:
| I once had an employer that required us to use passworded
| SSH, and disallowed SSH keys, because they couldn't enforce
| that the SSH keys were passphrase protected, so just turned
| that option off.
|
| They said it was a PCI requirement, or something.
| yardstick wrote:
| PCI requires multi-factor auth these days, so you'll
| likely find now the ssh password will be your password
| plus a OTP at the end.
| notpushkin wrote:
| Isn't there a way to ask for OTP after initiating the SSH
| session?
| mrspuratic wrote:
| Yes, via PAM, and this works fine with OpenSSH. But the
| couple of OTP implementations I've used are the same, you
| can either provide password and PIN or passwordPIN. In
| the end they get concatenated, passed to the next layer,
| and taken apart for checks. This lets it work with brain-
| dead http basic auth too, if you're unlucky enough to
| have to use that...
| mazone wrote:
| PCI DSS from 4.0 actually have something called
| customized approach for everything. If you can prove and
| the QSA agrees that you fullfill the goal of a
| requirement, you can be quite flexible. Example i am
| doing things like not using passwords at all and only
| passkeys, or only ssh keys protected by hardware security
| key etc. Together with agents trying to verify the
| devices connected are company owned and hardened in
| different ways. Your milage might vary depending on how
| good your auditor is but PCI DSS standard do have quite a
| bit of flexibility in it.
| yardstick wrote:
| Presumably at some point in your environment you are
| doing MFA? Just not at every step?
|
| Ie If someone broke into your office, opened computer,
| inserted the hardware security key, would they get in? Or
| is there something else non-physical going on? Like the
| initial login is password + security key, and you can
| demonstrate the ssh keys never leave the secured PCs etc.
| jerf wrote:
| This is not as illegitimate as it may sound to you. You
| may not hear about "getting someone's SSH keys" very
| often, because we only hear about "vulnerabilities" on
| places like HN and this isn't a "vulnerability" in any
| software.
|
| But getting someone's SSH keys and then running off and
| doing other things is a very normal part of any focused
| attack in which attackers use some foothold to start
| pivoting into your systems. It's one of the first things
| an attacker will check for, precisely because it's high
| likelihood they'll find one and high reward if they do.
| It's an extremely serious threat that you don't hear
| about very often, just like you may not hear about "the
| sudoers file left something open with passwordless access
| it shouldn't have and the attackers lifted themselves up
| to root from there" even though it's a major part of many
| actual incursions. I'm aware of multiple cases in which
| someone's passwordless SSH key played a part of the
| process.
|
| So that really is a legitimate problem and turning them
| off is not security theater but can have a real impact on
| your security posture. The problem is solved nowadays
| with adding other auth to the process like proving
| possession of a physical token as part of the login
| process.
| seadan83 wrote:
| > But getting someone's SSH keys and then running off and
| doing other things is a very normal part of any focused
| attack in which attackers use some foothold to start
| pivoting into your systems.
|
| Though, if someone gets that far, couldn't they also
| install a key logger on the users system? At that point -
| whether it's just password or a password enabled SSH key,
| anything the user does is all compromised regardless.
| jerf wrote:
| "Though, if someone gets that far, couldn't they also
| install a key logger on the users system?"
|
| There are a ton of situations where that is not the case.
| They may be using directory traversal from something else
| to read a key without even necessarily being _on_ the
| system. They may be on the system at 1am local time, and
| want to get in and get their job done before the user is
| even there. They may be on a server somewhere where
| someone left a key they shouldn 't have. The attacker may
| have gotten enough of a secret to compromise some _other_
| secret store where the key is being held. They 're
| probably on a system with user-level access only and that
| may not be enough to "just" install a keylogger,
| depending on how the system is set up and how the user
| accesses it. These are examples and not even remotely a
| full enumeration of all the possibilities. I won't tell
| you which ones, but some of these are things I've
| personally seen attackers take advantage of, so they're
| not just theory, either.
|
| When you're under _personal_ attack, not just getting
| popped by some vuln scanner scanning over the entire
| Internet, the situation becomes very different than a lot
| of people here on HN are used to. Ever been locked out of
| a system accidentally, then thought for a moment and
| strung together three other things to reach back into the
| system you were locked out of, like "oh yeah, I can push
| a software update to this automatic deployment system,
| which will run a bash script that checks the IP address
| and if it is this system restarts the ssh server, and so
| after 10 minutes we should be in"? Imagine someone who
| does that every day, all the time, as their full time
| job, and then imagine they're on a team of other people
| who also do it every day as their full time job, then
| imagine they've gotten a foothold into your system.
| Which, by the way, they immediately used to put a
| command-and-control client on your system, loaded with
| all kinds of exploits, and the ability to push arbitrary
| code to any number of systems at a time and all the
| tooling to use that as if they've been developing it for
| 20 years, which they have. What's the transitive closure
| of what they could work out how to access? The answer
| would probably surprise you.
| seadan83 wrote:
| I appreciate the additional insights, but the premise I'm
| pushing back on is whenever a SSH key is read, then the
| user account is by necessity compromised in order to do
| so. Given that level of a breach, there are myriad ways
| for an attacker to escalate privilege and exploit their
| access without worrying about a password on the SSH key.
| Namely, at that point, cracking the password on the SSH
| key is a tractable problem.
|
| > They may be using directory traversal from something
| else to read a key without even necessarily being on the
| system.
|
| At least on linux - to read the directory containing a
| SSH key requires the ability to also write to that
| directory, as the user. Therefore you can also write to
| '.bashrc' and all sorts of other places. I suspect
| Windows might have a larger attack surface, but
| nonetheless, a directory traversal that is able to read
| and write is also able to install a keylogger.
|
| > They may be on a server somewhere where someone left a
| key they shouldn't have
|
| Private key should never be transmitted over a network
| boundary. SSH key passwords can be bruteforced as well.
| Having a password on the SSH key, when the SSH key is
| somewhere it _really_ should never have been, is closing
| the barn door after the horses have left.
|
| > The attacker may have gotten enough of a secret to
| compromise some other secret store where the key is being
| held.
|
| Again, getting access to the secret is enough to also
| have write access and be able to install a key logger. A
| password on the SSH key still does not help.
|
| > They're probably on a system with user-level access
| only and that may not be enough to "just" install a
| keylogger
|
| If a person has enough access to read a SSH key, they can
| also install a key logger for at least that user account.
| They are equivalent levels of compromise, a user account
| having its SSH key read is already compromised.
|
| _edit_ : addendum: There are certainly attacks that can
| only read the contents of a system, with root that can
| read the full system. It's just odd to think about, since
| at that rate the SSH keys being on a prod system is
| already such a big no-no. SSH keys really need to live
| exactly just on the personal devices of the people who
| own those keys - EG: it should never be the case that say
| a SQL injection attack that gains root level read
| permission over everything on a filesystem can then ever
| read SSH keys - cause those keys should never be on the
| remote system to begin with. Putting a password on
| private keys that are then copied to servers _is_
| security theater; the keys ought to never be copied to a
| remote server to begin with.
| delfinom wrote:
| They do it because their IT departments are checklist
| monkeys with no actual brainpower there, AND/OR they have
| cybersecurity insurers that mandate it who also have nobody
| with actual brainpower working there.
| SAI_Peregrinus wrote:
| Whenever I don't have to type it, that's what I do. It's
| the login (or password manager password) needing this
| counterproductive crap that gets the "append a date"
| treatment. It's a 10-word diceware passphrase, only used
| for that login anyway, it's not getting breached if it's
| stored in even a remotely secure manner (even an unsalted
| hash would be safe).
| pcardoso wrote:
| I once wrote a script to change my password randomly X times
| and then back to my original password. Worked like a charm.
| claudex wrote:
| There are policies to prevent changing the password more
| than once a day to prevent that. I've encountered it in
| several places
| thih9 wrote:
| Fascinating. In other words:
|
| In order to force the user to change their password more
| frequently (long term), the user is prevented from
| changing their password too frequently (short term).
|
| I wonder whether the person who added that is actually
| confident that the benefits outweigh the drawbacks or is
| that a case of tunnel vision.
| eqvinox wrote:
| There are also systems that keep a history of old
| passwords just to prevent you from reusing one.
| jandrese wrote:
| I like the ones that not only keep a history of your old
| passwords but will reject any password that is _similar_
| to any of your 30 previous passwords, which means they
| 're storing either a plaintext or reversibly encrypted
| list of every password somewhere on the system. Talk
| about a goldmine for the hacker that dumps that database.
| rightbyte wrote:
| Ye. If the insane password gatekeeper shenanigans doesn't
| make you input your old password together with the new,
| you know they store your passwords.
| Rexxar wrote:
| Something like that could probably be implemented by
| storing multiple hash of some automatically modified
| version of the password. For example, if your password is
| "PassWorD" they can additionally store the hash of the
| lowercase version of the password. So if you change it
| from "PassWorD" to "paSswOrd", they will see it has the
| same lowercase hash than the previous one without knowing
| it.
| jandrese wrote:
| This doesn't seem practical at all. The combinatoral
| explosion would make the storage requirements impractical
| for everything but the absolutely most trivial cases like
| incrementing a number as the very last digit. Even in
| your simple example you're talking about storing 256
| different hashes just to catch one possible mutation on a
| way too short password.
| HocusLocus wrote:
| Password changed.
|
| Password changed.
|
| Password changed.
|
| Error at : broken pipe
| mx_03 wrote:
| Bad habits are hard to kill.
|
| Sometimes you just cant convince people that something is no
| longer recommended.
| viraptor wrote:
| 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.
| b0a04gl wrote:
| been thinking same every time it asks me to reset without
| warning. i just assume breach and rotate everything linked to
| that email. if it's not a breach and just some dumb policy,
| then congrats they made me waste 30mins securing nothing.
| brikym wrote:
| 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.
| SpaceNoodled wrote:
| It honestly forces me to keep a Post-It on my monitor with a
| hint to this season's new password suffix.
| olivermuty wrote:
| Most SOC2 vendors still require rotation, it is unbelieveably
| frustrating.
| vrighter wrote:
| Stuff like ISO27001 still demands it. We have to rotate
| passwords, against modern cybersecurity practice, in order to
| comply with an information security standard.
| rjgray wrote:
| ISO 27001 doesn't say this. The control implementation
| guidance (ISO 27002) specifically cautions against requiring
| frequent password changes.
| qualeed wrote:
| 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.
| Xss3 wrote:
| Hot take, password requirements are a necessity to prevent
| id10t errors.
|
| 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.
| afiori wrote:
| "password too long" for password shorter than a megabyte is
| the most idiotic error ever created.
|
| It only makes sense in HTTP basicauth and other system that
| keep plaintext passwords.
| efitz wrote:
| 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.
| tzs wrote:
| > 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?
| londons_explore wrote:
| 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.
| tzs wrote:
| So when they accept an invitation to give a lecture six
| months from now on the discoveries at the Gudme Hall
| Complex in Denmark how do they arrange to make sure they
| will show up?
| chillfox wrote:
| The requirements usually don't come from IT.
|
| 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.
| ToucanLoucan wrote:
| Just an unbreakable law of the universe.
|
| "Why did this stupid shit happen? Oh, it's money again."
| ajmurmann wrote:
| It's not money but inertia of very large systems. All these
| password changes cost money as well. If anything it's a
| market failure that insurance companies seem to have too
| little incentive to update their security requirements.
| This would likely be solved by reducing friction with both
| evaluating insurers in detail and switching between them.
| bunderbunder wrote:
| It's also a sort of moral hazard problem.
|
| If you, the person in charge of these decisions, allow an
| incumbent policy - even a bad one - to stand, then if
| something goes wrong you can blame the policy. If you
| change the policy, though, then you're at risk of being
| held personally responsible if something goes wrong. Even
| if the change isn't related to the problem.
|
| It's not just cybersecurity. I have a family member who
| was a medical director, and ran up against it whenever he
| wanted to update hospital policies and standards of care
| to reflect new findings. Legal would throw a shitfit
| about it every time. With the way tort law in the US
| works, the solution to the trolley problem is always
| "don't throw the switch" because as soon as you touch it
| you're involved and can be held responsible for what
| happens.
| leoc wrote:
| "No-one ever got fired for buying IBM" etc.
| ToucanLoucan wrote:
| I mean that was true about Boeing, right up until it
| wasn't.
| BitwiseFool wrote:
| 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.
| lesuorac wrote:
| > Turns out, this rule was not from IT. It was a
| requirement from the cybersecurity insurance policy the
| organization had taken.
|
| I wonder if some of these constraints are to try to find a
| way not to pay out on the policy.
| ang_cire wrote:
| It absolutely was/is.
|
| To bastardize Douglas Adams: For-profit insurance is a
| scam; breach insurance, doubly-so.
| lucideer wrote:
| > 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.
| BrandoElFollito wrote:
| 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.
| paradox460 wrote:
| IT seems to be a haven for minor dictators to enact their power
| fantasies
| ipython wrote:
| 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. "
| kwanbix wrote:
| I just joined a fintech company. It is so crazy, everything logs
| out daily, to login you have to input a complex password plus the
| 2FA, you have to run everything through a Citrix VDI. Really bad.
| nofunsir wrote:
| Only once a day? Sounds heavenly. Try every time you turn
| around and use your air-gapped dev PC for 5 minutes, while
| trying to keep a reference PDF from online up on your corporate
| PC to read.
| garyfirestorm wrote:
| I hate the corporate office 365. How many times on the same
| corporate laptop on which I log in from home do I need to reenter
| outlook password and 2FA.
|
| I seriously think ms365 login chain is straight broken Click here
| to sign in - enters userID and pass - thanks for logging out :o
| ExoticPearTree wrote:
| You should be angry at whoever set it like that. In O365 you
| can sessions last as much as you want.
|
| Currently MS recommends a 90 day window between MFA re-
| authentication for known devices/browsers you already
| authenticated on.
| notfed wrote:
| Here's 2 or 3 cents:
|
| - Websites should (in agreement with TFA) just remain logged in
| (at least for 24 hours). Let the OS handle it.
|
| - Public computers should only ever provide ephemeral login
| sessions. Everything cleared upon each login. Never persist
| anything to disk.
|
| - Personal computers _should_ reauth frequently, but should use
| adaptive authentication: i.e., password sometimes, and pin
| /fingerprint other times, where reasonable. Since "reasonable" is
| debatable, this should be configurable by the user at the OS
| level.
| WarOnPrivacy wrote:
| From the article: 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.
|
| For workstations, I like security keys.
| projektfu wrote:
| 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.
| osigurdson wrote:
| Google hasn't asked me to re-enter my password for years. If your
| users are the product this must make financial sense.
| aljgz wrote:
| 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.
| benrutter wrote:
| 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.
| jaydenmilne wrote:
| Microsoft has ruined their PC games with this. I hesitate to fire
| up Minecraft or Master Chief Collection these days because I just
| _know_ it is going to make me reauth for no apparent reason. I
| took 2FA off my Microsoft account because of this, so congrats.
|
| These are a video games, not a bank account! Please just let me
| have fun!
| candiddevmike wrote:
| Yea, it's nuts having to reauthenticate constantly on an Xbox,
| especially with a randomized password. They changed it recently
| where you can scan a QR code I guess, but whoever implemented
| that system is completely disconnected from reality.
| tlogan wrote:
| Sure. All true. But PCI compliance requires 90-day password
| rotation which might not be required if you're using multi-factor
| authentication (MFA). In other words, in the case of MFA, that
| requirement might be waived: and the operative word here is
| might.
|
| So, if you're pursuing PCI compliance people don't rely on
| assumptions or conditional language like might. Certainty is key
| when dealing with compliance frameworks.
| TheBicPen wrote:
| Very confused about this point:
|
| > Passwords, Face ID, Touch ID -- things that supposedly nobody
| but you can replicate, but which don't prove you're physically
| near a given device
|
| Password, sure. But the other 2 surely prove that you're both 1)
| the correct person and 2) near the physical device that scans
| your face/fingerprint. The article immediately follows that by
| saying that face/touch ID do both.
| b0a04gl wrote:
| that line "useless password expiration policies" kinda undersells
| the real damage honestly. it's not just about annoyance or people
| incrementing numbers. i've seen orgs where users literally email
| themselves passwords just so they don't forget the new one every
| 30 days. the entire system becomes hostile to secure behavior. no
| one talks about how these policies quietly push people _away_
| from good opsec habits. like the policy itself becomes the threat
| model.
| jillesvangurp wrote:
| A curious thing with security is that a lot of measures companies
| take aren't about your security but about liability and control.
| Most security theater is motivated by that. Your inconvenience is
| collateral damage to that. Apple and Google don't worry about you
| getting hacked but about you suing them after you get hacked.
| That's the risk they are mitigating. Or worse, you jumping ship
| to the competitor. They want you dependent on your account with
| them.
|
| So, when Google single signs you out mid meeting (has happened to
| me), they don't care about how stupidly annoying that is. That's
| just them asserting that if anything bad happens to you, it was
| your own fault and not their failing.
|
| And then a secondary thing that makes life even harder is that
| instead of working together they are considering single sign on
| mechanisms as control points that they can leverage to keep the
| relationship with 'their' users exclusive. So Google and MS both
| do very similar things but they don't trust each other's Identity
| Providers (IDP). That's not an accident. That's intentional. MS
| has been on a decades long mission to 'own' all logins, and of
| course they've been failing to get there just as long. Likewise,
| Google and Meta have been fighting over this as well. And the net
| result is that you don't have just 1 account to worry about but
| gazillions. That's why every silly little app has its own stupid
| email/password thing and why onboarding friction is the biggest
| hurdle to users adopting these.
|
| These are the primary motives driving this mess. Companies don't
| collaborate, so security stays complex and messy. It's also the
| reason that passwords (long discredited as a reliable way to
| authenticate) are still a thing. If we had effective federated
| IDPs like OpenID where everybody could use and IDP of their
| choice and use it to authenticate it with pretty much everything
| and the kitchen sink, you wouldn't be using passwords ever. That
| was envisioned as early as 20 years ago. Google, MS, Meta, etc.
| blocked every attempt to make that happen by never mutually
| trusting each other, or any other IDP not operated by them. They
| all implement some version of OpenID 2.0 (with enough differences
| to make supporting all of them a bit of a journey) but they
| deliberately don't whitelist any external IDPs and jealously
| continue to fragment the security landscape by guarding their
| walled gardens.
|
| They've been engaging with each other in backroom standardization
| attempts ensuring that the status quo is never allowed to change
| for decades. The latest move in this war: pass keys. Nice
| solution on paper. But you got to have the Google version of it.
| And the MS version. And all the rest. Sigh. Because, obviously,
| by design these will never delegate to each other. They trust
| each other even less than they trust you.
| flashblaze wrote:
| Might be tangent, but Cursor has this the worst. Each time you
| close the browser and open, you're logged out. I have no idea why
| they do this.
| latchkey wrote:
| Google Workspace defaults to making you sign in every 2 weeks
| unless you have a certain upper tier of paid account with them.
|
| Even worse is that if you try to search for the feature and click
| on it, it presents a page that unhelpfully returns 404.
|
| It's annoying AF.
|
| "By default, the web session length for Google services is 14
| days." https://support.google.com/a/answer/7576830?hl=en
| ianopolous wrote:
| Humans shouldn't generate passwords. ~0 people are good at that.
| Websites should just generate a password for a user, letting them
| regenerate as many times as they like until they get one they
| like (without breaking password manager based generation). A bit
| like this: https://peergos-demo.net/?signup=true
| baq wrote:
| ~0 people want to remember passwords. generating passwords for
| them without offering to securely store them in a password
| manager strikes me as misguided.
| ianopolous wrote:
| People should absolutely be using password managers where
| possible.
|
| A website doesn't have control over whether you are using a
| password manager though. This is about stopping the human
| from generating a password themselves, which will be
| terrible.
| baq wrote:
| I mean, at this point might as well drop the password
| requirement completely and send an email login link every
| time a user gets logged out and wants to log back in. It's
| how 'reset password' feature works for some people anyway.
| ianopolous wrote:
| Yep, if that's possible for your service that works. If
| the service doesn't want your email and/or doesn't have
| access to your data, e.g. an E2EE service where account
| reset is impossible, then that's not an option.
|
| The supposition for all this is that the service wants to
| use passwords for whatever reason. In that case, generate
| them for the user.
| hananova wrote:
| The previous company I worked for did this kind of frequent
| expiration, made for a good 2-3 days off every 3 months because I
| sure as hell wasn't going to set an alarm on the date.
| briffid wrote:
| I'm so tired of the enforced password changes, that I just write
| them on a post-it note now.
| perlgeek wrote:
| Stealing session tokens is a common technique to get around MFA,
| deployed by malware everywhere.
|
| I don't like it, but frequent reauth does limit the blast radius
| of stolen session tokens.
| jeroenhd wrote:
| Needless to say, this is an ad for Tailscale. I hate these short-
| lived sessions myself, but there are oftenreasons why they're
| there.
|
| The alternatives proposed are "just always check right before a
| sensitive action" and "use continuous verification". Both of
| which are much harder to pull off correctly than short-lived
| authentication sessions (unless you buy their product, of course,
| supposedly), especially on third-party services you don't control
| the source or manage the deployment for.
|
| Oh, and of course, "just make everyone lock their screens". If
| only it was that easy. If basic rules like that worked, we could
| ditch half the security measures we have for websites. What's
| next, "just use unique passwords of 20+ characters for each
| website"?
|
| Also, this is putting a lot of trust in solutions like Windows
| Hello. I can't speak for the security of Apple's implementation,
| but thanks to bad vendor implementations (including Microsoft's
| own!), Windows Hello hardware is full of security holes. At some
| point one company decided to take a look at a few of those
| devices [and found security problems in all of
| them](https://blackwinghq.com/blog/posts/a-touch-of-pwn-part-i/).
|
| Short token longevity also protects against one use risk
| Tailscale have a solution for: users logging in to their personal
| accounts on public computers. That's still an essential use case
| for people without internet access or computer access at home.
| Often these people are more vulnerable (homeless, very poor) so
| relying on them clicking the "log out" button on every website
| they're forced to interact with is not going to work.
|
| Kerberos (or buying what Tailscale sells) does offer a somewhat
| nicer authentication flow, but that still doesn't work reliably
| on every browser on every OS on every device and it requires
| people to follow basic rules like "lock your screen", which is a
| massive risk. Passwords will always work anywhere and their
| security can be somewhat enforced.
| LinAGKar wrote:
| Does that mean Tailcale will stop doing it? Currently they
| require you to log into every node and reauthenticate it every
| now and then, unless you disable key expiry.
| nottorp wrote:
| That's okay, soon we'll have 8 hour ssl certs to go with this
| crap.
| willis936 wrote:
| I litigated the "sign back into SSO and every downstream login
| every four hours" with my IT team. They held their ground. So
| much money is being lit on fire with the time wasted.
| ajsnigrutin wrote:
| OnShape (web based 3d editing software) is like this. They have a
| free tier with public-documents-only option, and it's same there.
|
| Open the page... you have to log in, no way to remember you.
| Sure, you save your password in the browser, but unless you then
| also click into one of the input fields, the login button is
| disabled. Then you work on some 3d stuff, export the file, send
| it to the 3d printer, some time goes by, browser still open, you
| get the object, and the holes don't line up, you forgot the wall
| thickness in the measurements, calipers, yep, 3 more
| milimeters... open onshape tab, nope, you've been logged out. I
| didn't even close the goddamn window/tab, it's a free account
| editing a public document.
| btbuildem wrote:
| > Consider enforcing automatic screen lock when you walk away
|
| The corpo "security" dingbats force this on our work machines via
| profiles -- can't control how long before the screen locks. Thank
| goodness for the Amphetamine app. I'm not typing in my password
| every time I stop to think for two minutes, you can fuck all the
| way off with that.
| Nextgrid wrote:
| If you're using a Mac, I find the fingerprint sensor helps a
| lot.
| phkahler wrote:
| No, but it's a good excuse to require MS authenticator on my
| phone...
| tom_m wrote:
| I don't know, I still think it's a good idea to change passwords
| every so often. At the rate databases get leaked, you can't
| always rely on the strength of the hash and the time it used to
| take to crack given hardware getting faster and faster. Yes it
| can cause a minor inconvenience if locked out, but that's better
| than the alternative depending on what that system was.
|
| But...worry not, we're about to embark on a world with a whole
| lot less security now thanks to AI and laziness.
| Aissen wrote:
| OWASP still recommends regular expiration:
| https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...
| temporallobe wrote:
| This kind of goes along with my ongoing pet peeve about DX in
| general. There are very few organizations I've worked with that
| actually care and put their devs first. Case in point, I worked
| on a contract a few years ago with very frequent reauths where
| you had to enter your PIV card PIN about every 30 min. Obviously
| something was not configured correctly, but when we complained we
| were told that that was their security policy and to go pound
| sand. It made everyone so frustrated that productivity took a
| huge nosedive. I remember one day I was in the middle of trying
| to analyze something very tedious and having anxiety about the
| next time that dialog would prompt me for my PIN. Sure enough it
| happened, and I just gave up. I left my laptop, took a walk, and
| did nothing for the rest of the day. Eventually someone important
| petitioned for us and it was fixed, but I can't begin to
| calculate how much money this wasted in terms of unproductive
| contract hours.
| taniks1618 wrote:
| I very much agree with this article. But many companies are still
| under the idea of a complex password, instead of a long one. A
| "secure" password is not random character vomit. A secure
| password is a pass-phrase with multiple words and characters
| intermingled.
| einaralex wrote:
| Looking at you Beatport!
| tacitusarc wrote:
| A minor recommendation: remove the word "just" from the following
| paragraph.
|
| > At Tailscale, we believe in security that's adaptive,
| intelligent, and actually useful -- not --just- security theater.
| jandrese wrote:
| IMHO there are only 2 requirements for a good password:
|
| 1. It must be close to impossible for a computer to guess.
|
| 2. It must be easy for a human to remember.
|
| Virtually all password policies focus exclusively on point #1,
| with the vast majority just giving cargo cult instructions
| without really understanding the state of the art. Almost nobody
| puts any emphasis on point #2, which is arguably more important
| as it is the source of most breaches. If a person can't create a
| password, ignore it for a week, and then remember it immediately
| for the next login it's a bad password. This is where
| requirements like "no more than two characters from a character
| set (lower case, upper case, numbers, punctuation) in a row" are
| actively counterproductive. If the password has to be so
| convoluted that the user is forced to write it down then you've
| undermined your own security. Worse, it means the help desk will
| be forced to reset many many passwords which increases the
| chances of an impersonation attack succeeding.
| benced wrote:
| Funny because tailscale arbitrarily expires tokens on machines
| and doesn't expose a way to see token age to the user (but does
| allow your IT admin to renew a token).
___________________________________________________________________
(page generated 2025-06-13 23:00 UTC)