OWASP still recommends regular expiration: https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...
Frequent reauth doesn't make you more secure
441–450 of 539 posts
Re: Frequent reauth doesn't make you more secure
#442Forced 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…
IT seems to be a haven for minor dictators to enact their power fantasies
Re: Frequent reauth doesn't make you more secure
#443Earlier quoted context omitted.
I've been pushing NIST on SOC2 auditors for years. They always accept it once given a link.
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.
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.
Re: Frequent reauth doesn't make you more secure
#444Yahoo 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.
Do you have a link to that Yahoo publication? Or any more information on it?
probably not
Re: Frequent reauth doesn't make you more secure
#445This 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.
Re: Frequent reauth doesn't make you more secure
#446I 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 :(
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
Re: Frequent reauth doesn't make you more secure
#447Corporate 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.
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.
No true Scotsman
Re: Frequent reauth doesn't make you more secure
#448Earlier quoted context omitted.
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…
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…
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
Re: Frequent reauth doesn't make you more secure
#449Earlier quoted context omitted.
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."
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.
Re: Frequent reauth doesn't make you more secure
#450Forced 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…
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.