[HN Gopher] Frequent reauth doesn't make you more secure
___________________________________________________________________
Frequent reauth doesn't make you more secure
Author : ingve
Score : 435 points
Date : 2025-06-12 19:05 UTC (3 hours 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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)
| 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.
| 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.
| 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.
| 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).
| 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 ; )
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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".
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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...
| 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.
| 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.
| 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.
| 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.
| 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.
| 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).
| 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.
| 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!
| 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.
| 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.
| 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.
| 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?
| 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.
| 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
___________________________________________________________________
(page generated 2025-06-12 23:00 UTC)