Frequent reauth doesn't make you more secure
tailscale.com
tailscale.com
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
https://pages.nist.gov/800-63-3/sp800-63b.html
Or by Microsoft
> Password expiration requirements do more harm than good...
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/p...
But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).
1234abcd@
1234abcd@1
1234abcd@2
1234abcd@3
This is a better use of the finite practical appetite for complying with policies than the idiotic "forcibly change it every 90 days" + "Your 8 character password needs to have at least one number, one uppercase, and one of these specific 8 characters: `! @ # $ % ^ & *`"
By the way, to quote Old Biff Tannen, "oh, you don't have a safe. GET A SAFE!"
Unfortunately corporate policies evolve at glacial speeds...
Granted - there are blockers to getting there. IDK why for example, macOS can't use Touch ID from a cold boot, that's stupid, at least when there haven't been too many failed attempts or anything.
A ~1:50,000 error rate per finger added sounds fine, but lose a few laptops and have multiple valid fingerprints etc and the odds quickly look significantly worse. Or a janitor could end up trying to log into a significant number of machines etc.
Isn't that because the Secure Enclave (the only place which contains the Touch ID biometric data) is locked by your password?
"When a user's password is set up on an Apple Silicon Mac, the password is passed through a one-way hashing algorithm that produces a key used to encrypt the Secure enclave's key."[0]
[0] https://blog.greggant.com/posts/2023/04/14/the-security-encl...
Hmm, how would you know that.
That said, it means that you can skip this check by hacking around the front end check haha
Smart cards have had pretty solid ecosystem support for the past two decades thanks to the U.S. Government and HSPD-12, and now we’ve got technologies like webauthn that make passwordless authentication even easier.
1234567890a1234567890@1234567890
No, just longer to type. You can't fix stupid people by making the life of non-stupid people worse.
All you do is for non-stupid people to stop caring and do the easiest thing possible too.
I also don't want to type 30 chars, when 15 _properly randomly chosen_ characters would suffice but the "stupid people" chose those 15 characters as "passwordP@55w0rd" and now everyone requires us to write 30 instead because it's "so much more secure" when they write "passwordP@55w0rdpasswordP@55w0rd"
There are different attack vectors. Yes, 15 random chars is sufficient if random, but recalling and typing 15 truly random characters is a big challenge for most everyone.
You shouldn't be having to remember and type your password for Hacker News, for Gmail, or your bank, ever, not even one time.
By making them 30 characters, you're ensuring one of two things:
A. Users at least use a passphrase such as "my dad liked to drink 6 packs of Miller Lite" which is brute-force-proof so, that's fine
B. Users who aren't masochists use a password manager properly and never have to even see their password let alone type it.
That's it, that's the whole endgame. By keeping passwords short enough to memorize and type, you're just enabling people to use P455w0rd. And if you think that only impacts stupid people, most people are stupid and many of them are in charge of keeping your data (and infrastructure, and government, etc) safe. You need them to be protected, to protect you.
Users are not "at least using a passphrase". They will do the simplest thing ever.
What happened when people used the password "123" and we added "Must have at least 8 chars"? They make it "password".
What happened when people used the password "password" and we added "Must have one upper case char"? They make it "Password" or "passworD".
What happened when people used the password "Password" and we added "Must have one number"? They make it "Password1".
What happened when people used the password "Password1" and we added "Must have one special char"? They make it "Password1!".
Guess what happened when people used the password "Password1!" and we added "Must be 30 chars long"? They make it "Password901234567890123456789!".
(or anything else stupidly easy based on whatever password they used to have anyway)
As in, you are missing the point I'm making. You cannot solve a people education problem by adding more and more "stringent" requirements. You need to educate them. You need to make them understand why it matters. Only then might they actually care enough to use a proper passphrase like you suggested.
In that sense I do agree with you that using a password manager is the best most people can do. I use one at work and it's a game changer. But I only use it, because it's provided by work and thus it's free for me. If they didn't provide it, guess what I would do too? If they have obnoxious rules, then I will thwart them any which way makes it easier for me. So my "change your password every 30 days and it can't be one of the last 8" password of course was my last password but it went up to <lastPassword>8 until I went to <lastPassword> again.
If a site owner knows that certain accounts are part of a database breach or something, a reasonable step would be to force the users to change the password at next login.
But it's possible that you could follow the best practice and still force a reset. This could be because:
* the customer or provider doesn't want to wait for everyone to log in
* they've waited for N months and now there is a block of users who have not logged in yet and they think it is worth the user annoyance to just force them all to reset their password
you have to believe it, it's true, you just think it's not the greatest threat or that the response to mitigate it (for example, using a pattern of temporary passwords to facilitate remembering them) would be worse than the disease.
It’s especially annoying when a company enforces these brain dead policies on employees. You want people to waste mental effort changing their passwords by 1 letter every 3 months, just to appease some IT manager? Give me a break lol.
I’d rather have a long complex password that i remember and remember ONCE.
Paper can't be hacked, and writing down the password allows for more complicated passwords. In case someone gets access to your wallet, you still keep a portion of the password not written down.
(And if someone gets physical access to your stuff, you are hosed in general, because they can just install a keylogger. So even keeping your password fragment on a post-it under your keyboard would be fine-ish.)
You probably should know that recent smartphones (the most likely devices to ask for a wifi password at home) have features to share a password right in the settings. iPhones will simply ask you (or anyone connected) to allow them, and androids have some sort of sharing enabled (via qr code generally).
Hackers need just one chain of tired persons to breach a system. Sometimes length(chain) = 1, that's when bad things happen.
Anecdotal PS: I used to work at a bank and had to rotate my password monthly (sometimes even more, because there were unfederated systems that required another password, also with rotation). Eventually all my passwords became [short STRING] + [autoincremental INT]. We had MFA, so it didn't matter that much, but that makes it even more hilarious.
… which is why the password has sufficient entropy such that it will take until the heat death of the universe to brute force it. We're 3 months closer to the heat death of the universe … oh no?
Instead, expiry is about “what are the chances that the secret has already leaked” and about choosing an acceptable compromise between rotation frequency and attacker loiter time - assuming that the system hasn’t been back doored, let’s put an upper limit on how long an attacker with the secret has access. And incidentally it also means that if you somehow fail to disable access for ex-employees, that lingering access will eventually take care of itself.
But as the article points out, expiry has always been controversial and it’s not clear that on balance expiry is a good control.
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
[0] https://www.finra.org/filing-reporting/entitlement/password-...
> If the password length is 16 to 32 characters, it will be valid for 365 days
Madness.
On my first Wireguard testbed, WG's keygen dropped one at the front of the key. It remains my most treasured digital possession.
thankfully my current company let me keep my password for the last 3 years
Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash.
By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want.
If you only care about similarity to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.
You can do a quick check against the last password (which you have in clear, because it was just entered), though.
Similarly vs older passwords is what would be an issue.
Which isn't unheard of, though it's been years since I've seen it.
So, it can hash any proposed password and compare the history to make it's not been seen $recently (as an exact match, since it's comparing hashes).
It could also perform some minor permutations of any new password, and do the same history check to make sure you're not just changing the first or last character or digit. I don't know if it does this, but it could.
When you do the password change it asks you for the old one, that's how it knows.
So it asks for old + new, checks old is correct against the hash, and then compares old + new likeness.
So it all happens in memory.
This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.
They said it was a PCI requirement, or something.
Ie If someone broke into your office, opened computer, inserted the hardware security key, would they get in? Or is there something else non-physical going on? Like the initial login is password + security key, and you can demonstrate the ssh keys never leave the secured PCs etc.
It can be complicated but a example. TOTP that is very common used with passwords is regarded as MFA (tho most of the time software based on phone) but have many problems regardless
- many time replayable - can be intercepted - implementations look different - recovery code reuse problems etc.
On the other hand, using only passkeys dont have those problems but with passkeys, many times you cannot decide on what device a user have registrated the passkeys in a enterprise setting. example they could be apple passkeys, chrome passkeys, windows, hardware key(yubikey) etc and all of them behave different when it comes how they ex can be copied/ synced between users devices. So from where they can be used.
So for any authentication flow, you need to look at the full picture. What is the process when credentials are lost? How do user onboard etc.
Is a good entry point to say. We should use MFA or similar but the details matter.
But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.
So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.
Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.
When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.
> They may be using directory traversal from something else to read a key without even necessarily being on the system.
At least on linux - to read the directory containing a SSH key requires the ability to also write to that directory, as the user. Therefore you can also write to '.bashrc' and all sorts of other places. I suspect Windows might have a larger attack surface, but nonetheless, a directory traversal that is able to read and write is also able to install a keylogger.
> They may be on a server somewhere where someone left a key they shouldn't have
Private key should never be transmitted over a network boundary. SSH key passwords can be bruteforced as well. Having a password on the SSH key, when the SSH key is somewhere it really should never have been, is closing the barn door after the horses have left.
> The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held.
Again, getting access to the secret is enough to also have write access and be able to install a key logger. A password on the SSH key still does not help.
> They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger
If a person has enough access to read a SSH key, they can also install a key logger for at least that user account. They are equivalent levels of compromise, a user account having its SSH key read is already compromised.
edit: addendum: There are certainly attacks that can only read the contents of a system, with root that can read the full system. It's just odd to think about, since at that rate the SSH keys being on a prod system is already such a big no-no. SSH keys really need to live exactly just on the personal devices of the people who own those keys - EG: it should never be the case that say a SQL injection attack that gains root level read permission over everything on a filesystem can then ever read SSH keys - cause those keys should never be on the remote system to begin with. Putting a password on private keys that are then copied to servers _is_ security theater; the keys ought to never be copied to a remote server to begin with.
Um... I'm really happy you can mind read dude.
The whole premise here is whether passwords on SSH keys actually help.
SSH keys tend to live in two places: (1) a developers laptop, (2) some sort of CI/CD machine.
The passworded SSH key helps in case (1) only when a person walks away from the laptop and leaves it unlocked. An attacker can't simply then open up a SSH terminal and then SSH to whatever they see in the history. Or, it helps in case a person has a laptop that never locks and the org is simply trying to buy enough time to rotate the persons public keys before the SSH key password is cracked. The SSH key password can buy time, yes - but it does not change the actual security posture.
In case (2), all sorts of considerations need to be made. Though, any password would need to be encoded in a way that is just as accessible as the secret key itself. In case (2), the password really does nothing.
So, yeah, passwording a SSH key does not really help very much. If the keys are left around, then it is the fact they are left around that is a problem. The solution is not to create a scanner that all SSH keys have a password on them, but instead be sure that no SSH keys are installed on systems where they do not belong.
> They are the ones who get to flow through any crack they can find.
I would agree, that is why defense in depth is a good principle just as zero trust security.
So.. passworded SSH keys are kinda really security theater. Please give an attack vector on a persons laptop where the password SSH key is going to stop an attack that is otherwise unachievable. I'll steel man the counter position and mention that physical access is one case (except in that case we are only buying time). AFAIK, that is really it, that is the one place where a password on a SSH key helps.
To hack a persons laptop and read contents in the .ssh directory is a full compromise. To pick up the pieces after that, you need to do things like make sure the compromise can be observed, that privilege escalation is limited. If it comes down to the password on a SSH key being last line of defense - it's game over.
Keep in mind, your burden of proof is to show cases where SSH password actually provides a true increase in real security. The meta conversation of "well, you obviously never have.." is not interesting.
I'll note, if it is the case that SSH passwords are actual security - then, presumably you would feel comfortable stating "yeah, the SSH key was stolen, but nothing needs to be done because the SSH key had a password on it!" It's like the locks on doors, it is for the honest people, the criminals are only slowed down but not stopped by most door locks.
In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).
I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.
Practical/actual answer: this is stupid either way.
Or if you want a slightly more convoluted mechanism, when someone changes their password you have both in plain-text and you can take a copy of the old password at that point -- after all, it's not being used as a password any more! For bonus fun, submit all previous passwords to pwned passwords. Password reuse makes this a bad idea in general, specific policies attempting to mandate it will not be an issue notwithstanding.
Password changed.
Password changed.
Error at : broken pipe
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
Sometimes you just cant convince people that something is no longer recommended.
Often when people say this, they are parroting their assessor. But not every assessor graduated at the top of their class, or cares to stay updated, or believes that they know better, etc.
Another hot take, calling them passwords instead of pass phrases was a mistake.
People have no problem making a secure pass phrase like 'apophis is coming in 2029’.
It uses special chars and numbers, but some websites would reject it for spaces and some for being too long.
I say these are hot takes despite aligning with NIST because I've never seen a company align with them.
It only makes sense in HTTP basicauth and other system that keep plaintext passwords.
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
That is extremely annoying.
On the other hand if I was a manager and that happened to someone I managed we'd definitely have a conversation where I would acknowledge that forced password rotation is idiotic, but also point out that our password expiration is 90 days after the most recent change, which is 12 weeks and 6 days, and ask how come they don't have a "deal with stupid password expiration" event on their calendar set to repeat every 11 weeks?
That gives them 13 days warning. Vacations can be longer than 13 days, but I'd expect that when people are scheduling vacations they would check their calendar and make arrangements to deal with any events that occur when they won't be available. In this case dealing with it would mean changing the password before their vacation starts.
I don't expect people to go all in on some fancy "Getting Things Done" or similar system, but surely it is not unreasonable to expect people to use a simple calendar for things like this?
It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach.
Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
"Why did this stupid shit happen? Oh, it's money again."
If you, the person in charge of these decisions, allow an incumbent policy - even a bad one - to stand, then if something goes wrong you can blame the policy. If you change the policy, though, then you're at risk of being held personally responsible if something goes wrong. Even if the change isn't related to the problem.
It's not just cybersecurity. I have a family member who was a medical director, and ran up against it whenever he wanted to update hospital policies and standards of care to reflect new findings. Legal would throw a shitfit about it every time. With the way tort law in the US works, the solution to the trolley problem is always "don't throw the switch" because as soon as you touch it you're involved and can be held responsible for what happens.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
I wonder if some of these constraints are to try to find a way not to pay out on the policy.
To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.
we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!
and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.
After all it's perfectly possible to do interior work in your house that isn't up to code, but if it burns down in a fire, the insurance company will investigate and may not pay out if they find out.
As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.
Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.
In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.
In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.
This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).
A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.
And then you have trauma that will say "we cannot change the password because we don't know where it is used".
Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.
They refused to establish MFA or passkeys - and instead insist that "NIST is the minimum recommendation for cybersecurity... and we take cybersecurity very seriously... to ensure the safety and security of the citizens... therefore we will not change our policy on mandatory account lockouts or password change requirements."
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?
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.
Bad UX is potential security vulnerability. If your system behaves in unreasonable ways, users are much less likely to notice when it behaves in a slightly different unreasonable way, this time because of a spoofing/phishing, etc.
The obvious example: if your system frequently asks for passwords, re-entering passwords becomes a habit (read system one from "thinking fast and slow"), and the user is less likely to use judgement each time they enter the password.
But also, if an OS makes it hard to find all startup applications, allows untrusted code to run in the background without any visible signs, allows terminal code to access all local files by default, etc etc these all can be abused.
One problem is that human psychology is rarely considered as important a factor as it should be by the average security expert. The other is the usual suspect: incentives. The right chain of responsibilities is missing when things go wrong for people because of mistakes that would be avoidable by proper product design.
Regulation should enforce that, but while everyone would benefit from regulation, no one likes the regulation that will regulate the product/services they offer, and the supplier has upper hand when a change in regulation is being considered because they are focused and motivated.
In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
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 :)
Now that most OSes can unlock with just a fingerprint or face,
there's no reason to leave your screen unlocked when you walk away.
Cameras aren't ubiquitous either. Across the 5 locations I currently service, less than 2 percent of desktop PCs have a camera.
Past that, I believe there is a secondary challenge with face scanning; it's the unsettlement factor. I suggest that discomfort with face scanning is reasonable and earned.
The reason: We're constantly subject to face scanning that is non-consensual, intentionally hidden from us and is probably exploitative. Cams also enable snoopy bosses, school admins, corps, LEO and Govs to endlessly peer where they should not.
And even where we own our devices, we don't fully control them. Software corps have no ethical boundaries. Any assumptions that they'll respect us - at all - isn't based on reality or history.
For workstations, I like security keys.
It would be worth doing research to find the best fingerprint scanner that implements this well.
Face scanning is a poor solution because desktops usually do not have Hello-compatible scanners and the scanners on the Windows laptops aren't very good. They frustrate users who prefer darkened rooms or who sit in places with varying contrast from the windows. It is also weird the way the camera is constantly trying to find you, and so it blinks its red LED frequently until the computer goes to sleep.
Just really agreeing with you on security keys, but we also have to make sure they are really secure. Also, like the article says, they give you the device possession part, but not the user ID part, unless they have a biometric device built in.
This logic I do not understand. USB hubs exist and are more-or-less commodity parts these days. [0]
I'd be surprised if the fingerprint reader was anything faster than USB 2.0, and deeply offended if the reader did anything other than idle on the bus when it's not being used... so you're not going to be suffering any real bandwidth contention by putting that guy and a USB 3.x device on the same hub.
[0] They're also usually how motherboards that have a whole bunch of USB ports hook those ports into the onboard USB controller(s). (Do folks usually think that every one of the 10gbit/s ports on one's desktop machine could be simultaneously run at 10gbit/s?)
Fortunately these days most services will cache your work.
It doesn't matter if things are broken. It matters that you did everything by the book. And the book in this case was written 30 years ago and is woefully inadequate. But try convincing your VP of information security that employees shouldn't have to change their password every 3 months...
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.
What I remember is that the promise of SSO in the 1990s and early 2000s was that you would login only ONCE, onto your desktop. The operating system would use that login to acquire NTLM or Kerberos tokens, which would then be used to authenticate everything else: shared drives, printers, even web sites would be authenticated using that token (there's a way to pass through your desktop NTLM authentication to a web site, which IME is slightly annoying because it authenticates the connection and not the request, and therefore needs keep-alive HTTPS connections to work correctly).
Of course, that only really works that well in an homogeneous environment, for instance one in which everyone is using a few Windows NT versions on the desktops and all the servers, or one in which both the desktops and servers use the same specific proprietary Unix variant. What instead happened was the rise of heterogeneous systems, which do not share that common authentication mechanism. To make things even worse, each piece of software has its own separate authentication database, often (but not always) a pluggable one which might perhaps be coerced to forward the authentication attempts to another system, instead of directly using the operating system's centralized authentication mechanisms. AFAIK, you can still make it work, but it's a lot of work (for instance, IIRC forwarding NTLM credentials to web servers is disabled by default, and has to be manually enabled and configured to allow a given web server).
It works if no monopoly abuses their position by sabotaging the standard.
OAuth is getting a chance to work because neither Google, Apple nor Facebook are big enough, and they don't play well with each other. At least right now.
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.
With email magic link I need to enter my email (it seems to rarely auto-fill for some reason), then wait (often it takes 10s for the email to be sent for some reason), then if I was logging in on something that isn't my default browser I need to copy+paste the link (often just clicking the link authorizes the source session but not always and you don't know what this site does so you need to do it to be safe). Now you are finally logged in but probably have two tabs open. Either you need to find the first one to continue your session (if it logged that one in) or close it and lose your history for that tab (and hope that the website actually maintained your target page which more often than not it didn't).
I'd much prefer if they could just trust my password. But I know the unfortunate truth is that the majory of people just reuse a password across most sites. So these measures are intended to raise the baseline difficulty, not to improve the security of those with good habits.
Sometimes it takes minutes. I have, on more than one occasion, given up on buying a product because of this. It's actually insane to me how much effort sites put into preventing users from using them.
I get it, most people are idiots with completely non-existent security hygiene, but man does it suck being punished because of just how low the common denominator is here.
*faster + easier (fewer steps)
If someone tries to log on to your site from a low reputation VPN, throwing an email OTP challenge can give some assurance it’s a genuine user logging in. Rather than a spammer or something like that.
2. Forget password -> get email for new password -> input username/new password -> get email otp code.
The only actual security factor here is your [email, email password], everything else is just silly rigamarole.
Whether it is worth annoying some users in the password reset case to avoid making the login code slightly more complicated is going to depend on your specific situation.
That's right, you have to wait for an email to arrive, make it through the spam gauntlet, and then click the link in the email, likely covered in trackers, just to get into a website or app. And here I thought people wanted to keep you in their site as much as possible
logging into phishing links would make more people pause if they didnt have to login constantly to get work done
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.
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
A lot of infosec authorities move away from this.
However, I always wonder, does it make sense for an org to stop with periodic password resets if: 1. the org is not very capable in detecting all account compromises; 2. in practice, users leak their passwords (e.g. by getting phished) and not all of them lead to direct intrusions, some credentials are sold first and it may take weeks/months to cause an intrusion.
I believe that in practice, forced password changes at least ensure that unknown compromised passwords will become outdated at some point in time, and I think that this is positive.
Ultimately, I believe the best thing to do is to move to FIDO2-authentication here.
But I do wonder what are other peoples takes on this topic?
password
password1
password2
password!
Password1!
People get predictable on how they modify their passwords when that policy is instituted. Mostly because it's a royal pain in the ass to have to generate a new password AND remember it.
That was one of the reasons that browsers (etc) began offering users randomly generated passwords that either the browser, or a 3rd party tool/service recalling the password on demand.
However that then means the password to the browser/service becomes the unchanging password...
> Ultimately, I believe the best thing to do is to move to FIDO2-authentication here.
Passkeys are an attempt to circumvent this by having (effectively) a key that's attached to some physical device that the user must have access to to prove that they are the authorised user... but... people are circumventing those by storing them in cloud services... which means that the password to the cloud service is... yet again.. the weak point.
> But I do wonder what are other peoples takes on this topic?
For my money, the problem that's being attempted to be solved is unsolvable.
In the physical world we determine identity by citing documents that verify the identity as far as a trusted institution like a government or bank is concerned, and those documents are predicated on documents that may or may not exist (birth certificates) and the assurance that those documents are for the person presenting them, from other people that have been through the same procedure.
The digital world is even more difficult to prove identity with, because everyone looks exactly the same, ones and zeros, the order might be different from one person to another, but they're mutable.
I agree, on moving the weak point to certain service providers when doing this.
Unsolvable: hm, but isn’t the idea to make it more secure, not necessarily solve it completely?
> Passwords, Face ID, Touch ID — things that supposedly nobody but you can replicate, but which don't prove you're physically near a given device
Password, sure. But the other 2 surely prove that you're both 1) the correct person and 2) near the physical device that scans your face/fingerprint. The article immediately follows that by saying that face/touch ID do both.
Unfortunately lots of compliance people/orgs don’t seem to want to give it up.
Every once in a while, the token attached to that somehow expires. Which means that once I have successfully signed in (but before doing MFA) I am redirected to a DIFFERENT SSO system.
I get to login to that and enter its MFA code.
Having now completed all security requirements. I get to enter the MFA code for the original SSO.
Double SSO. Double MFA.
Boy don’t we feel secure.
The root of trust is my yubikey in both cases but the implementation was lazy.
I brought this up to our security team and they shrugged.
1. It must be close to impossible for a computer to guess.
2. It must be easy for a human to remember.
Virtually all password policies focus exclusively on point #1, with the vast majority just giving cargo cult instructions without really understanding the state of the art. Almost nobody puts any emphasis on point #2, which is arguably more important as it is the source of most breaches. If a person can't create a password, ignore it for a week, and then remember it immediately for the next login it's a bad password. This is where requirements like "no more than two characters from a character set (lower case, upper case, numbers, punctuation) in a row" are actively counterproductive. If the password has to be so convoluted that the user is forced to write it down then you've undermined your own security. Worse, it means the help desk will be forced to reset many many passwords which increases the chances of an impersonation attack succeeding.
The corpo "security" dingbats force this on our work machines via profiles -- can't control how long before the screen locks. Thank goodness for the Amphetamine app. I'm not typing in my password every time I stop to think for two minutes, you can fuck all the way off with that.
I haven’t chatted about it with anyone, as I partly wasn’t sure if something in my setup has changed and whether I’m a minority that fell into some constant reauth bucket. Or whether most of site owners have slowly been using lower and lower auth expiration, causing me a bunch of frustration and friction.
those are actually ones that don’t do stupid shit like expire passwords… I have had one password for vanguard… and I am in my 50’s :)
Open the page... you have to log in, no way to remember you. Sure, you save your password in the browser, but unless you then also click into one of the input fields, the login button is disabled. Then you work on some 3d stuff, export the file, send it to the 3d printer, some time goes by, browser still open, you get the object, and the holes don't line up, you forgot the wall thickness in the measurements, calipers, yep, 3 more milimeters... open onshape tab, nope, you've been logged out. I didn't even close the goddamn window/tab, it's a free account editing a public document.
and you can just use a custom OIDC IDP with tailscale, for all 15 of us that have custom OIDC IDPs
[^1]: https://goauthentik.io/
But at least it makes me reauth.
Companies don't even have a password manager so few employees use the browser to save passwords, others use their own password manager which comes with its own security risks like that service, LastPass IIRC, that got breached.
When working for big companies, there are so many wrong processes and practices which provides the bare minimal and that is fine.
Support team cannot care to report the problems coz they don't wanna more work, my laptop always connect to a restricted network while in the office which kills internet access to everything, that in turn cause the laptop to take 20-30 to turn own while it tries to run AD policies.
The whole process is broken within the companies culture, keep it minimal, repetitive and that "should work, next"!
A website doesn't have control over whether you are using a password manager though. This is about stopping the human from generating a password themselves, which will be terrible.
The supposition for all this is that the service wants to use passwords for whatever reason. In that case, generate them for the user.
Further, the development of this ecosystem is to the exclusion of alternative OSes. Windows Hello and whatever apple wants to call their suite of biometric goo is elevating them to a place in my life that is unacceptable by virtue of the unwarranted trust granted to them.
These are a video games, not a bank account! Please just let me have fun!
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.
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.
I seriously think ms365 login chain is straight broken Click here to sign in - enters userID and pass - thanks for logging out :o
Currently MS recommends a 90 day window between MFA re-authentication for known devices/browsers you already authenticated on.
The alternatives proposed are "just always check right before a sensitive action" and "use continuous verification". Both of which are much harder to pull off correctly than short-lived authentication sessions (unless you buy their product, of course, supposedly), especially on third-party services you don't control the source or manage the deployment for.
Oh, and of course, "just make everyone lock their screens". If only it was that easy. If basic rules like that worked, we could ditch half the security measures we have for websites. What's next, "just use unique passwords of 20+ characters for each website"?
Also, this is putting a lot of trust in solutions like Windows Hello. I can't speak for the security of Apple's implementation, but thanks to bad vendor implementations (including Microsoft's own!), Windows Hello hardware is full of security holes. At some point one company decided to take a look at a few of those devices [and found security problems in all of them](https://blackwinghq.com/blog/posts/a-touch-of-pwn-part-i/).
Short token longevity also protects against one use risk Tailscale have a solution for: users logging in to their personal accounts on public computers. That's still an essential use case for people without internet access or computer access at home. Often these people are more vulnerable (homeless, very poor) so relying on them clicking the "log out" button on every website they're forced to interact with is not going to work.
Kerberos (or buying what Tailscale sells) does offer a somewhat nicer authentication flow, but that still doesn't work reliably on every browser on every OS on every device and it requires people to follow basic rules like "lock your screen", which is a massive risk. Passwords will always work anywhere and their security can be somewhat enforced.
But...worry not, we're about to embark on a world with a whole lot less security now thanks to AI and laziness.
- Websites should (in agreement with TFA) just remain logged in (at least for 24 hours). Let the OS handle it.
- Public computers should only ever provide ephemeral login sessions. Everything cleared upon each login. Never persist anything to disk.
- Personal computers should reauth frequently, but should use adaptive authentication: i.e., password sometimes, and pin/fingerprint other times, where reasonable. Since "reasonable" is debatable, this should be configurable by the user at the OS level.
Even worse is that if you try to search for the feature and click on it, it presents a page that unhelpfully returns 404.
It's annoying AF.
"By default, the web session length for Google services is 14 days." https://support.google.com/a/answer/7576830?hl=en
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.
So, if you’re pursuing PCI compliance people don’t rely on assumptions or conditional language like might. Certainty is key when dealing with compliance frameworks.
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
E.g. If you set your session timeouts to a ~1 day then by the time your session cookies are up for sale on the dark web, they will be expired.
The article doesn't mention this and it's the main reason I advocate for auth sessions that are as short as practical.
it's funny, but tracks infosec life pretty well, that we've stumbled into a proof that the necessary condition for a system to verify we are alive and are our authentic being is to offer up some minor suffering to it.
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.
> At Tailscale, we believe in security that’s adaptive, intelligent, and actually useful — not —just- security theater.
The same web app stays logged in forever in my mac and I access both of them with the same time intervals.
I don't like it, but frequent reauth does limit the blast radius of stolen session tokens.
Security theater, not really as it makes passwords less secure
Apple'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.
It's the same reason I intentionally lock up apps with TouchID when there's remotely anything sensitive in there. I just don't want someone to be able to snoop if I forget to lock my phone.
I'll say however, there should be easier ways to reauth in such scenarios. Like in my case, TouchID is not very disruptive to my work even if a prompt appears. I'll also say it's probably stupid to lock out when there's continuous activity (should lock based on inactivity period).
The worst offenders in my experience are banking apps. They:
- Force logout sometimes regardless of ongoing activity
- Log out as soon as I close the tab
- Log out when I press the back/reload button
- After logging out, impose a mandatory inactivity period before I can login again (this is just the most idiotic thing EVER)
- Use JS to block any kind of copy/paste operation on username/password fields
- Never integrate with modern auth mechanisms, not even app-based TOTP!
- Have crazy password expiry windows (like every quarter) and force password change when your previous password expires, regardless of how strong they areFor a banking app, I think this is fine. A lot of people aren't aware closing a window isn't logging out. The rest of that is dumb, though.
So, when Google single signs you out mid meeting (has happened to me), they don't care about how stupidly annoying that is. That's just them asserting that if anything bad happens to you, it was your own fault and not their failing.
And then a secondary thing that makes life even harder is that instead of working together they are considering single sign on mechanisms as control points that they can leverage to keep the relationship with 'their' users exclusive. So Google and MS both do very similar things but they don't trust each other's Identity Providers (IDP). That's not an accident. That's intentional. MS has been on a decades long mission to 'own' all logins, and of course they've been failing to get there just as long. Likewise, Google and Meta have been fighting over this as well. And the net result is that you don't have just 1 account to worry about but gazillions. That's why every silly little app has its own stupid email/password thing and why onboarding friction is the biggest hurdle to users adopting these.
These are the primary motives driving this mess. Companies don't collaborate, so security stays complex and messy. It's also the reason that passwords (long discredited as a reliable way to authenticate) are still a thing. If we had effective federated IDPs like OpenID where everybody could use and IDP of their choice and use it to authenticate it with pretty much everything and the kitchen sink, you wouldn't be using passwords ever. That was envisioned as early as 20 years ago. Google, MS, Meta, etc. blocked every attempt to make that happen by never mutually trusting each other, or any other IDP not operated by them. They all implement some version of OpenID 2.0 (with enough differences to make supporting all of them a bit of a journey) but they deliberately don't whitelist any external IDPs and jealously continue to fragment the security landscape by guarding their walled gardens.
They've been engaging with each other in backroom standardization attempts ensuring that the status quo is never allowed to change for decades. The latest move in this war: pass keys. Nice solution on paper. But you got to have the Google version of it. And the MS version. And all the rest. Sigh. Because, obviously, by design these will never delegate to each other. They trust each other even less than they trust you.