Frequent reauth doesn't make you more secure(tailscale.com)
tailscale.com
Frequent reauth doesn't make you more secure
https://tailscale.com/blog/frequent-reath-security
538 comments
The requirements usually don’t come from IT.
It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach.
Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
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.
I belonged to an organization that had password complexity requirements. That's normal and understandable. However one requirement was that no part of my password could contain a three character subsstring that was included in my full name. I won't give my real name here, but sadly it includes some three letter subsequences that are somewhat common in many English words. I can understand a policy that prevents someone from using "matthew1234" as Matthew Smith's password, but this rule also prevents such a person from using "correcthorsebatterystaple" because it has 'att' in it.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
> 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.
I wonder if some of these constraints are to try to find a way not to pay out on the policy.
It absolutely was/is.
To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.
To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.
> 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.
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.
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.
is a judge going to think the same way if insurance doesn't pay and you take them to court though, in the event of a breach, etc.
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.
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.
in this case I'd be more worried about being in court trying to explain why we knowingly used an inferior approach (forced password changes) when we knew the newer approach resulted in higher security... that is a vastly different analogy than being "out of code". additionally, noting the deviation from the old, less secure standard up front (in our HITRUST submissions) and with our customers (in their vendor questionnaires) provides evidence that we are going above and beyond vs. shirking a duty.
Should you also question their competence? They should know, right?
this is less about competence and more about update schedules... we happen to feel like it's worth incorporating guidance that's newer than what HITRUST or our customers require us to (though the guidance in question was updated by NIST eight years ago... sometimes it takes a long time for this stuff to change)
Just an unbreakable law of the universe.
"Why did this stupid shit happen? Oh, it's money again."
"Why did this stupid shit happen? Oh, it's money again."
It's not money but inertia of very large systems. All these password changes cost money as well. If anything it's a market failure that insurance companies seem to have too little incentive to update their security requirements. This would likely be solved by reducing friction with both evaluating insurers in detail and switching between them.
It's also a sort of moral hazard problem.
If you, the person in charge of these decisions, allow an incumbent policy - even a bad one - to stand, then if something goes wrong you can blame the policy. If you change the policy, though, then you're at risk of being held personally responsible if something goes wrong. Even if the change isn't related to the problem.
It's not just cybersecurity. I have a family member who was a medical director, and ran up against it whenever he wanted to update hospital policies and standards of care to reflect new findings. Legal would throw a shitfit about it every time. With the way tort law in the US works, the solution to the trolley problem is always "don't throw the switch" because as soon as you touch it you're involved and can be held responsible for what happens.
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.
I love the analogy to the trolley problem. It sounds like this logic would literally hold up in a real-life trolley problem in regards to the law.
"No-one ever got fired for buying IBM" etc.
I mean that was true about Boeing, right up until it wasn't.
Not money; incentives
Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep track of the change interval. It also adds no security whatsoever! A user could almost certainly get away with Password2025-06, etc.
I once wrote a script to change my password randomly X times and then back to my original password. Worked like a charm.
There are policies to prevent changing the password more than once a day to prevent that. I've encountered it in several places
Fascinating. In other words:
In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).
I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.
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.
There are also systems that keep a history of old passwords just to prevent you from reusing one.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.
This doesn't seem practical at all. The combinatoral explosion would make the storage requirements impractical for everything but the absolutely most trivial cases like incrementing a number as the very last digit. Even in your simple example you're talking about storing 256 different hashes just to catch one possible mutation on a way too short password.
You can store a normalised form -- so if the password is `PaSsWoRd` and the user tries to change it to `pA55wOrD`, a normalisation that lower-cases, turns 1 and i into l, turns 2 and 5 into s, and turns 4 into a, would normalise both to `password`.
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.
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.
Technical/pedantic answer: you can store a 'normalized' hashed form of the password, e.g. before hashing it, convert it to all lowercase, replace all digits with 0, sort the characters, … and then do the same to the new password before hashing it, so a whole bunch of stuff will compare "equal".
Practical/actual answer: this is stupid either way.
Practical/actual answer: this is stupid either way.
You could use a Bloom filter, and just gaslight your users when a false positive happens.
Ye. If the insane password gatekeeper shenanigans doesn't make you input your old password together with the new, you know they store your passwords.
The obvious solution is to have a Monday password, a Tuesday password, etc.
Password changed.
Password changed.
Password changed.
Error at : broken pipe
Password changed.
Password changed.
Error at : broken pipe
I’ve personally experienced the password change require that “more than X characters be different than the old password”
Um, that's a really bad sign...
No, you can do it safely. The idea is to have the password renewal process also ask for the previous password.
This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.
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.
Oh so trivially bypassable by changing your password twice.
To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.
No it doesn't. Shows you how complicated all this is and how the un-initiated (including me) should learn to not give their two cents.
When you do the password change it asks you for the old one, that's how it knows.
So it asks for old + new, checks old is correct against the hash, and then compares old + new likeness.
So it all happens in memory.
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.
Unless they ask you for your current password as part of the password change flow.
Is there any way to check that with non-plain-text password?
Actually it can be trivial as long as you can require the user to re-type the current password when entering a new password; check hash first, then check edit distance with the entered "current password" (and, of course, promptly throw it away once you know the edit distance.)
Ohh. I guess that's what Windows does when a user wants to change their own password in the domain.
It does more than that, it keeps a hashed password history (which used to be in the user attr ntPasswdHistory, but is now "somewhere secret" afaik) according to the value of ms-DS-Password-History-Length attribute. OpenLDAP keeps these (ppolicy overlay) in the user object.
So, it can hash any proposed password and compare the history to make it's not been seen $recently (as an exact match, since it's comparing hashes).
It could also perform some minor permutations of any new password, and do the same history check to make sure you're not just changing the first or last character or digit. I don't know if it does this, but it could.
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.
Not if the check is done client-side, so the plain password never leaves you local domain. Of course the check being done client-side means that it isn't difficult to skip if you are inclined to make a smidgin of effort.
It can be done server side too, the old password can be sent along the new one and the server can verify it.
Yes, what I meant to say that it doesn't even have to be done server-side, so the fact it happens doesn't imply the server ever sees the old password beyond it's initial setting.
[deleted]
I just let the keyring roll a completely new password. For some reason, all of my employers do require this insanity, but not on the one password I have to actually type.
I once had an employer that required us to use passworded SSH, and disallowed SSH keys, because they couldn't enforce that the SSH keys were passphrase protected, so just turned that option off.
They said it was a PCI requirement, or something.
They said it was a PCI requirement, or something.
PCI requires multi-factor auth these days, so you’ll likely find now the ssh password will be your password plus a OTP at the end.
PCI DSS from 4.0 actually have something called customized approach for everything. If you can prove and the QSA agrees that you fullfill the goal of a requirement, you can be quite flexible. Example i am doing things like not using passwords at all and only passkeys, or only ssh keys protected by hardware security key etc. Together with agents trying to verify the devices connected are company owned and hardened in different ways.
Your milage might vary depending on how good your auditor is but PCI DSS standard do have quite a bit of flexibility in it.
Presumably at some point in your environment you are doing MFA? Just not at every step?
Ie If someone broke into your office, opened computer, inserted the hardware security key, would they get in? Or is there something else non-physical going on? Like the initial login is password + security key, and you can demonstrate the ssh keys never leave the secured PCs etc.
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 is not about MFA or not but to demonstrate the process is secure for the purpose.
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.
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.
It’s always interesting to hear other people’s approaches- Thanks for the insights!
Isn’t there a way to ask for OTP after initiating the SSH session?
One issue with this is it makes it hard for scripts to log in (this may be what you want)
Yes, via PAM, and this works fine with OpenSSH. But the couple of OTP implementations I've used are the same, you can either provide password and PIN or passwordPIN. In the end they get concatenated, passed to the next layer, and taken apart for checks. This lets it work with brain-dead http basic auth too, if you're unlucky enough to have to use that...
Yeah, I’ve seen it in a couple places, too. (Once I’ve had to write my own wrapper for openfortivpn that did exactly that!)
This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.
But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.
So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.
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.
> But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems.
Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
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.
"Though, if someone gets that far, couldn't they also install a key logger on the users system?"
There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.
When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.
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.
I appreciate the additional insights, but the premise I'm pushing back on is whenever a SSH key is read, then the user account is by necessity compromised in order to do so. Given that level of a breach, there are myriad ways for an attacker to escalate privilege and exploit their access without worrying about a password on the SSH key. Namely, at that point, cracking the password on the SSH key is a tractable problem.
> They may be using directory traversal from something else to read a key without even necessarily being on the system.
At least on linux - to read the directory containing a SSH key requires the ability to also write to that directory, as the user. Therefore you can also write to '.bashrc' and all sorts of other places. I suspect Windows might have a larger attack surface, but nonetheless, a directory traversal that is able to read and write is also able to install a keylogger.
> They may be on a server somewhere where someone left a key they shouldn't have
Private key should never be transmitted over a network boundary. SSH key passwords can be bruteforced as well. Having a password on the SSH key, when the SSH key is somewhere it really should never have been, is closing the barn door after the horses have left.
> The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held.
Again, getting access to the secret is enough to also have write access and be able to install a key logger. A password on the SSH key still does not help.
> They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger
If a person has enough access to read a SSH key, they can also install a key logger for at least that user account. They are equivalent levels of compromise, a user account having its SSH key read is already compromised.
edit: addendum: There are certainly attacks that can only read the contents of a system, with root that can read the full system. It's just odd to think about, since at that rate the SSH keys being on a prod system is already such a big no-no. SSH keys really need to live exactly just on the personal devices of the people who own those keys - EG: it should never be the case that say a SQL injection attack that gains root level read permission over everything on a filesystem can then ever read SSH keys - cause those keys should never be on the remote system to begin with. Putting a password on private keys that are then copied to servers _is_ security theater; the keys ought to never be copied to a remote server to begin with.
> 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.
I can tell you've not been involved in defending against an active attack. You, as the defender, do not get to play the game of "well, if I squint and read it that way, that attack wouldn't work". The attackers get to play "well, hey, if it turns out I do this and that and push it through the other thing, I get access". They are the ones who get to flow through any crack they can find. They are the ones who get to do logic chopping like you're trying to do. You don't get to argue "Well gosh, that team shouldn't have left that one permission open on that one system, that's not a best practice, if they'd followed best practices 100% of the time the attackers couldn't have gotten in...". Your job is to pick up the pieces.
> I can tell you've not been involved in defending against an active attack.
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.
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.
Whenever I don't have to type it, that's what I do. It's the login (or password manager password) needing this counterproductive crap that gets the "append a date" treatment. It's a 10-word diceware passphrase, only used for that login anyway, it's not getting breached if it's stored in even a remotely secure manner (even an unsalted hash would be safe).
They do it because their IT departments are checklist monkeys with no actual brainpower there, AND/OR they have cybersecurity insurers that mandate it who also have nobody with actual brainpower working there.
When I first set up an account at a new org or whatever, I don't think about the possibility of rotation later, but once I get my first "your password has expired and needs to be reset" message, I just add a counter to the end of the password that I increment each time I'm required to change it. Successive passwords have no less entropy than the original password, anyway.
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
[deleted]
> But these don't seem to be authoritative enough for IT / security,
As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.
Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.
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.
Sometimes when I log into a random website and I see a forced password reset, I wonder if it has been compromised, rather than setting a time-based expiry.
If a site owner knows that certain accounts are part of a database breach or something, a reasonable step would be to force the users to change the password at next login.
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.
Another common reason to do a force password reset is if they've moved authentication providers and were not able to bring their hashes along. Some providers don't allow for hash export (Cognito, Entra).
Or just if they changed to a more secure hash algorithm themselves and want to upgrade users still on the older insecure one.
This can be done at login time without the user noticing, as you have the plaintext password for a moment.
Yeah, this is the best practice. We offer that in our product.
But it's possible that you could follow the best practice and still force a reset. This could be because:
* the customer or provider doesn't want to wait for everyone to log in
* they've waited for N months and now there is a block of users who have not logged in yet and they think it is worth the user annoyance to just force them all to reset their password
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
They could do that by comparing against the old hash and if it matches generate the new hash to store somewhere.
Last time I brought this to our cyber folks, they pointed out that PCI standards require password rotation. So it depends upon which auditors you care about more.
This requirement is in section 8.3.9 of the PCI DSS[0], and only applies to single-factor authentication implementations, two-factor auth removes this requirement.
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
Your broker/bank still needs to do it, unfortunately... someone please fix this :(
[0] https://www.finra.org/filing-reporting/entitlement/password-...
[0] https://www.finra.org/filing-reporting/entitlement/password-...
> If the password length is 12 to 15 characters, it will be valid for 180 days
> If the password length is 16 to 32 characters, it will be valid for 365 days
Madness.
> If the password length is 16 to 32 characters, it will be valid for 365 days
Madness.
I'm a big fan of "should not include profanity, words of a vulgar nature". It's not unthinkable my password manager comes up with a chain of letters that at one point will include "fuck".
> I'm a big fan of "should not include profanity, words of a vulgar nature".
On my first Wireguard testbed, WG's keygen dropped one at the front of the key. It remains my most treasured digital possession.
On my first Wireguard testbed, WG's keygen dropped one at the front of the key. It remains my most treasured digital possession.
This comment reminded me of a talk I saw[1] about Apple's password generation algorithm. Apparently (and unsurprisingly), they have a list of offensive terms the system is designed to avoid. I expect this is common-enough practice in most popular password managers, but probably not all.
[1] https://www.youtube.com/watch?v=-0dwX2kf6Oc
[1] https://www.youtube.com/watch?v=-0dwX2kf6Oc
It would be fun to make a passphrase generator that always includes a profanity.
So long as they factor that into the "bits of entropy" calculation.
Dibs for calling it misenthropy. Entropy mixed with misantrophy.
Now I'm trying to remember where I read the story about somebody who was in a programming class and was writing some program that took user input, and figured that it should be smart enough not to repeat curse words. So they started writing down all the curse words it should know not to say, and that was about the extent of what they had done when the teacher came around to see how everything was going.
Word list based passphrases mostly avoid this, by not including those words. Which still doesn't mean you won't get something offensive, of course, it'll just be a string of four words instead of four letters.
It kinda is good personal policy IMO for passwords you have to type to be positive affirmations. I used 'Fuckthis1!' for a moment; funny enough it was not the most moralizing thing to type all the time! OTOH, 'H@ppyH@ppyJoyJoy!!' was always a small mood lift.
What's the scope of that? Not consumer accounts I imagine? I haven't had to change my bank account passwords in over a decade.
I’ve always said “lockout turns a possible password guessing attack into a guaranteed denial-of-service attack”.
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
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.
I think a lot of people in IT know these things but having a 'strict' auth policy makes them seem competent so they just go with that. Besides there is not much incentive to make authentication efficient since the frustrated users are a captive audience not paying customers.
I just had this argument with a state wide government website. I have to log in to this site maybe once per year to update contact information and update a few fields. Unfortunately, that site silently deactivates your account automatically every 90 days. So I'm forced to change the password literally every time I log into the dumb thing.
They refused to establish MFA or passkeys - and instead insist that "NIST is the minimum recommendation for cybersecurity... and we take cybersecurity very seriously... to ensure the safety and security of the citizens... therefore we will not change our policy on mandatory account lockouts or password change requirements."
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."
if my password has not been leaked it's insane that providers think i should rotate it, but this still seems to be standard practice for some completely baffling reason
There’s weird math that says your password or generally a secret key is more secure if it’s existed for less time (generated fresh) because there hasn’t been as much time to brute force it. I don’t believe it but some hardcore types do.
That might apply to short passwords but passphrases are recommended and if they're >20 characters then brute forcing is not going to make meaningful progress toward them while we are all alive.
> I don’t believe it but some hardcore types do.
… which is why the password has sufficient entropy such that it will take until the heat death of the universe to brute force it. We're 3 months closer to the heat death of the universe … oh no?
… 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?
Time based expiry (“freshness”) is not about likelihood of brute force. Brute force prevention is handled by delay/lockout policy for online systems, and by password complexity rules or key length/cipher combinations. Nobody sane uses such rules in such a way that make brute force “slightly impractical”- security practitioners always choose lifetime-of-the-universe-scale complexity if given a choice.
Instead, expiry is about “what are the chances that the secret has already leaked” and about choosing an acceptable compromise between rotation frequency and attacker loiter time - assuming that the system hasn’t been back doored, let’s put an upper limit on how long an attacker with the secret has access. And incidentally it also means that if you somehow fail to disable access for ex-employees, that lingering access will eventually take care of itself.
But as the article points out, expiry has always been controversial and it’s not clear that on balance expiry is a good control.
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.
>I don’t believe it but
you have to believe it, it's true, you just think it's not the greatest threat or that the response to mitigate it (for example, using a pattern of temporary passwords to facilitate remembering them) would be worse than the disease.
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.
if it causes 90% of people to just enter a simpler password, out of frustration and “fatigue”, then this is irrelevant IMO. Theory doesn’t take into account human behavior.
It’s especially annoying when a company enforces these brain dead policies on employees. You want people to waste mental effort changing their passwords by 1 letter every 3 months, just to appease some IT manager? Give me a break lol.
I’d rather have a long complex password that i remember and remember ONCE.
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.
That's what baffles me. Somehow security NEVER acknowledges that security theater, cognitive overload and constant friction makes users more inclined to make bad decisions, repetition over months make this even worse.
Hackers need just one chain of tired persons to breach a system. Sometimes length(chain) = 1, that's when bad things happen.
Anecdotal PS: I used to work at a bank and had to rotate my password monthly (sometimes even more, because there were unfederated systems that required another password, also with rotation). Eventually all my passwords became [short STRING] + [autoincremental INT]. We had MFA, so it didn't matter that much, but that makes it even more hilarious.
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.
I think directly caused by the fact that at large companies, the best way to get ahead is to be seen as doing things. It doesn't matter if those things are completely harmful, so long as they sound good. With password changes you now have company wide visibility, with regularity, doing something that to somebody who's not thinking much would probably be suggestive of doing a very thorough job.
For most people, writing (most of) their password on a piece of paper that they keep in their wallet would be pretty good security.
Paper can't be hacked, and writing down the password allows for more complicated passwords. In case someone gets access to your wallet, you still keep a portion of the password not written down.
(And if someone gets physical access to your stuff, you are hosed in general, because they can just install a keylogger. So even keeping your password fragment on a post-it under your keyboard would be fine-ish.)
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.)
It really depends on what password. At home our wifi password is on a paper, right there on the office board. If you landed in the room, I won't feel more in security if you need other actions to get the password out of me.
> At home our wifi password is on a paper, right there on the office board.
You probably should know that recent smartphones (the most likely devices to ask for a wifi password at home) have features to share a password right in the settings. iPhones will simply ask you (or anyone connected) to allow them, and androids have some sort of sharing enabled (via qr code generally).
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).
No, like I don’t believe the math. It’s not about not wanting to believe the math. I don’t believe the mathematical conclusion is practically true even if there may be something theoretically interesting to talk about, like the monty hall problem.
it's BSD /etc/passwd being 666 or something, so anyone could brute force it in 180 days, therefore passwords has to have max complexity within 8 bytes limitation and rotated every 180/2 days... who's even started using computers before it was patched?
Stuff like ISO27001 still demands it. We have to rotate passwords, against modern cybersecurity practice, in order to comply with an information security standard.
ISO 27001 doesn't say this. The control implementation guidance (ISO 27002) specifically cautions against requiring frequent password changes.
Most frameworks, at least most that I am aware of (north america) have removed password rotation requirements entirely, or have exemptions in place if you have MFA, use risk-based access policies, etc.
Often when people say this, they are parroting their assessor. But not every assessor graduated at the top of their class, or cares to stay updated, or believes that they know better, etc.
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.
These recommendations live in a mythical world, but not in a company.
In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.
In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.
This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).
A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.
And then you have trauma that will say "we cannot change the password because we don't know where it is used".
Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.
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.
IT seems to be a haven for minor dictators to enact their power fantasies
1234abcd@ it is then for all my accounts.
Password rotation does nothing more than get you to use
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!"
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!"
Don't tell them. I don't want to have to enter 30 characters. And it does not help for the people you'd need it for anyway.
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.
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.
That's why we recommend passphrases. That 30 character requirement becomes much easier when it's 3-4 words with a separater. Faster to type, too.
Which does nothing for the "stupid people". I.e. the ones that we put these rules into place for. They'll do what I posted instead (or something else easily guessable and the cycle continues - technological solution to a people problem, i.e. doesn't work)
I would hate to be labeled 'stupid' everytime I don't want to type some 30 dumb characters everytime I login. How about no?
Different difference ;)
I also don't want to type 30 chars, when 15 _properly randomly chosen_ characters would suffice but the "stupid people" chose those 15 characters as "passwordP@55w0rd" and now everyone requires us to write 30 instead because it's "so much more secure" when they write "passwordP@55w0rdpasswordP@55w0rd"
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"
You're all missing the point.
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.
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.
I don't think that is correct at all.
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.
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.
Correct-horse-battery-staple!! is 30 characters and quick to type
Which does nothing for the "stupid people". I.e. the ones that we put these rules into place for. They'll do what I posted instead (or something else easily guessable and the cycle continues - technological solution to a people problem, i.e. doesn't work)
In the corporate space you should move away from passwords entirely.
Smart cards have had pretty solid ecosystem support for the past two decades thanks to the U.S. Government and HSPD-12, and now we’ve got technologies like webauthn that make passwordless authentication even easier.
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.
And require smart card, reader, drivers etc... nah
Every work laptop I've used had a smart card reader directly built into it and I've never used smart cards.
Or a yubikey, or a webcam, or a fingerprint sensor…
In the enterprise, the cost of inconvenience to users is effectively zero. Perhaps even negative as security theater can be a pretty effective way to convince management that something is being done.
There's one weird trick to get people to have strong passwords (even if you force rotation): don't allow them to pick their own passwords. Randomly generate the passwords for them.
Also don't allow them to copy paste the password. And especially don't allow them to use any kind of password wallet. They will really love you for this and you won't get an excessive number of calls to reset forgotten/lost passwords.
Preach.
Gmail doesn't force password rotation, and one can just imagine the type of attacks they must sustain...
Unfortunately corporate policies evolve at glacial speeds...
Unfortunately corporate policies evolve at glacial speeds...
I’m doubtful a 30 digit minimum password is a meaningful improvement over a 20 digit password here. Meanwhile actually typing in very long passwords adds up across a workday/year especially with mistakes.
I think if done right, typing that password should be more like a once a quarter exception rather than a daily occurrence.
Granted - there are blockers to getting there. IDK why for example, macOS can't use Touch ID from a cold boot, that's stupid, at least when there haven't been too many failed attempts or anything.
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.
> macOS can't use Touch ID from a cold boot
Isn't that because the Secure Enclave (the only place which contains the Touch ID biometric data) is locked by your password?
"When a user's password is set up on an Apple Silicon Mac, the password is passed through a one-way hashing algorithm that produces a key used to encrypt the Secure enclave's key."[0]
[0] https://blog.greggant.com/posts/2023/04/14/the-security-encl...
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...
Touch ID isn’t that secure. It’s fine for personal devices, but I wouldn’t trust it alone in a government or cooperate environment.
A ~1:50,000 error rate per finger added sounds fine, but lose a few laptops and have multiple valid fingerprints etc and the odds quickly look significantly worse. Or a janitor could end up trying to log into a significant number of machines etc.
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.
You're only supposed to type your password at most once a day to sign into SSO.
Then how do you suggest authenticating not just in the morning but after lunch, going to the bathroom, any physical meetings, etc?
"Your password is too similar to your previous password"
Hmm, how would you know that.
Hmm, how would you know that.
Don't you generally have to enter the current password to change it to a new one?
Interesting. I guess you could do it on the frontend by asking for old and new passwords simultaneously and sending the hashes to the backend.
That said, it means that you can skip this check by hacking around the front end check haha
That said, it means that you can skip this check by hacking around the front end check haha
By making it less secure. Like those auth schemes back in the day that sounded great in theory until you figured out that in order to implement them the provider had to store them un-hashed. No thanks.
Hash each character.
Bad habits are hard to kill.
Sometimes you just cant convince people that something is no longer recommended.
Sometimes you just cant convince people that something is no longer recommended.
You don't really need to convince people who implement it. You need to convince people creating certification/law, so PCI/SOC2/whatever. I'm still posting every time something like "for the record, I know we have to legally do this, but it's pointless and actually makes us less secure" for a few things.
It honestly forces me to keep a Post-It on my monitor with a hint to this season's new password suffix.
Most SOC2 vendors still require rotation, it is unbelieveably frustrating.
Jesus, it was so annoying so I kept appending a letter after each password reset -> a through z
thankfully my current company let me keep my password for the last 3 years
thankfully my current company let me keep my password for the last 3 years
Password similarity rule was not enforced ?
Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?
In practice, that's probably how it's done. But in theory: no.
Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash.
By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want.
If you only care about similarity to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.
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.
Not if they ask for the current password at the same time.
https://news.ycombinator.com/item?id=44265372
https://news.ycombinator.com/item?id=44265372
Similarly of new vs current password is simple enough by just requiring the current password as part of the password change call. Which is a good idea anyway so someone can't just walk up and change your password if you forget to lock things over lunch.
Similarly vs older passwords is what would be an issue.
Similarly vs older passwords is what would be an issue.
> 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.
Which isn't unheard of, though it's been years since I've seen it.
It probably requires some sort of decreased security (if the password hash is truly slow & secure, it would be hard to enforce dissimilarity); but there might be other methods that leak less than cleartext (like salting and storing hashes of overlapping/separate n-grams from the previous password and checking for number of similar n-grams; etc). Or as another commenter suggested checking all passwords within edit distance 1 (though if you can do that, your password hashing algorithm is likely too fast).
[deleted]
> Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
That is extremely annoying.
On the other hand if I was a manager and that happened to someone I managed we'd definitely have a conversation where I would acknowledge that forced password rotation is idiotic, but also point out that our password expiration is 90 days after the most recent change, which is 12 weeks and 6 days, and ask how come they don't have a "deal with stupid password expiration" event on their calendar set to repeat every 11 weeks?
That gives them 13 days warning. Vacations can be longer than 13 days, but I'd expect that when people are scheduling vacations they would check their calendar and make arrangements to deal with any events that occur when they won't be available. In this case dealing with it would mean changing the password before their vacation starts.
I don't expect people to go all in on some fancy "Getting Things Done" or similar system, but surely it is not unreasonable to expect people to use a simple calendar for things like this?
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?
The fact is that you might have an employee who is a real expert in 3rd century archaeology, but scheduling and password changes just aren't what they are here to do. They don't want to do it, don't know how to do it, and don't want to learn how to do it.
So when they accept an invitation to give a lecture six months from now on the discoveries at the Gudme Hall Complex in Denmark how do they arrange to make sure they will show up?
Hot take, password requirements are a necessity to prevent id10t errors.
Another hot take, calling them passwords instead of pass phrases was a mistake.
People have no problem making a secure pass phrase like 'apophis is coming in 2029’.
It uses special chars and numbers, but some websites would reject it for spaces and some for being too long.
I say these are hot takes despite aligning with NIST because I've never seen a company align with them.
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.
"password too long" for password shorter than a megabyte is the most idiotic error ever created.
It only makes sense in HTTP basicauth and other system that keep plaintext passwords.
It only makes sense in HTTP basicauth and other system that keep plaintext passwords.
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.
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...
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...
In 2025, I don’t think that accessing apple accounts on a non-apple device is a happy path for apple anymore.
"Trust this device" is the modern day elevator door close button.
I've found that it's only american elevator door close buttons that don't work.
The rest of the world manages to keep them operational.
The rest of the world manages to keep them operational.
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.
Then most set the auto-close duration equal to this minimum open duration and you get this appearance of buttons doing nothing.
[deleted]
As a obsessive door close button presser, I can definitely tell you that there are many elevators in Europe where the button doesnt work either
Haha
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.
> 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.
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.
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.
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.
TIL, this now makes a lot of sense, won't be as mad about it anymore.
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.
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 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.
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.
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.
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.
That is the single most useless dialog/question in IT. I wonder how much money that costs the global economy a year.
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.
Adblocking and anti-tracking are mandatory on my company laptop, cannot switch those off. And I wouldn't want to.
This is actually one great use for an MDM policy.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Remembering things reliably must be the most unsolvable problem in computer science.
Unless it's related to advertising. Then it works flawlessly and sometimes survives device transfers and factory resets.
Unless it's related to advertising. Then it works flawlessly and sometimes survives device transfers and factory resets.
"The best minds of my generation are thinking about how to make people click ads."
-Jeff Hammerbacher
-Jeff Hammerbacher
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
How is that supposed to make anyone click on an ad?
Just to expand upon the reference, the comment you responded to is the first stanza of Allen Ginsberg poem "Howl" [0] published in 1956, which is what Hammerbacher paraphrased in the quote that I shared. "Howl" is amazing on its own though, and I highly recommend that people read the whole thing and/or watch the 2010 film about Ginsberg's life where James Franco recites it in its entirety[1]. And as a follow-up, I also highly recommend Scott Alexander's "Meditations on Moloch" that takes inspiration from the poem to analyze societal failures of coordination.
[0] https://www.poetryfoundation.org/poems/49303/howl
[1] https://www.imdb.com/title/tt1049402/
[2] https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
[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/
Thanks for adding the background, much more helpful than my glib nonsense.
I feel that Meditations on Moloch should be mandatory study for anyone who lives in a society.
I feel that Meditations on Moloch should be mandatory study for anyone who lives in a society.
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 ...
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 ...
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.
Windows 95 had this shit figured out on systems running a 486 and 6MB of RAM.
Not just the window size, but if you have more than one monitor, it won't always remember the screen.
Oh, you double clicked to make it bigger? How about making it postage stamp sized in the bottom left of a different monitor...
Oh, you double clicked to make it bigger? How about making it postage stamp sized in the bottom left of a different monitor...
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".
That stops the computer asking, but it doesn't stop the phone asking.
Apple changed this a few years ago, because of a potential security venerability: https://imazing.com/blog/ios-backup-passcode-prompt
Apple changed this a few years ago, because of a potential security venerability: https://imazing.com/blog/ios-backup-passcode-prompt
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.
It’s worse if you say no. It just keeps asking you. I don’t plug my phone into my Mac to charge it anymore. It’s just too annoying.
This is seriously annoying.
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?
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?
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.
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.
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 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'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'm very happy with this extension:
https://chromewebstore.google.com/detail/dont-f-with-paste/n...
https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
https://greasyfork.org/en/scripts/36928-don-t-with-paste (works with Safari)
I get frustrated by having to retype routing/account numbers, or not being able to paste them in the first place. And the ubiquitous e-mail address confirmations. (Given that I still get dozens of e-mails sent to me intended for other people, not spam, just sent to the wrong address, this isn't working. People mistype their e-mail addresses multiple times. You really need to verify the e-mail address by sending an e-mail and asking for a code or a click.)
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.)
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 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.
> Not good business.
As you guessed, most of those aren't businesses and we need them more than they need us.
As you guessed, most of those aren't businesses and we need them more than they need us.
Yes, it’s really bad for security. I just deny it if I don’t know what it’s for. I’m sure I’m missing out on some very important functionality.
My understanding is that iCloud backup requires it, among who-knows-what other things. So I've been reluctant to hit "Not now."
I just have to trust their security model to not allow random apps to pop up and issue those prompts.
I just have to trust their security model to not allow random apps to pop up and issue those prompts.
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.
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.
[deleted]
Something is mis-configured. This isn't the default experience. TouchID works just fine for AppStore purchases.
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.
So Apple wants me to type in my 50+ character password every time I use the App Store app. It’s such a pain.
If it helps there's no security advantage of a 50+ character password over a suitable 16 character one.
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.
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.
My work switched our passwords from minimum 8 digits of upper, lower, numeric and special (requires all 3 present) to a passphrase.
Now its 21 minimum but requires upper, lower and numeric. I guess at least I don't have to stick an exclamation on the end.
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.
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.
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.
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.
- 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.
> Switch to a phrase-based password.
I assume that's why it's 50+ characters long, as opposed to 20 gibberish characters. Because phrase-based passwords are longer. And whether it's 40 or 50 or 50+ doesn't even matter, the point is it's not short like a 6-digit PIN.
I have the exact same problem. It's still incredibly annoying to type on a touchscreen keyboard. If you mistype one character...
So no, it's not the commenter's fault. And it's certainly not mine. I'm doing the best with the tools I have available. It's Apple's fault, mainly.
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.
This is not Apple's intended default behavior.
The various stores use their own biometric auth (the abstraction over touch ID and face ID) settings, which can cause this based on user config, particularly if you're using family accounts of any kind.
The most likely issue is one of these is set to ask every time as many families that share devices with kids consider that a feature, not a bug.
If all possible places are set to accept biometric ID (there's always one more setting than you think to check), it can be something about your network or device itself, particularly if for some reason you show up as if rotating through random geographies or from "unknown" devices.
Modern-ish auth systems (e.g., authentication mechanisms for Google, Microsoft, and Apple) also have a "risk based authentication" ratchet that re-prompts if enough data points are abnormal. Depending on your level of access to admin panels, you may be able to identify what is flagging to re-prompt.
Usually this sort of thing can be traced to something like a per-request VPN with no geographic affinity option, or an ISP (especially mobile ISP) that exits you from random cities across border lines.
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.
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.
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.
Is this for a particular situation(s)?
I do not run into this at all across my apple products.
I do not run into this at all across my apple products.
It literally is Jennifer Lawrence's fault. No joke.
Same with the forced emails you get ANYTIME you login to iCloud via web.
Same with the forced emails you get ANYTIME you login to iCloud via web.
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.
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.
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!)
The Mac pops those up too, now. Utter insanity.
The Mac pops those up too, now. Utter insanity.
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.
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'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.
The really annoying thing is that when I purchase an app on my watch, it makes me type the password on my watch...
How is this a thing?!
How is this a thing?!
Really? I never have to re-auth unless I get a new device.
Same behavior here.
I use TouchID to log in several times per day, and am required to enter a password "to enable TouchID" about once per week. iOS and macOS both.
This feels reasonable to me.
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.
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... :-/
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... :-/
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?
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 keeps prompting for the Apple password again and again
pro tip (for mac desktop, not iphone): drag the dumb prompt off to the edge of the screen ( i drag from top left of the window and drop it to the bottom right of the monitor )
it will not give a 2nd prompt if the first prompt is closed
=> i do this specifically when the 'apple accounts' crap has some issue and forever prompts me to re-login.
edit: clearification
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
I have to change my apple password every single time I need to download an app.
It seems like insane friction for something that is making them a lot of money
It seems like insane friction for something that is making them a lot of money
Same. And annoyingly you're not allowed to reuse old passwords, so you have to keep inventing (and remembering) new ones.
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.
> macOS and Android
> It's my device.
There is your dissonance.
> It's my device.
There is your dissonance.
This is just enshitification in a mask. Next thing you know, guess what? Your device is not yours, you just rent it from the feudal.
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.
I've been pushing NIST on SOC2 auditors for years. They always accept it once given a link.
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".
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".
Yes, it's this rolling on your back and preemptively trying to cover all eventualities that does stuff like this.
It seems like none wants to actually justify their decisions to auditors as its more time critical when the audit happens.
It seems like none wants to actually justify their decisions to auditors as its more time critical when the audit happens.
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.
The auditors aren't writing the compliance guidelines, are they? Just enforcing them.
I'd say you want to send these articles to the people writing such guidelines.
What am I missing?
I'd say you want to send these articles to the people writing such guidelines.
What am I missing?
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.
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.
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.
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.
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.
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.
Ideally we should use the word “waste” to narrowly point at activities that are entirely pointless. Like requiring password rotation every 7 days.
There is no incentive to do so when the shareholders are only interested in the next quarterly earnings report.
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.
Something related that's barely touched in the post:
Bad UX is potential security vulnerability. If your system behaves in unreasonable ways, users are much less likely to notice when it behaves in a slightly different unreasonable way, this time because of a spoofing/phishing, etc.
The obvious example: if your system frequently asks for passwords, re-entering passwords becomes a habit (read system one from "thinking fast and slow"), and the user is less likely to use judgement each time they enter the password.
But also, if an OS makes it hard to find all startup applications, allows untrusted code to run in the background without any visible signs, allows terminal code to access all local files by default, etc etc these all can be abused.
One problem is that human psychology is rarely considered as important a factor as it should be by the average security expert. The other is the usual suspect: incentives. The right chain of responsibilities is missing when things go wrong for people because of mistakes that would be avoidable by proper product design.
Regulation should enforce that, but while everyone would benefit from regulation, no one likes the regulation that will regulate the product/services they offer, and the supplier has upper hand when a change in regulation is being considered because they are focused and motivated.
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.
This is a great take! Similarly, I've seen shadow IT and sneaky work around type stuff crop up a lot before because the "official" way of doing something has picked up too much friction.
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.
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.
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.
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.
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).
UserID -> token is a tiny amount of data.
UserID -> token is a tiny amount of data.
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.
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.
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
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 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
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.
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.
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.
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.
OAuth2 is not inherently stateless.
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.
Ah makes sense
That's a great way to interfere with local work when the network goes down.
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
Access tokens are used for network calls so if the network is down nothing works anyway ?
You mean the power going out is related to why my computer will not respond and the screen went blank? That's strange
Sounds like you want local-first offline-first apps? Me too.
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
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.
> 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.
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.
> The police department getting a court order and forcing you to unlock your phone
If you live under a tyrannical regime, neither passkeys nor passwords will help you. The police state will find a way to do what they want with you.
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.
> SMS gets forwarded to email
This hop is actually more secure than receiving an SMS natively. Your mobile network provider can already read all of your SMS and there are tons of exploits for modifying the receiver of SMS in the wild. SMS is a terrible way to send information securely.
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.
[deleted]
I was somewhat pondering along these lines.
At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for services needing the VPN. And users don't notice much of this during normal operation.
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.
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 :)
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 :)
You don't need reauthenticate for that, you just need to renew existing tokens. Separate the timeouts for authentication and authorization.
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.
From the article:
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.
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.
If an organization wants fingerprint scanners, they just have to provide them. It's about $15-50 per workstation, if desired. The main problem is they use up an increasingly scarce USB port. Some scanners also rely more on security by obscurity rather than protecting the channel. https://www.google.com/search?q=windows%20hello%20fingerprin...
It would be worth doing research to find the best fingerprint scanner that implements this well.
Face scanning is a poor solution because desktops usually do not have Hello-compatible scanners and the scanners on the Windows laptops aren't very good. They frustrate users who prefer darkened rooms or who sit in places with varying contrast from the windows. It is also weird the way the camera is constantly trying to find you, and so it blinks its red LED frequently until the computer goes to sleep.
Just really agreeing with you on security keys, but we also have to make sure they are really secure. Also, like the article says, they give you the device possession part, but not the user ID part, unless they have a biometric device built in.
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.
> The main problem is they use up an increasingly scarce USB port.
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?)
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?)
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.
Few things worse than spending 30 minutes writing something only to be asked to login when you submit it.
Fortunately these days most services will cache your work.
Fortunately these days most services will cache your work.
Though to rely on Jira to respect your work or your browser functionality is madness.
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...
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...
At least for that one, you can now point to NIST recommendations, which finally discourage rotating passwords.
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.
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.
Remember when it was called SINGLE sign on? Emphasis on SINGLE? I mean, this whole idea has been such a mess forever. Why am I prompted to SSO hundreds of times a day?
As far as I've understood/remember SSO was logging on with a single ID and not logging on a single time.
> As far as I've understood/remember SSO was logging on with a single ID and not logging on a single time.
What I remember is that the promise of SSO in the 1990s and early 2000s was that you would login only ONCE, onto your desktop. The operating system would use that login to acquire NTLM or Kerberos tokens, which would then be used to authenticate everything else: shared drives, printers, even web sites would be authenticated using that token (there's a way to pass through your desktop NTLM authentication to a web site, which IME is slightly annoying because it authenticates the connection and not the request, and therefore needs keep-alive HTTPS connections to work correctly).
Of course, that only really works that well in an homogeneous environment, for instance one in which everyone is using a few Windows NT versions on the desktops and all the servers, or one in which both the desktops and servers use the same specific proprietary Unix variant. What instead happened was the rise of heterogeneous systems, which do not share that common authentication mechanism. To make things even worse, each piece of software has its own separate authentication database, often (but not always) a pluggable one which might perhaps be coerced to forward the authentication attempts to another system, instead of directly using the operating system's centralized authentication mechanisms. AFAIK, you can still make it work, but it's a lot of work (for instance, IIRC forwarding NTLM credentials to web servers is disabled by default, and has to be manually enabled and configured to allow a given web server).
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).
> Of course, that only really works that well in an homogeneous environment
It works if no monopoly abuses their position by sabotaging the standard.
OAuth is getting a chance to work because neither Google, Apple nor Facebook are big enough, and they don't play well with each other. At least right now.
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.
You are describing "same sign-on", which is generally less desirable than single sign-on, but at least users only have one set of credentials to remember.
Well, for phones: phones can be lost or stolen. For desktops: an uncomfortable number tend to log in to public computers (eg libraries) without logging out and without understanding the implications.
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.
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.
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.
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.
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.
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.
good point
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.
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.
I just can't stand email OTP.
Before we had passwords, now we have passwords + email OTP. And doesn't matter if you forgot password - you will receive password reset to the same email. You already prove email ownership by resetting or using password - why sending another useless "security token" to the same email. Pure nonsense. Whoever designs all of this clearly has little idea of what they are doing :(
I’ve kind of become a fan of the sites that don’t even have passwords but just email you a “magic” link. If my account security is tied to my email why make me do extra song and dance if I’m gonna have to fish out an email for every login anyway?
I despise this. With username and password my password manager just fills it in and it is one click to click "login".
With email magic link I need to enter my email (it seems to rarely auto-fill for some reason), then wait (often it takes 10s for the email to be sent for some reason), then if I was logging in on something that isn't my default browser I need to copy+paste the link (often just clicking the link authorizes the source session but not always and you don't know what this site does so you need to do it to be safe). Now you are finally logged in but probably have two tabs open. Either you need to find the first one to continue your session (if it logged that one in) or close it and lose your history for that tab (and hope that the website actually maintained your target page which more often than not it didn't).
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).
Nothing tempts me so strongly to give up and leave a site than needing to use a magic link to get in.
Sometimes it takes minutes. I have, on more than one occasion, given up on buying a product because of this. It's actually insane to me how much effort sites put into preventing users from using them.
I get it, most people are idiots with completely non-existent security hygiene, but man does it suck being punished because of just how low the common denominator is here.
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.
And on top of that, the session is probably gonna expire in less than day. I hate logging in to Anthropic because of this signin-email dance
My point is that on sites that force email 2FA you have to do the email dance anyway. A username and password are basically theater.
That's true. Although pasting the code into the existing browser tab is a bit smoother in my workflow. And at least the form autofills properly when they ask for email and password.
I'd much prefer if they could just trust my password. But I know the unfortunate truth is that the majory of people just reuse a password across most sites. So these measures are intended to raise the baseline difficulty, not to improve the security of those with good habits.
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.
My preferred workflow as well, but now many websites are starting to do this thing where you have to enter only your username, hit next, and then the password input shows up; however, the username only input breaks my password manager from trying to autofill! Argh
HomeDepot’s is even crazier. You input just your email and hit Next. Then a button appears to “Send magic link” to login via that annoying method. And then there is a tiny text below: “Want to use a different login method? Wait 10s…9s…8s…”. Only after 10s are you able to select a tiny text link “Use Password” to unlock using the password field
FYI Home Depot supports passkeys which are a significantly better* sign-in user experience than magic links.
*faster + easier (fewer steps)
*faster + easier (fewer steps)
Oh nice, thanks, just set this up! Though seems like I needed to do enable it separately for the web version and iOS app.
Google has been doing this for years, if not over a decade at this point. Password managers have gotten wise about it though, so for some websites it actually works.
The biggest pet peeve of mine in this area is "magic link" auth. Instead of letting you use a password and otp, which can be managed by a password manager, they send you an email so you can click a link to get into their app
That's right, you have to wait for an email to arrive, make it through the spam gauntlet, and then click the link in the email, likely covered in trackers, just to get into a website or app. And here I thought people wanted to keep you in their site as much as possible
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
I'm confused by this comment. Can you clarify exactly which poor design flow you're talking about?
1. Input username/password -> get email otp code.
2. Forget password -> get email for new password -> input username/new password -> get email otp code.
The only actual security factor here is your [email, email password], everything else is just silly rigamarole.
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.
Note that by doing it that way they don't have to have a special case for handling input of username/password when that password is a new password. Making security critical code simpler is generally a good idea.
Whether it is worth annoying some users in the password reset case to avoid making the login code slightly more complicated is going to depend on your specific situation.
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.
I read their point as why have passwords at all when the security is you having access to your email account.
[deleted]
Email OTP can be useful as a layer in risk based authentication.
If someone tries to log on to your site from a low reputation VPN, throwing an email OTP challenge can give some assurance it’s a genuine user logging in. Rather than a spammer or something like that.
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.
Yes, it makes sense if the environment has changed, the device has changed, or if the person is logging in from a higher threat source such as a VPN IP address. However, if nothing changed, it is a waste of time in many cases.
user clicks a phishing link and is asked to login to M365 again, they do it without hesitation because they are used to doing this 5 times a day
logging into phishing links would make more people pause if they didnt have to login constantly to get work done
logging into phishing links would make more people pause if they didnt have to login constantly to get work done
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.
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.
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
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.
And successfully opening a wifi captive portal is the most difficult thing to achieve in all of tech for some reason.
It's even harder than moving a file from a desktop into a telephone on the same LAN with an USB cable plugging both.
Computer security has a problem.
Computer security has a problem.
man, I thought that was just me.
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.
[deleted]
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.
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.
> People might be in bad family situations (where not everyone with access to a shared device
Then they should configure their browser to log them out. Not hope that every site has good settings for their niche scenario.
Then they should configure their browser to log them out. Not hope that every site has good settings for their niche scenario.
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.
It’s all theater so they can sell the idea that they’re doing everything they can, and if something does happen they can shift blame.
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.
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.
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.
Hardly anyone can tell, until everyone can tell, because you have a breach.
It's similar to the idea that if you aren't doing restore drills you aren't really taking backups. But people rarely test their auth rules.
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.
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.
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 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.
Genius. I love it.
I was reading about keyboard firmware last night and saw the ability to do “tap dances”, where a series of specific key presses in short order can trigger a predefined action.
It instantly occurred to me how useful it would be to be able to quickly type “QWE” and have one long complex password input for you automatically. Then “ZXC” for another, etc.
Of course flashing your passwords directly into your keyboard firmware is probably a pretty big security no-no.
But all the places that love to enforce constant password changes with super specific rules sure make something like that sound appealing.
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.
Even worse. NIS2 in the European Union makes password changes legally required for many organisations.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)
I’ve been told PCI does as well, though I don’t know if that’s really still true.
Edit: jjav beat me to it below, confirming it is.
Edit: jjav beat me to it below, confirming it is.
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.
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.
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.
Ha ha ha ha ha.
Where do you live? That’s absolutely not my experience.
Where do you live? That’s absolutely not my experience.
> 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 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 a PCI requirement
The only requirement for password rotation in PCI DSS v4.0 is if the password is the only form of authentication (i.e. no MFA). Use MFA (which you should be anyways) and you don't need to enforce password rotation.
>Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation).
>Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days.
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.
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.
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.
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.
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).
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...
Every four months? If only. I’m required to do it every 30 days for a number of systems. The good ones are every 90 days.
I have one that emails me every 3 months to change my password. Very annoying.
No true Scotsman
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
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
The most secure thing would be to unplug the servers.
edit: I'm agreeing with parent. Availability is part of security. If it weren't, you could unplug the server and call it a day.
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.
There’s another closely related one, changing passwords periodically.
A lot of infosec authorities move away from this.
However, I always wonder, does it make sense for an org to stop with periodic password resets if: 1. the org is not very capable in detecting all account compromises; 2. in practice, users leak their passwords (e.g. by getting phished) and not all of them lead to direct intrusions, some credentials are sold first and it may take weeks/months to cause an intrusion.
I believe that in practice, forced password changes at least ensure that unknown compromised passwords will become outdated at some point in time, and I think that this is positive.
Ultimately, I believe the best thing to do is to move to FIDO2-authentication here.
But I do wonder what are other peoples takes on this topic?
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?
> I believe that in practice, forced password changes at least ensure that unknown compromised passwords will become outdated at some point in time, and I think that this is positive.
password
password1
password2
password!
Password1!
People get predictable on how they modify their passwords when that policy is instituted. Mostly because it's a royal pain in the ass to have to generate a new password AND remember it.
That was one of the reasons that browsers (etc) began offering users randomly generated passwords that either the browser, or a 3rd party tool/service recalling the password on demand.
However that then means the password to the browser/service becomes the unchanging password...
> Ultimately, I believe the best thing to do is to move to FIDO2-authentication here.
Passkeys are an attempt to circumvent this by having (effectively) a key that's attached to some physical device that the user must have access to to prove that they are the authorised user... but... people are circumventing those by storing them in cloud services... which means that the password to the cloud service is... yet again.. the weak point.
> But I do wonder what are other peoples takes on this topic?
For my money, the problem that's being attempted to be solved is unsolvable.
In the physical world we determine identity by citing documents that verify the identity as far as a trusted institution like a government or bank is concerned, and those documents are predicated on documents that may or may not exist (birth certificates) and the assurance that those documents are for the person presenting them, from other people that have been through the same procedure.
The digital world is even more difficult to prove identity with, because everyone looks exactly the same, ones and zeros, the order might be different from one person to another, but they're mutable.
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.
On the password1, password2, password2! flow, yes this happens and is bad, but not everyone is like this. I would say, any change (even a weak one) to a compromised password helps (even a bit). Because it requires attackers to test more passwords, providing more opportunity to detect them.
I agree, on moving the weak point to certain service providers when doing this.
Unsolvable: hm, but isn’t the idea to make it more secure, not necessarily solve it completely?
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?
Very confused about this point:
> Passwords, Face ID, Touch ID — things that supposedly nobody but you can replicate, but which don't prove you're physically near a given device
Password, sure. But the other 2 surely prove that you're both 1) the correct person and 2) near the physical device that scans your face/fingerprint. The article immediately follows that by saying that face/touch ID do both.
> 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.
Please just talk to my ssh agent and stop harassing me with authentication modals asking for tokens and fingerprints.
Finally someone said it. This is a relic from when a row in a database table for a session id cost about $400. I'm joking of course but that's what literally was on the mind of early internet engineers. The only company that fights this is Google and apparently tailscale.
The MFA is getting out of control too. Go to vendor's tool/website, which uses some SSO method and redirects/prompts me to login with the SSO provider. Authenticate to SSO providers, which requires an MFA. Redirects me back to the vendor's tool/website, which prompts for its own MFA. And the vendor's tool's configuration has a security setting that requires all accounts to have MFA, even if they are authenticated via other means.
I need to use SSO with MFA for something. So I sign in.
Every once in a while, the token attached to that somehow expires. Which means that once I have successfully signed in (but before doing MFA) I am redirected to a DIFFERENT SSO system.
I get to login to that and enter its MFA code.
Having now completed all security requirements. I get to enter the MFA code for the original SSO.
Double SSO. Double MFA.
Boy don’t we feel secure.
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.
I have this at my work. One system requires SSO so I go to the SSO gateway, touch my yubikey to login to SSO, and then I am redirected back to the original app, and it also wants my yubikey so I touch it again, and then I am finally granted access.
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.
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.
IMHO there are only 2 requirements for a good password:
1. It must be close to impossible for a computer to guess.
2. It must be easy for a human to remember.
Virtually all password policies focus exclusively on point #1, with the vast majority just giving cargo cult instructions without really understanding the state of the art. Almost nobody puts any emphasis on point #2, which is arguably more important as it is the source of most breaches. If a person can't create a password, ignore it for a week, and then remember it immediately for the next login it's a bad password. This is where requirements like "no more than two characters from a character set (lower case, upper case, numbers, punctuation) in a row" are actively counterproductive. If the password has to be so convoluted that the user is forced to write it down then you've undermined your own security. Worse, it means the help desk will be forced to reset many many passwords which increases the chances of an impersonation attack succeeding.
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.
[deleted]
> Consider enforcing automatic screen lock when you walk away
The corpo "security" dingbats force this on our work machines via profiles -- can't control how long before the screen locks. Thank goodness for the Amphetamine app. I'm not typing in my password every time I stop to think for two minutes, you can fuck all the way off with that.
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.
If you're using a Mac, I find the fingerprint sensor helps a lot.
This has been bothering me for a while now (few years maybe ?) - websites repeatedly expiring my login for who knows what reason. Sure, maybe I can understand for high value trading platform or something.
But no - most mundane sites which most people wouldn’t at all consider sensitive, like HomeDepot / BHPhotoVideo / various online shops, will expire my session within like 24h - seriously, wtf. And significantly more sensitive sites, eg Meta/FB, are usually able to keep my auth for months/years.
I haven’t chatted about it with anyone, as I partly wasn’t sure if something in my setup has changed and whether I’m a minority that fell into some constant reauth bucket. Or whether most of site owners have slowly been using lower and lower auth expiration, causing me a bunch of frustration and friction.
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.
…high value trading platform or something
those are actually ones that don’t do stupid shit like expire passwords… I have had one password for vanguard… and I am in my 50’s :)
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 :)
OnShape (web based 3d editing software) is like this. They have a free tier with public-documents-only option, and it's same there.
Open the page... you have to log in, no way to remember you. Sure, you save your password in the browser, but unless you then also click into one of the input fields, the login button is disabled. Then you work on some 3d stuff, export the file, send it to the 3d printer, some time goes by, browser still open, you get the object, and the holes don't line up, you forgot the wall thickness in the measurements, calipers, yep, 3 more milimeters... open onshape tab, nope, you've been logged out. I didn't even close the goddamn window/tab, it's a free account editing a public document.
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.
Pretty rich coming from a company that only let's you create an account via SSO from the largest offenders of this.
and also requires you to relogin every so often (to be fair it's 90 days not 24h)
and you can just use a custom OIDC IDP with tailscale, for all 15 of us that have custom OIDC IDPs
and you can just use a custom OIDC IDP with tailscale, for all 15 of us that have custom OIDC IDPs
It at least got me to learn how to self-host my own identity provider!
Do tell!
I set up Authentik[^1] on my NAS in a docker container and went from there! Just had to add a .well-known webfinger file to my domain that pointed to the Authentik instance and it "just worked" with Tailscale.
[^1]: https://goauthentik.io/
[^1]: https://goauthentik.io/
Interesting, I'll have to try this. It's still not the anonymity I desire from my private VPN (due to domain requirements) but at least the giants can't rug pull you.
I was working at a crypto exchange for years and completely burned out on reauth. VPN session would die, 20 different SaaS products would log me out, constant interruptions. I’m amazed I never got phished.
They've got the google mail here at work set to make me change the password once per month. The 100-character, unguessable, un-shoulder-surfable password that isn't reused anywhere. In addition to the 2fa I have to use with it. And it will now ask for reauth once per week, which just happens to somehow be 2 minutes before the important weekly meeting I'm supposed to attend which kicks me out of calendar for the link to the Google video meeting.
But at least it makes me reauth.
But at least it makes me reauth.
Anything that generates fatigue doesn't work.
Passwords expiring every 2 months??
Users will user password like "test1" "test2" test3" and so on.
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"!
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"!
Humans shouldn't generate passwords. ~0 people are good at that. Websites should just generate a password for a user, letting them regenerate as many times as they like until they get one they like (without breaking password manager based generation). A bit like this: https://peergos-demo.net/?signup=true
~0 people want to remember passwords. generating passwords for them without offering to securely store them in a password manager strikes me as misguided.
People should absolutely be using password managers where possible.
A website doesn't have control over whether you are using a password manager though. This is about stopping the human from generating a password themselves, which will be terrible.
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.
I mean, at this point might as well drop the password requirement completely and send an email login link every time a user gets logged out and wants to log back in. It's how 'reset password' feature works for some people anyway.
Yep, if that's possible for your service that works. If the service doesn't want your email and/or doesn't have access to your data, e.g. an E2EE service where account reset is impossible, then that's not an option.
The supposition for all this is that the service wants to use passwords for whatever reason. In that case, generate them for the user.
The supposition for all this is that the service wants to use passwords for whatever reason. In that case, generate them for the user.
I have really strong opinions against the device-secured biometric stuff. On my own devices, I will never use it as it dramatically lowers my security posture.
Further, the development of this ecosystem is to the exclusion of alternative OSes. Windows Hello and whatever apple wants to call their suite of biometric goo is elevating them to a place in my life that is unacceptable by virtue of the unwarranted trust granted to them.
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.
Microsoft has ruined their PC games with this. I hesitate to fire up Minecraft or Master Chief Collection these days because I just _know_ it is going to make me reauth for no apparent reason. I took 2FA off my Microsoft account because of this, so congrats.
These are a video games, not a bank account! Please just let me have fun!
These are a video games, not a bank account! Please just let me have fun!
Yea, it's nuts having to reauthenticate constantly on an Xbox, especially with a randomized password. They changed it recently where you can scan a QR code I guess, but whoever implemented that system is completely disconnected from reality.
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.
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.
15 seconds?
I’ve never heard of anything like that. The recommendation I’ve always seen is 15 minutes.
Seems like you could quickly run afoul of that just from a spotty Internet connection.
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.
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.
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.
I don’t need to charge often, but I’m logged out of every single one of my charging apps for that reason. They kick me out constantly.
If you want me to auth to make a payment when starting a session, fine. I’ll hate you, but whatever.
Nope. Can’t even get into the app. Want to see where their stations are? Too bad. Sign up, sign in, or hit guest mode and prepare to be annoyed.
I can stay signed into Amazon with a credit card set up for years at a time.
God forbid I ever want to charge a car.
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.
OWASP still recommends regular expiration: https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...
I hate the corporate office 365. How many times on the same corporate laptop on which I log in from home do I need to reenter outlook password and 2FA.
I seriously think ms365 login chain is straight broken Click here to sign in - enters userID and pass - thanks for logging out :o
I seriously think ms365 login chain is straight broken Click here to sign in - enters userID and pass - thanks for logging out :o
You should be angry at whoever set it like that. In O365 you can sessions last as much as you want.
Currently MS recommends a 90 day window between MFA re-authentication for known devices/browsers you already authenticated on.
Currently MS recommends a 90 day window between MFA re-authentication for known devices/browsers you already authenticated on.
Needless to say, this is an ad for Tailscale. I hate these short-lived sessions myself, but there are oftenreasons why they're there.
The alternatives proposed are "just always check right before a sensitive action" and "use continuous verification". Both of which are much harder to pull off correctly than short-lived authentication sessions (unless you buy their product, of course, supposedly), especially on third-party services you don't control the source or manage the deployment for.
Oh, and of course, "just make everyone lock their screens". If only it was that easy. If basic rules like that worked, we could ditch half the security measures we have for websites. What's next, "just use unique passwords of 20+ characters for each website"?
Also, this is putting a lot of trust in solutions like Windows Hello. I can't speak for the security of Apple's implementation, but thanks to bad vendor implementations (including Microsoft's own!), Windows Hello hardware is full of security holes. At some point one company decided to take a look at a few of those devices [and found security problems in all of them](https://blackwinghq.com/blog/posts/a-touch-of-pwn-part-i/).
Short token longevity also protects against one use risk Tailscale have a solution for: users logging in to their personal accounts on public computers. That's still an essential use case for people without internet access or computer access at home. Often these people are more vulnerable (homeless, very poor) so relying on them clicking the "log out" button on every website they're forced to interact with is not going to work.
Kerberos (or buying what Tailscale sells) does offer a somewhat nicer authentication flow, but that still doesn't work reliably on every browser on every OS on every device and it requires people to follow basic rules like "lock your screen", which is a massive risk. Passwords will always work anywhere and their security can be somewhat enforced.
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.
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.
I don't get why asking for a password multiple times is perceived as more secure. It's the same password. If an attacker was able to find it and input it once, surely they can do it multiple times too...
It's not about asking for the password, it's about expiring sessions frequently. Nobody is going to steal sessions, of course, but the cargo cult security remains.
And then there is AWS which has 3 different products to log in and will sign out randomly and then redirect you to the wrong login page seemingly at random whilst in the middle of incident response
I don't know, I still think it's a good idea to change passwords every so often. At the rate databases get leaked, you can't always rely on the strength of the hash and the time it used to take to crack given hardware getting faster and faster. Yes it can cause a minor inconvenience if locked out, but that's better than the alternative depending on what that system was.
But...worry not, we're about to embark on a world with a whole lot less security now thanks to AI and laziness.
But...worry not, we're about to embark on a world with a whole lot less security now thanks to AI and laziness.
Here's 2 or 3 cents:
- Websites should (in agreement with TFA) just remain logged in (at least for 24 hours). Let the OS handle it.
- Public computers should only ever provide ephemeral login sessions. Everything cleared upon each login. Never persist anything to disk.
- Personal computers should reauth frequently, but should use adaptive authentication: i.e., password sometimes, and pin/fingerprint other times, where reasonable. Since "reasonable" is debatable, this should be configurable by the user at the OS level.
- 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.
Google Workspace defaults to making you sign in every 2 weeks unless you have a certain upper tier of paid account with them.
Even worse is that if you try to search for the feature and click on it, it presents a page that unhelpfully returns 404.
It's annoying AF.
"By default, the web session length for Google services is 14 days." https://support.google.com/a/answer/7576830?hl=en
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
Does that mean Tailcale will stop doing it? Currently they require you to log into every node and reauthenticate it every now and then, unless you disable key expiry.
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.
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.
There's "disable key expiry" per machine in the tailscale admin panel
Sure. All true. But PCI compliance requires 90-day password rotation which might not be required if you’re using multi-factor authentication (MFA). In other words, in the case of MFA, that requirement might be waived: and the operative word here is might.
So, if you’re pursuing PCI compliance people don’t rely on assumptions or conditional language like might. Certainty is key when dealing with compliance frameworks.
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.
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 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).
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).
Who said it wasn’t locked?
>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.
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.
"Shoulder suffering" a funny one ; )
Also, there are shields for screens which basically hide it from anywhere not directly in front
Very useful for people who work in trains and stuff: their neighbors can't see things
Very useful for people who work in trains and stuff: their neighbors can't see things
Please repeat this to every moron involved in security theatre. This is turning into a pain in the ass in the industry for no reason
[deleted]
Wouldn't frequent reauth be beneficial for stolen sessions?
E.g. If you set your session timeouts to a ~1 day then by the time your session cookies are up for sale on the dark web, they will be expired.
The article doesn't mention this and it's the main reason I advocate for auth sessions that are as short as practical.
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.
If your session cookies were stolen, they can be stolen again and again too? Timeouts of 1 day assumes the cookies can only be stolen once.
recently came to appreciate the irony in proving who we are via catchpas, password complexity, and context switching 2FA is that any security method without personal irritation will get automated and broken. therefore, all security requires for us to prove the authenticity of our being by demonstrating suffering somehow- and an authentication method without evidence of suffering cannot prove we are real.
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.
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.
Zoom has been driving me nuts with this lately. I have to reauth with OTP 3 times a day, while logging in on the same computer on the same LAN with the same browser. I spend over $1500 a year with Zoom, and this issue is seriously making me think about how I can migrate to something else.
I very much agree with this article. But many companies are still under the idea of a complex password, instead of a long one. A "secure" password is not random character vomit. A secure password is a pass-phrase with multiple words and characters intermingled.
But it is easier to implement and maintain so it will continue to be the default.
> What are we really checking?
That the security policy for the user and the resulting access key hasn't changed their level of access?
Identity, while the most common use case, is only half the system when federating logins.
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.
Why would you need to reauth for that?
Validated the user that logged in is still the same person.
I just joined a fintech company. It is so crazy, everything logs out daily, to login you have to input a complex password plus the 2FA, you have to run everything through a Citrix VDI. Really bad.
Only once a day? Sounds heavenly. Try every time you turn around and use your air-gapped dev PC for 5 minutes, while trying to keep a reference PDF from online up on your corporate PC to read.
A minor recommendation: remove the word “just” from the following paragraph.
> At Tailscale, we believe in security that’s adaptive, intelligent, and actually useful — not —just- security theater.
> At Tailscale, we believe in security that’s adaptive, intelligent, and actually useful — not —just- security theater.
I'm trying to understand why my Rails application constantly logs me out in my iPhone/Chrome.
The same web app stays logged in forever in my mac and I access both of them with the same time intervals.
The same web app stays logged in forever in my mac and I access both of them with the same time intervals.
The previous company I worked for did this kind of frequent expiration, made for a good 2-3 days off every 3 months because I sure as hell wasn't going to set an alarm on the date.
Stealing session tokens is a common technique to get around MFA, deployed by malware everywhere.
I don't like it, but frequent reauth does limit the blast radius of stolen session tokens.
I don't like it, but frequent reauth does limit the blast radius of stolen session tokens.
Funny because tailscale arbitrarily expires tokens on machines and doesn’t expose a way to see token age to the user (but does allow your IT admin to renew a token).
My personal pet peeve is restrictions on what characters can go, have to go, into a password
Security theater, not really as it makes passwords less secure
Security theater, not really as it makes passwords less secure
Might be tangent, but Cursor has this the worst. Each time you close the browser and open, you're logged out. I have no idea why they do this.
Google hasn't asked me to re-enter my password for years. If your users are the product this must make financial sense.
No, but it's a good excuse to require MS authenticator on my phone...
Zero trust states that you don’t implicitly trust an entity even if they were previously authenticated. So is this a critique of zero trust? More productive might be to say that we shouldn’t blindly force reauth if our risk profile doesn’t warrant it - just like any security mechanism.
OMG I wish that someone would tell this to Apple.
Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.
Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.
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.
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.
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.
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.
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
Hence... Session cookie, even if set without expiration date
Session cookies are cookies that identify a session. They last however long you specify. A bank forces quick session expiry. Amazon doesn't.
Compare https://docs.djangoproject.com/en/5.2/topics/http/sessions/ .
> To use cookies-based sessions, set the SESSION_ENGINE setting to "django.contrib.sessions.backends.signed_cookies".
> When using the cookies backend the session data can be read by the client.
> A MAC (Message Authentication Code) is used to protect the data against changes by the client, so that the session data will be invalidated when being tampered with. The same invalidation happens if the client storing the cookie (e.g. your user’s browser) can’t store all of the session cookie and drops data.
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.
No, they're not. This terminology is well-established.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
[deleted]
You can believe what you like, but that won't change what people mean by the term "session cookie".
If you try to communicate with other people using that definition of "session cookie", your communication will fail.
If you try to communicate with other people using that definition of "session cookie", your communication will fail.
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.
[deleted]
[deleted]
I set my browser to clear cookies on exit so that my cookies cannot be stolen by malware.
Why do you think malware can't steal your cookies when the browser is open (and I assume it is open for most of the day)?
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.
> 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.
Most sites do not use session cookies for auth, they use persistent cookies.
[deleted]
This kind of goes along with my ongoing pet peeve about DX in general. There are very few organizations I’ve worked with that actually care and put their devs first. Case in point, I worked on a contract a few years ago with very frequent reauths where you had to enter your PIV card PIN about every 30 min. Obviously something was not configured correctly, but when we complained we were told that that was their security policy and to go pound sand. It made everyone so frustrated that productivity took a huge nosedive. I remember one day I was in the middle of trying to analyze something very tedious and having anxiety about the next time that dialog would prompt me for my PIN. Sure enough it happened, and I just gave up. I left my laptop, took a walk, and did nothing for the rest of the day. Eventually someone important petitioned for us and it was fixed, but I can’t begin to calculate how much money this wasted in terms of unproductive contract hours.
Okta / Lumos are the biggest offenders of this.
I suspect in that case it's to get their name in front of people's faces for marketing purposes. If things are actually seamless enough that you don't need to re-auth, you won't be reminded that their company exists.
They dodged what to do about SSO and SAML. With SAML I don't necessarily know (as a coder) who will be the IdP or what protocol there will be for up to date authorisation info.
Looking at you Beatport!
That's okay, soon we'll have 8 hour ssl certs to go with this crap.
I disagree with the general advise behind this, even when I'm in a household with trusted (most of the time) family members. Forcing a re-auth ensures that even if I forget to lock my machine/browser, someone can't snoop around. I want this to be the norm especially for my Macbook since for whatever reason, I might forget to lock or have some program running that'll force the laptop to not auto lock out (e.g. while downloading something that takes a long time) so I don't want someone to be able to seize that opportunity.
It's the same reason I intentionally lock up apps with TouchID when there's remotely anything sensitive in there. I just don't want someone to be able to snoop if I forget to lock my phone.
I'll say however, there should be easier ways to reauth in such scenarios. Like in my case, TouchID is not very disruptive to my work even if a prompt appears. I'll also say it's probably stupid to lock out when there's continuous activity (should lock based on inactivity period).
The worst offenders in my experience are banking apps. They:
It's the same reason I intentionally lock up apps with TouchID when there's remotely anything sensitive in there. I just don't want someone to be able to snoop if I forget to lock my phone.
I'll say however, there should be easier ways to reauth in such scenarios. Like in my case, TouchID is not very disruptive to my work even if a prompt appears. I'll also say it's probably stupid to lock out when there's continuous activity (should lock based on inactivity period).
The worst offenders in my experience are banking apps. They:
- Force logout sometimes regardless of ongoing activity
- Log out as soon as I close the tab
- Log out when I press the back/reload button
- After logging out, impose a mandatory inactivity period before I can login again (this is just the most idiotic thing EVER)
- Use JS to block any kind of copy/paste operation on username/password fields
- Never integrate with modern auth mechanisms, not even app-based TOTP!
- Have crazy password expiry windows (like every quarter) and force password change when your previous password expires, regardless of how strong they are> Log out as soon as I close the tab
For a banking app, I think this is fine. A lot of people aren't aware closing a window isn't logging out. The rest of that is dumb, though.
For a banking app, I think this is fine. A lot of people aren't aware closing a window isn't logging out. The rest of that is dumb, though.
Nah, that is dumb too. I get what you’re saying though. They could even ask and confirm if that’s the case while logging in and let me have a persistent session on my own machines.
I'm so tired of the enforced password changes, that I just write them on a post-it note now.
Heroku's 25 hours comes to mind... this is so infuriating and annoying.
I litigated the "sign back into SSO and every downstream login every four hours" with my IT team. They held their ground. So much money is being lit on fire with the time wasted.
lol tell that to the people that want 15 day length TLS Certs.
A curious thing with security is that a lot of measures companies take aren't about your security but about liability and control. Most security theater is motivated by that. Your inconvenience is collateral damage to that. Apple and Google don't worry about you getting hacked but about you suing them after you get hacked. That's the risk they are mitigating. Or worse, you jumping ship to the competitor. They want you dependent on your account with them.
So, when Google single signs you out mid meeting (has happened to me), they don't care about how stupidly annoying that is. That's just them asserting that if anything bad happens to you, it was your own fault and not their failing.
And then a secondary thing that makes life even harder is that instead of working together they are considering single sign on mechanisms as control points that they can leverage to keep the relationship with 'their' users exclusive. So Google and MS both do very similar things but they don't trust each other's Identity Providers (IDP). That's not an accident. That's intentional. MS has been on a decades long mission to 'own' all logins, and of course they've been failing to get there just as long. Likewise, Google and Meta have been fighting over this as well. And the net result is that you don't have just 1 account to worry about but gazillions. That's why every silly little app has its own stupid email/password thing and why onboarding friction is the biggest hurdle to users adopting these.
These are the primary motives driving this mess. Companies don't collaborate, so security stays complex and messy. It's also the reason that passwords (long discredited as a reliable way to authenticate) are still a thing. If we had effective federated IDPs like OpenID where everybody could use and IDP of their choice and use it to authenticate it with pretty much everything and the kitchen sink, you wouldn't be using passwords ever. That was envisioned as early as 20 years ago. Google, MS, Meta, etc. blocked every attempt to make that happen by never mutually trusting each other, or any other IDP not operated by them. They all implement some version of OpenID 2.0 (with enough differences to make supporting all of them a bit of a journey) but they deliberately don't whitelist any external IDPs and jealously continue to fragment the security landscape by guarding their walled gardens.
They've been engaging with each other in backroom standardization attempts ensuring that the status quo is never allowed to change for decades. The latest move in this war: pass keys. Nice solution on paper. But you got to have the Google version of it. And the MS version. And all the rest. Sigh. Because, obviously, by design these will never delegate to each other. They trust each other even less than they trust you.
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.
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).