Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frequent reauth doesn't make you more secure

tailscale.com

Post reply on HN
Print view View original

421–430 of 539 posts

Re: Frequent reauth doesn't make you more secure

#421

Post by chillfox »

montebicyclelo wrote: post #189

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. Many (most?) companies still do it, despite it now not being recommended by NIST: > Ver…

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.

Re: Frequent reauth doesn't make you more secure

#422

Post by qualeed »

ExoticPearTree wrote: post #401
qualeed wrote: post #76

Earlier quoted context omitted.

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 secur…

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).

Re: Frequent reauth doesn't make you more secure

#423

Post by Freebytes »

spacebanana7 wrote: post #184
vizzah wrote: post #178

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 :(

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.

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.

Re: Frequent reauth doesn't make you more secure

#424

Post by Freebytes »

al_borland wrote: post #47
paxys wrote: post #16

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.

Re: Frequent reauth doesn't make you more secure

#425

Post by twodave »

mooreds wrote: post #299
twodave wrote: post #63

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 helpfu…

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?

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.

Re: Frequent reauth doesn't make you more secure

#426

Post by circular_logic »

valenterry wrote: post #20

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

Re: Frequent reauth doesn't make you more secure

#427

Post by ToucanLoucan »

chillfox wrote: post #421
montebicyclelo wrote: post #189

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. Many (most?) companies still do it, despite it now not being recommended by NIST: > Ver…

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…

Just an unbreakable law of the universe.

"Why did this stupid shit happen? Oh, it's money again."

Re: Frequent reauth doesn't make you more secure

#428

Post by tetha »

maccard wrote: post #370
tetha wrote: post #27

Earlier quoted context omitted.

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 service…

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 d…

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 :)

Re: Frequent reauth doesn't make you more secure

#429

Post by eqvinox »

claudex wrote: post #382
pcardoso wrote: post #377

Earlier quoted context omitted.

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

There are also systems that keep a history of old passwords just to prevent you from reusing one.
Post reply on HN