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.
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.
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.
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
> 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.
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.
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.
> 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.
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.
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.
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.
Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.
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
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.
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
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.
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.
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.
It definitely improves speed. Crypto algos are slow, but they are not slower than a TCP roundtrip. Even a memory database is not generally running on the same machine, so there is still a round-trip cost vs a JWT. Also, although it doesn't need to be the same DB, it adds more complexity to store such a key in a different DB than your actual user data (where the original auth logic is coming from).
Then don't hit the SQL DB directly, cache the tokens in memory. Be it Redis or just in your app. Invalidate the cache on token expiry (Redis has TTL built in).
And now I need to invalidate the cache if the key is invalidated. Also this cache cannot be updated/invalidated atomically, like I can if I'm just storing a refresh key in the SQL db. Caching in Redis is more complex and more prone to error than access/refresh token systems.
Dude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence.
Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all your requirements.
I can have it both ways, that is the entire point of the refresh/access token system. The access tokens are used for 99% of requests (every request except "refresh" requests) and I am not persisting them anywhere – there is no cache/db read. It is a quick, CPU-bound check to decrypt the token, no i/o required.
Your newly proposed solution sounds much more complicated than the above.
Ah right, my apologies, I seem to have misunderstood here. For some reason I thought your initial comment was narrowly discussing the issue of DB load in a system that doesn't use refresh tokens.
Upon re-reading the thread context I have no idea why I thought that. Yes of course, refresh tokens are the best solution
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.
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.
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.
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.
Frequent reauth only makes people figure out hacks to work around it.
Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works
Because much of what passes as "security" is a bunch of theater.
> SMS gets forwarded to e-mail, TOTP codes get sent over Wechat,
Here we are deep into 2FA land. Where you have institutions blocking SMS/MMS to IP telephony because they want to capture real people (and this locks out rural customers). Using your cell phone was never a suitable 2nd factor and now it is evolving into a check to make sure you're not a robot/script.
Passkeys are adding another layer to this... The police department getting a court order and forcing you to unlock your phone and then everything else is coming. Or here if you live in some place with fewer laws.
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.
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
You say users don’t notice much of this - I disagree. I had to authenticate with our SSO provider 9 times yesterday (I started counting because it’s getting so frustrating). All on the same device; once on initial login, once on VPN connect, once to the SSO dashboard, twice (!) to Microsoft for Outlook and Azure access via our IDP, once for perforce (no 2FA required thankfully) and three times to Jenkins because it doesn’t remember the OIDC token if you close your browser. IT say it’s normal and here I am spending 10 minutes a day waiting for my Authenticator app to log in.
I work on a corporate controlled machine, with a corporate VPN app and custom certificates installed. I’m pretty sure it knows when I sneeze, but yet remembering who I am for more than 15 minutes seems out of scope.
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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).
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...
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.
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).
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.
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.
> 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.
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.
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.
> 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.
We just completed our PCI audit for the year and the auditor is adamant that this is the requirement.
Perhaps they're wrong, but fighting with the auditors is like wrestling with pigs, best avoided.
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.
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.
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
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.
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).
>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.
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.
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.
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.
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.
> 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.
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.
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.
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.
I hate Apple products for this.
I see this pattern across all apple products - not one.
On my mac, I setup my touch ID, and log in to my Apple account on the App Store. Time and again, when I try to install apps, it keeps repeatedly prompting for my password, instead of letting me just use my touchID. This applies to free apps as well, which is again silly beyond what is already enough silliness.
I briefly see this on my spouse's iPhone as well. Almost felt like Apple hasn't changed a bit after all these years. It keeps fucking prompting for password over and over, randomly when installing apps. although the phone is secured with a touch ID.
This happens especially when you reset the phone and starting from scratch - it keeps prompting for the Apple password again and again.
And it's even worse if you are accessing Apple services on a non-Apple device. No matter how many times I click "trust device" when logging in to icloud.com it will still make me do the password + one-time code song and dance the next day.
Another pointless annoyance - if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password. Why?? And of course when you're on that prompt there's no way to open your password manager without cancelling out of it entirely. Makes for a fun experience at the checkout counter...
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.
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.
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.
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.
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.
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).
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.
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.
> 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.
I don't disagree, and I appreciate your keeping the conversation on-topic, but that's very much an incomplete picture. I think our modern app ecosystem as a whole conditions users to click "OK" reflexively. A hypothetical app wants permissions for your camera, location, and file storage. If you click OK, you can use the app. If you don't, some functions may not work. I think the average user gets caught in the desire to use an app for its intended purpose and the need to tinker with settings - which they may or may not understand - if they want to use that app securely. So, they just say OK to everything.
Of course, that's not the only situation with these push notifications. MFA fatigue attacks are a real thing, hammering the user with as many notifications as they can in a short time. Maybe the user assumes it's a bug, maybe they try to deny the push notification but eventually hit the wrong button, maybe they just want it to stop; it's not so much about exploiting user conditioning as it is assuming that if you force people into an unfamiliar situations, that some of them will eventually slip up.
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.
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.
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.
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.
related pet peeve: faceid is often (but unpredictably) really slow - like, I'm looking at the phone and in a hurry and would prefer to enter my pin but touching the screen goes back to the lockscreen, and swiping up starts faceid again.
> if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password.
What? FaceID will prompt for a re-try. Always. It will never fail once and then refuse to do FaceID.
If you can't figure out to lift the sunglasses off your face or sit up in bed for a second, that's not anyone's fault but your own.
Also, FaceID will never fall back to your account password for Apple Wallet transactions with a physical credit card reader.
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.
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.
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.
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... :-/
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.
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.
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
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.
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.
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 ...
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".
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.
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.
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.
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.
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.
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.
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.
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.
Phrase-based passwords are far easier to type and remember than random gibberish at 20 characters. I would much rather type a 10x longer sentence than type random characters, even on mobile. It's far easier to validate a passphrase because we, as humans, will notice mispellings quite fast. It's only difficult if you're not english speaking, or have dyslexia - where I would refer you back to the original point: you don't need a 50 character password. Ever.
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?
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.
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.
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.
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.
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.
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.
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.)
Are you sure you have enabled TouchID for purchases (Settings > Touch ID & Password)? If you don't, I guess it might prompt for passwords. I just need to authenticate once on restart but can pretty much use TouchID almost all the time after that anywhere auth is expected.
I have on mine, and yes it always prompts for a password anyways if I haven't used the App Store extremely recently (like within the past 24 hours).
I'd assume it's a straight-up bug on Apple's part, but they haven't fixed it for years and years, so at this point I think they're just being sadistic.
Because yes TouchID works everywhere else. This is App Store-specific. It's literally the only reason I keep a password manager app on my home screen, since it autofills everywhere else but not there so I have to always copy my Apple password manually from the password manager app.
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.
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.
I wonder if what you're seeing is geographic. I'm in Scandinavia and authentication lasts a decent while for me, with strict settings. I tried a few things with my SO's iPhone and iPad and they behaved the same.
> it 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.
At least for Apple I can see this being a way to avoid account lock out. Your Apple ID password would otherwise almost never be used so when people finally go to factory reset their device or something they would realise they long since forgot their password and now have an expensive brick.
I 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.
I think free apps are still scrutinized because they don’t want attackers to install known-compromised apps or trackers. Like a controlling spouse sneakily face IDing a sketchier Life360 while “making a phone call”.
Could be wrong, but that’s the only thing I can think of.
For sure. They don't really need to protect your credit card in that way, since if a silly kid bought $300 worth of Super Gems or installed a paid app (are there even any normal paid apps now?) Apple has full control, if you call support, to just say "nope" and take the money back and refund you. But sneaking any random app onto the phone of someone else for nefarious reasons is something Apple is super paranoid about.
Which is also why I will get random popups every few weeks for the rest of my life saying things like "Google Maps has been using your location for 179 days." with a "scary" little map of where I've been. No amount of saying "yes, i meant to do that" can convince Apple that it's intentional.
Indeed. And I have several Apple mobile devices around the house that just decide they need the password entered just for general reasons, without any specific triggering action! And those pop up modal dialogs in front of what you're doing (super dangerously, as that teaches users that it's plausible that they might be on the Web, and get a popup asking them to enter a password, that they should click on to lead them to a password-entering place!)
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.
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
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.
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.
this is only because of all the lawsuits about apple store chargebacks because they allowed kids to make purchases.
article is shot Enterprise software and you're talking about games and predatory dark patterns in consumer devices. or do you company distribute software to employees via app store?
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...
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.
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.
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.
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.
Came here to say this, upvoted. Both Apple and Microsoft have "corporate IT" settings that can be used to turn off "trust my device", "remember me", etc. Auditors and CISO offices tend to lean in on checklist security - in other words it doesn't matter if it's actually more secure, it only matters that it passes the checklist audit. Many of the settings are user hostile and incentivize users to work around them. Making real security worse of course...
I’m not sure how one changes the mind of auditors who are just there for a job and who aren’t actually interested in the field? IME, the only auditors who are knowledgeable are those overseeing the folks with checklists — and they rarely seem to have the time to correct the folks they’re overseeing.
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)
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.
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.
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.
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.
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.
Makes sense. The thing people forget about SOC2 is that it's very not-technical and very much so written by CPA's. No two SOC2's are identical. Hell the same companies SOC2 done by different auditors will be different.
Saying "The United States of America National Institute of Standards and Technology says X on page 423 of Special Publication 800-53 revision 5" is a really awesome "We're doing things the RIGHT way".
No, you’re right. Though I think there’s definitely a gap between standards bodies like NIST and the AICPA or whoever sets the SOC2 standards these days. I think some of the answer is just momentum. Customers have come to expect it of their vendors, specifically because it is security theatre, something they can point to if anything goes wrong.
> 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.
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.
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
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.
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.
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.
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.
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.
538 comments
[ 3.3 ms ] story [ 157 ms ] threadApple's developer services, such as App Store Connect, actually use session cookies. 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.
Hence... Session cookie, even if set without expiration date
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.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
If you try to communicate with other people using that definition of "session cookie", your communication will fail.
Most sites do not use session cookies for auth, they use persistent cookies.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
Validating a token requires running encryption level algorithms to check the signing signature, and those are not fast.
UserID -> token is a tiny amount of data.
Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all your requirements.
Your newly proposed solution sounds much more complicated than the above.
Upon re-reading the thread context I have no idea why I thought that. Yes of course, refresh tokens are the best solution
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.
Passwords get written down, passwords end up in Google Docs, Arduinos with servos get attached to Yubikeys, SMS gets forwarded to e-mail, TOTP codes get sent over Wechat, the whole works
> SMS gets forwarded to e-mail, TOTP codes get sent over Wechat,
Here we are deep into 2FA land. Where you have institutions blocking SMS/MMS to IP telephony because they want to capture real people (and this locks out rural customers). Using your cell phone was never a suitable 2nd factor and now it is evolving into a check to make sure you're not a robot/script.
Passkeys are adding another layer to this... The police department getting a court order and forcing you to unlock your phone and then everything else is coming. Or here if you live in some place with fewer laws.
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.
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.
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
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.
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 :)
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.
Fortunately these days most services will cache your work.
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.
Then they should configure their browser to log them out. Not hope that every site has good settings for their niche scenario.
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.
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.
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.
Where do you live? That’s absolutely not my experience.
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.
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.
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.
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).
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)
Edit: jjav beat me to it below, confirming it is.
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.
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.
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.
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.
We just completed our PCI audit for the year and the auditor is adamant that this is the requirement.
Perhaps they're wrong, but fighting with the auditors is like wrestling with pigs, best avoided.
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.
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
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.
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).
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.
Very useful for people who work in trains and stuff: their neighbors can't see things
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.
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.
It's also risky to have the primary password credential transmitted instead of temporary tokens.
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.
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.
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.
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.
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.
logging into phishing links would make more people pause if they didnt have to login constantly to get work done
On my mac, I setup my touch ID, and log in to my Apple account on the App Store. Time and again, when I try to install apps, it keeps repeatedly prompting for my password, instead of letting me just use my touchID. This applies to free apps as well, which is again silly beyond what is already enough silliness.
I briefly see this on my spouse's iPhone as well. Almost felt like Apple hasn't changed a bit after all these years. It keeps fucking prompting for password over and over, randomly when installing apps. although the phone is secured with a touch ID. This happens especially when you reset the phone and starting from scratch - it keeps prompting for the Apple password again and again.
Another pointless annoyance - if Face ID fails when making a payment or installing an app (like it frequently does for reasons like sleeping in bed or wearing sunglasses) it won't fall back to PIN but ask you to enter your Apple account password. Why?? And of course when you're on that prompt there's no way to open your password manager without cancelling out of it entirely. Makes for a fun experience at the checkout counter...
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.
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.
Of course, that's not the only situation with these push notifications. MFA fatigue attacks are a real thing, hammering the user with as many notifications as they can in a short time. Maybe the user assumes it's a bug, maybe they try to deny the push notification but eventually hit the wrong button, maybe they just want it to stop; it's not so much about exploiting user conditioning as it is assuming that if you force people into an unfamiliar situations, that some of them will eventually slip up.
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.
The rest of the world manages to keep them operational.
Then most set the auto-close duration equal to this minimum open duration and you get this appearance of buttons doing nothing.
What? FaceID will prompt for a re-try. Always. It will never fail once and then refuse to do FaceID.
If you can't figure out to lift the sunglasses off your face or sit up in bed for a second, that's not anyone's fault but your own.
Also, FaceID will never fall back to your account password for Apple Wallet transactions with a physical credit card reader.
I 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.
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... :-/
> It's my device.
There is your dissonance.
Unless it's related to advertising. Then it works flawlessly and sometimes survives device transfers and factory resets.
-Jeff Hammerbacher
[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/
I feel that Meditations on Moloch should be mandatory study for anyone who lives in a society.
Windows 95 had this shit figured out on systems running a 486 and 6MB of RAM.
Oh, you double clicked to make it bigger? How about making it postage stamp sized in the bottom left of a different monitor...
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 ...
Apple changed this a few years ago, because of a potential security venerability: https://imazing.com/blog/ios-backup-passcode-prompt
So Apple wants me to type in my 50+ character password every time I use the App Store app. It’s such a pain.
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.
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.
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.
- 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.
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.
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?
I just have to trust their security model to not allow random apps to pop up and issue those prompts.
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.
iCloud is the only login that regularly breaks biometric ID functionality, and it's super annoying.
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.
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.
As you guessed, most of those aren't businesses and we need them more than they need us.
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.
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.)
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.
I do not run into this at all across my apple products.
It seems like insane friction for something that is making them a lot of money
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
Could be wrong, but that’s the only thing I can think of.
Which is also why I will get random popups every few weeks for the rest of my life saying things like "Google Maps has been using your location for 179 days." with a "scary" little map of where I've been. No amount of saying "yes, i meant to do that" can convince Apple that it's intentional.
The Mac pops those up too, now. Utter insanity.
How is this a thing?!
Same with the forced emails you get ANYTIME you login to iCloud via web.
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.
article is shot Enterprise software and you're talking about games and predatory dark patterns in consumer devices. or do you company distribute software to employees via app store?
It 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...
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.
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.
The same web app stays logged in forever in my mac and I access both of them with the same time intervals.
But at least it makes me reauth.
Then you get outcompeted by a company with no security at all, which is twice as efficient as you until they get hacked.
Ideally we should use the word “waste” to narrowly point at activities that are entirely pointless. Like requiring password rotation every 7 days.
It seems like none wants to actually justify their decisions to auditors as its more time critical when the audit happens.
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".
I'd say you want to send these articles to the people writing such guidelines.
What am I missing?
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.
They haven't found the setting for mobile yet, so I might just stop using desktop teams.
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
Computer security has a problem.
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.
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.