If this is a login for a work/school account, it’s because someone in your IT department thinks that applying a short “max session length” policy is “extra secure”.
Basically no different than shitty password rules or some places that make you change your password every 90 days.
If your session gets hijacked, max session lengths ensure the attacker doesn’t retain access once the session expires. It’s more likely someone in your company was phished and the attacker retained access to their Outlook for a few days or weeks before anyone noticed.
The weakest link in any system is the user, not the security policy (or lack thereof).
I’ve seen this particular policy aggravate users to the point where they would rather export sensitive company data onto their own personal machines rather than deal with having to reauth once per hour into some Entra ID SSO-backed web app.
Or even users who generate service account credentials that they share around with their team such that nobody uses their own account to login anymore
When your policy teeters towards aggravating users, many of them will just find clever ways to circumvent it, which is a losing situation for everyone.
Correct. No policy is an adequate substitute for security training or phishing awareness training. That doesn’t mean to allow abuse cases though
export sensitive company data onto their own personal machines
Intune can be (and usually is) used to enforce logins only from enrolled devices. Personal devices can be enrolled, then Conditional Access policies can be applied to silo app data from company data, preventing this abuse case
reauth once per hour
No way. One per day, at most. No one should have to re-auth every hour, except maybe Global Admin accounts, which shouldn’t be used for day-to-day tasks anyway.
users who generate service account credentials
To do this in Entra, you need the Application Administrator role assigned, which is a Privileged Role, so it should be controlled by PAM to prevent/detect this abuse case.
When your policy teeters towards aggravating users, many of them will just find clever ways to circumvent it
Not for long. And usually not without leaving an audit trail that indicates violating acceptable use policies, security policies, or access control standards, which then becomes an HR issue, not an IT issue
Half that at best. Unless you have people regularly working 12-14 hour shifts, 24 hours is excessive (and will annoy your employees more because that 24 hour clock will slowly migrate later in the day throughout the week - the expiration is never exactly on your limit in my experience).
The security: Since I have to retype the password every 5 minutes it is now recorded on every security camera system in a 20 kilometer radius.
I can remember long random passwords, but I am still too paranoid about them being recorded. I think I even saw something about predicting passwords based on delay and sound of key presses from recorded audio.
Well, when do you see the content of my private key? Never. Hopefully never, anyway. Same for cookies.
Ideally you’d be able to use a password manager to autofill your passwords, but if you’re on company hardware, they may not allow you to install the password manager. May be able to get IT to make an exception since it should only boost your security.
If you have to use shared hardware, then that sucks, I’m in the same boat.
it’s because someone in your IT department thinks that applying a short “max session length” policy is “extra secure”.
And that person is right, up to a point at least.
If you hijack my session, a short session lifetime explicitly kicks you out at the end of my original seasion, and you have to re-hijack. Assuming you don’t have both factors, it’s an easy way to limit the foothold of an attacker and make them have to try even harder. Cranking it too low will do the opposite, but we have more than a standard work shift for our session length, and it’s more than long enough to not be a massive annoyance.
If this is a login for a work/school account, it’s because someone in your IT department thinks that applying a short “max session length” policy is “extra secure”.
Basically no different than shitty password rules or some places that make you change your password every 90 days.
If your session gets hijacked, max session lengths ensure the attacker doesn’t retain access once the session expires. It’s more likely someone in your company was phished and the attacker retained access to their Outlook for a few days or weeks before anyone noticed.
The weakest link in any system is the user, not the security policy (or lack thereof).
I’ve seen this particular policy aggravate users to the point where they would rather export sensitive company data onto their own personal machines rather than deal with having to reauth once per hour into some Entra ID SSO-backed web app.
Or even users who generate service account credentials that they share around with their team such that nobody uses their own account to login anymore
When your policy teeters towards aggravating users, many of them will just find clever ways to circumvent it, which is a losing situation for everyone.
Once per hour is just stupid, but once per shift is reasonable in my opinion.
If your users can’t be bothered to auth once a day, they probably shouldn’t be working with anything remotely sensitive.
Correct. No policy is an adequate substitute for security training or phishing awareness training. That doesn’t mean to allow abuse cases though
Intune can be (and usually is) used to enforce logins only from enrolled devices. Personal devices can be enrolled, then Conditional Access policies can be applied to silo app data from company data, preventing this abuse case
No way. One per day, at most. No one should have to re-auth every hour, except maybe Global Admin accounts, which shouldn’t be used for day-to-day tasks anyway.
To do this in Entra, you need the Application Administrator role assigned, which is a Privileged Role, so it should be controlled by PAM to prevent/detect this abuse case.
Not for long. And usually not without leaving an audit trail that indicates violating acceptable use policies, security policies, or access control standards, which then becomes an HR issue, not an IT issue
Yeah but it should be 24 hours at least
I’m sympathetic, but I’m of the mind that it should just be the duration of the workday. Certainly not an hour like some places.
Half that at best. Unless you have people regularly working 12-14 hour shifts, 24 hours is excessive (and will annoy your employees more because that 24 hour clock will slowly migrate later in the day throughout the week - the expiration is never exactly on your limit in my experience).
If it makes you feel
worsebetter, those security professionals are usually paid more than most ITs, sometimes over $200k a year.Drives my dad insane because his security person at City Hall might be the dumbest human being alive.
Yeah, my boss routinely shares logins for things over slack group channels. 😟
Hi! It also does it for personal accounts
The security: Since I have to retype the password every 5 minutes it is now recorded on every security camera system in a 20 kilometer radius.
I can remember long random passwords, but I am still too paranoid about them being recorded. I think I even saw something about predicting passwords based on delay and sound of key presses from recorded audio.
Well, when do you see the content of my private key? Never. Hopefully never, anyway. Same for cookies.
Ideally you’d be able to use a password manager to autofill your passwords, but if you’re on company hardware, they may not allow you to install the password manager. May be able to get IT to make an exception since it should only boost your security.
If you have to use shared hardware, then that sucks, I’m in the same boat.
on company hardware, I can install and browser in my %userprofile%, then can put any password addon I want.
It could also be that is an application requesting access using an embedded browser, which is basically like an incognito/private window.
Yeah and now we all installed browser plugins to keep the session alive permanently for our password manager
And that person is right, up to a point at least.
If you hijack my session, a short session lifetime explicitly kicks you out at the end of my original seasion, and you have to re-hijack. Assuming you don’t have both factors, it’s an easy way to limit the foothold of an attacker and make them have to try even harder. Cranking it too low will do the opposite, but we have more than a standard work shift for our session length, and it’s more than long enough to not be a massive annoyance.