If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

(I appreciate that you're arguing for charitable interpretation, but the personal swipes at the beginning and end of your post wipe out the good effect and then some.)

https://news.ycombinator.com/newsguidelines.html

The problem with 'defense in depth' is that it comes as close as possible to locking down systems to the point of uselessness, without actually, technically, preventing work from being done.

If you want to defend in depth - more power to you.

If the way you're "defending in depth" is mostly not adding security, and is actively making the product less useful... I'm going to call it shite.

If you blindly say "defend in depth" without actually... you know... evaluating what that defense does to the product as a whole, you're doing your job poorly.

Maybe the OP wasn't blindly saying 'defend in depth'? Maybe they were advocating for evaluating what that defense does to the product as a whole? If they were, is their attitude worth describing as cancerous?

My take: you're stuck on the word cancer as some sort of insult, rather than an analogy. I'd argue you're being fairly uncharitable in your responses - and further... you're yet again not engaging with the actual on-topic discussion.

Have a good one.

> If you want to defend in depth - more power to you.

> If the way you're "defending in depth" is mostly not adding security, and is actively making the product less useful... I'm going to call it shite.

Agreed. Sure, there is defense at different depths, but there's no reason to add depth without adding defense as well.

Except that it's not a matter of 'convenience', it's a matter of being able to do their jobs. Security is a hard job, in part because you have to come up with security practices that are actually workable, and keep work impediments to a minimum. It's really easy to just add more restrictions. It's hard to add security that doesn't impede the users. When I see 'defense in depth' being invoked to justify massive work impediments for minimal security improvements, I don't see effective security practices - I see a cargo cult.

One which can be made reasonably, without telling anyone that their attitude is cancerous.

We are discussing ideas about security in a place and manner that allows us to have honest and frank conversations.

I think security teams optimizing only for security is actually very apt analogy to cancer: Part of the organization is acting in a manner that is negatively impacting the organization at large - while positively impacting that subset of the organization.

Cancer is the act of some cells in your body prioritizing themselves at the expense of the whole.

Personally - I think you're digging to find an insult in that comment, and I take it as a way for you to disengage with the topic at large.

This is an attitude that is routinely used to shut out voices that don't match the current "dress code".

Trust me, I'm hardly going to be calling you cancer over the dinner table for not passing the salt. I'm using that word intentionally and carefully - in a frank and honest conversation. If you're feeling hurt (especially on behalf of someone else...) maybe go do something else?

No, that's a problem with bad engineering. That a process requires skills most people attempting it don't have isn't a problem with the process, it just means that it is hard and relatively new.

One thing I see all the time that demonstrates this incompetence is talking about something being more or less "secure" without reference to a threat model. You simply can't make reasonable tradeoffs without thinking this through, and yet nobody wants to do the exercise.

In fairness, this is not just an engineering fault. I've seen one case where a legal department freaked out when they heard about a risk analysis project in pursuit of a formal threat model - they vehemently objected to anyone producing documents about such things that could potentially surface in some discovery fight.

Hey - I completely 100% agree. Believe it or not, I did quite a stint in software security before becoming this jaded (5+ years fulltime work at a security focused product sold primarily to large fortune 100 companies [banks - it was all banks]).

I think my problem is that for any difficult challenge... there is an answer that is simple, obvious, and incorrect.

My opinion is that the incorrect answers I see most are the two extremes: I don't care about security (BAD!). I only care about security (WORSE!!!!).

The first will eventually lead to compromised accounts/data and that can kill a company. The second will lead to products no one wants to use, which WILL kill a company.

Neither is a good spot to be. You want to find an appropriate compromise in the middle: Secure enough.

----

Side note - no one truly does the threat assessments based on threat model because no one in industry likes the answers.

For small and inconsequential threats - you are already secure enough.

For nation states - there is likely no solution that is workable if the thing is on the internet.

It's like trying to buy a secure door for your house: For most folks walking down the street, the current door is fine. When the Gov shows up with tanks - there is no door you can buy to solve the problem.

It seems to me that 'defense-in-depth' can very easily become a mantra that inevitably means drifting towards the latter. What are the real guidelines for telling when enough is enough? Because ime people who even can articulate anything along those lines are way, way fewer than people who make appeals to defense-in-depth.

And I think this is part of the problem: without a principled way to assess what is gratuitous, repeated appeals to defense-in-depth will lead to security practices that heavily favor having more measures in place over having a good UX. This is because the environments where information security is most valued are already organizations that frankly, do not give a shit about UX. The customers for cybersecurity products are massive bureaucracies: large enterprises, governments, and militaries. The vendors that sell those products are embedded in a broader market where no software really has to be usable, because there's a fundamental disconnect between the purchasing decision and the use of the software. For all B2B software, the user is not the customer, and it shows in a thousand ways. In infosec things are further tilted in that lots of easy routes to compliance which are terrible for UX are falsely perceived and presented as strictly required, perhaps even by law.

The idea that in a B2B market which primarily serves large organizations and governments, you will get any organic weighing and balancing of security against usability 'for free' is sheer fantasy. So where is the real counterweight to the advice that on its own recommends 'always add more, unless you have good reason not to'?

It's also why I strongly link this argument to cancer. It's an idea that grows unbounded until it's harmful, and by the time the organization realizes the harm, it's often too late to change.

Yep. I think your argument pretty much conveyed the same thing, along with a lot of anger and frustration.

I also agree with that anger and frustration— I've felt the same rage before, when I've been hit with blockers or UX degradation related to nominal or actual attempts to improve security. Restrictions that are ill-motivated (or whose motivations are just not clearly or convincingly communicated) are infuriating.

> by the time the organization realizes the harm, it's often too late to change.

This worry is the twin of the rage, for me, this sense that I can't do anything about it and it's never going to get better. A dreadful, reluctant admission to myself that the only way to stop the continual degradation of my work life will be to uproot myself: give up my job and everything I do like about it, leaving behind people I enjoy working with and reducing the amount of contact I have with them.

Happily, engaging directly with my company's infosec department directly often gives me hope and allays these fears somewhat. But generally, online discussion with people who implement security controls tends to reinforce my worry that, to borrow your metaphor, the disease is systemic and terminal.

Most 'cybersecurity professionals' (who are visible online, at least) transparently do not give a shit about UX, display flagrantly antagonistic attitudes about users and developers, and talk often about defense-in-depth but never articulate any inherent limits for appeals to defense-in-depth beyond 'well don't bother with measures that don't increase security at all'. All of it sends strong signals that people who value UX, DX, autonomy, morale, and well-being, to the extent they are present at all, are outliers in infosec who do not belong and have no hope of being effective.

And then the response to someone openly including a dimension of emotionality in an argument about a security measure they feel is gratuitous and cumbersome is

> Did... did [a cumbersome security measure] hurt you?

Like, seriously? Yes. Indeed it did and does.

But more than the security measures themselves, the pervasive attitude conveyed by that belittling question is the even bigger problem. And it generates many of the small ones.

You are - you're literally arguing for it right now. Short sessions just don't help all that much, and they have an outsized impact on users.

Why are you dying on this hill? Likely because your mindset is "security above all else" and that mindset is literally cancer.

Security above all else leads to a product that does fuck-all else (and it does it poorly).

I would say it makes an excellent analogy: A part of the whole (security) is prioritizing themselves and their needs in a way that makes the overall organism much less capable and effective.

Cancer.

Metaphor: a figure of speech in which a word or phrase is applied to an object or action to which it is not literally applicable.

Cancer: a practice or phenomenon perceived to be evil or destructive and hard to contain or eradicate.

My usage is literal. Organizations that act this way have cancer. They suffer from it, they can be treated, they can die.

It's as real as it gets. I am using cancer in the body as an analogy for this form of cancer - but I am not using a metaphor.

Like, if I put myself in the shoes of the people each of you are replying to, I can see how to reply to horsawlarway: if I disagree with their interpretation of what I said, I can argue back; if I realize that I said something poorly and didn't mean it, I can apologize and correct it; if I disagree with their analysis, I can push back with my own arguments...

...but your comment? You are just pointing at someone and calling them rude. You are then not only refusing to engage with their comment or their points, you are just telling them they shouldn't even be discussed or listened to because they used a word which, to be quite frank, is not insulting; and, in doing so, you have dragged this discussion from one between people who were passionate about an interesting topic that affects everyone on this website--one where I was excited to read both sides--to a bunch of people--sadly, now including me!--squabbling about how words are chosen and how arguments are formed while pointing fingers at each other about who is being insulting, which is a waste of everyone's time so bad I frankly feel bad about how I now feel like I also have to take part.

(BTW, I actually did at first choose to not send this comment: I wrote it, and then decided it was just further feeding you and further wasting other peoples' time, so I put it in a text file and moved on; but, then I noticed one of horsawlarway's responses had been flagged--even though you are clearly the instigator here--so I would need to post a defense of why I vouched for it: you are the person who not only took this thread in a personal direction, but you are the person who decided to start throwing around playground-style bullying: saying an idea is cancer is an opinion and analysis, not an insult... but all of your comments on this thread are patronizing and are the kind of taunting people use to start fist fights.)

Everytime I get into this kind of discussion, the answer seems to be "because it makes me feel better". Which is why it's so impossible to actually change someones mind about it and thus we have security "experts" (or worse, non-technical managers) making life miserable for thousands of users.

It really doesn't help that "security expert" is a job title. That means this person is expected to deal with security, not business objectives, and will be blamed for security incidents, not business goals satisfied. If the OP's attitude is cancer, this is what causes it, and it's completely toxic.

My team (20+ SREs/admins) spends roughly 40% of our time complying with either security requests, external audits, internal audits, internal queries from Risk/Security about servers etc. Figure the cost to our business of this (just from our team alone) is roughly $1M per annum. Add in the cost of all the "security" software, add another $2M per annum. Staffing of Risk/Security team is probably another $2M per annum. For all the other workers in IT (250 or so) probably another $3M. For non-IT workers, the added friction is easily 10% of their cost, so $15M. Add it up and you're around $25M.

And it's not even the out of pocket costs, but the opportunity cost. Thank god I work in a business that has regulative moats that prevent real competition.

Cancer is a perfect term for this IT culture.

Big companies are like governments, and when you remove outside market pressure, they become even more so.

Check these boxes to be compliant to make that enterprise sale.

Is it actually more secure? Who cares, insurance will cover us now and the enterprise paid us.

Need a citation on that “usually” part. A short session duration most definitely:

* Makes it less likely that when an attacker obtains a session token that is is unexpired.

* Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure.

The trade-offs, of course, are:

* Poorer UX, and potentially driving users to attempt to bypass approved tools and/or security controls

* More interactions with the authentication system, which, depending on the auth system and the attackers motivation/capabilities might actually let them harvest more credentials.

But, in any case, I’m not aware of any research that short session tokens don’t thwart attackers use of those tokens, and the idea is, to put it mildy, counterintuitive.

The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.

NO! that's merely the FIRST step in evaluating security. The next steps are: What sort of threat am I attempting to prevent? How do my mitigations impact usefulness of the product on the whole? And most critically: Are my users better served by adding this security measure?

That is much more likely to be determined based on what the product/tool is trying to achieve. Which brings us right back to: Security is a tradeoff.

There are situations where I think short sessions make sense (ex: changing billing/contact info). There are also situations where short sessions are huge negatives (ex: how well is slack going to work if you get logged out every 15 minutes?)

My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!"

Agree 100% on this.

Short sessions are thinking like physical security. Someone can pick any lock, the question is will it take long enough for a human to interrupt the attack?

It doesn’t matter how long a computer has access to the key. How fast it can cause damage is limited by the speed of light, not human fingers.

If you ever leave the credentials where they are accessible, they can be used even if the session expires in three seconds. And if they’re being seen (in motion) why would the session be expiring in three seconds?

Machines hack differently than humans. Don’t think in human timeframes or orders of magnitude. That will let you make mistakes you can’t afford to make.

An awful lot of hacking is done manually, by humans. For many scenarios, considering human timeframes is completely reasonable.

I’ve had to replace a credit card twice for suspicious activity (once cost me my favorite domain name, which is still parked). There were no major charges in either case. One charge at a business I’ve never been to.

Some people get a card and use it. Some immediately sell it after proving it works. That means a clearing house. A food chain. That will get more automated, not less.

But gives them more opportunities to acquire such token.

> * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure.

Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue to do so. An active session token can be thought as having arbitrary long lifespan.

Maybe, if the session tokens are being acquired by improper logging. If the tokens are acquired via the user’s cookie store, for instance, the total number of session tokens is going to be the same — the user is going to use the applications they use, and the stored session tokens will reflect that.

> Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue to do so. An active session token can be thought as having arbitrary long lifespan.

If the session timeout is based on inactivity, not total life time.

There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token.

> There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token.

If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.

Depends on the dwell time the attacker has until detection and eviction, but generally speaking, in the scenario where session tokens are being harvested from a user’s workstation or something like a jump server, the attacker is going to be able to access stored session tokens from the most recent login prior to their gaining access and any that occur during access. In any case, shorter session tokens are going to result in less access for the attacker. There isn’t a scenario that results in more access, and only absurdly contrived scenarios that result in the same access.

> If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.

That may be true of ticket-granting-ticket schemes, but not for single/multifactor authentication for ticket schemes. Both scenarios exist and need to be accounted for appropriately.

I’d argue for truly critical infrastructure, short-ish session times can be useful, but for most applications they do more harm than good and better alternatives exist. For instance:

* Enforcing step-up authentication for access to sensitive application functions.

* Forcing re-auth based on behavioral analytics (for instance, if the user normally accesses an app 8 - 5 Monday - Friday from the United States, but presents a session token on Saturday afternoon from Russia, maybe force a reauth.)

* For enterprise apps, SSO where you may be forcing an authentication event every shift, but at least it is one, not one per app.

But, of course, there is no one right answer because there is no universally applicable or agreed upon threat model.

1. Actual encryption key rotation. This is one grandparent of modern session limits, built with an assumption that keys might be compromised by cryptanalysis rather than stolen by malware-infected clients etc. Rotation reduces the number of ciphertext examples made available to perform the cryptanalysis, thereby reducing the risk of successful attacks. It also may reduce the scope of compromised data if and You may have a UX requirement for preventing idle sessions to stay open on clients because people are in a shared space with client devices, i.e. HIPAA touches on this for medical systems. only if key exchange is still considered secure, such that holding one key does not let you decode traffic captures to determine earlier/later keys in a transitive attack.

2. Forcing idle logouts with less dependence on client systems. This is another grandparent of modern limits which is sometimes cargo-culted. The underlying risk is people logging in and then abandoning a terminal in a shared space, so you want to reduce the chance that someone else can walk up and start using it. You really want the client system to participate in this, i.e. not just end a session but lock/clear the screen so previous data is not on display for unauthorized observers. But it is often seen as defense in depth to also abort the remote session credentials so that future actions are unauthorized even if the client software has failed to do its part, such as if it has crashed/hanged. This one has the weakness you mention that a malicious client could do endless refresh to prevent the detection of an idle UX by the server.

3. Forcing reauthentication periodically or for high-value actions. This is more paranoid than the prior idle logout concept, and actually demands the user reestablish their authenticity during an active session. This has been used historically as another kind of defense in depth attempt to verify user presence with less trust of the client system. But it is also used as a UX ritual to try to get the user to pay attention as well as build an audit chain for their consent to a specific action. Designers might tie this in with MFA/hardware tokens, to get different kinds of user-presence detection throughout a session.

4. Decentralized "web-scale" architecture and caching. In a traditional system, a session key is little more than an identifier and might be checked on each use, i.e. each web request, to determine actual client identity and privileges with a server-side lookup. But as people developed more distributed services, they have often shifted to embedding more of this info into the session "key" itself, as a larger signed blob. Different service components can decode and operate on this blob without having to do synchronous lookups in a centralized session database. This is where automatic refresh still serves a purpose, because it is during each refresh handshake that the centralized check can occur and potentially reject the refresh request or issue modified privileges. This rotation rate defines a system-wide guarantee for how long it takes certain changes to take effect, e.g. disabling a user account or changing the roles/privileges assigned to a user. I have seen this approach even in systems where the session key is a mere ID and cache invalidation could arguably be handled in the backend without forcing client's session keys to rotate. This seems like cargo culting, but is useful if the system operator wants to retain the option to use signed blobs in the future, and so does not want to allow client programmers to assume that client session keys are stable for indefinite time periods.

I'm a bank robber, I want to steal your money without you knowing so I'm not caught.

What would be a better way to do that? Withdraw $1000 immediately or to spread out that withdrawal over several months.

A short token forces the $1000 withdraw immediately. And one common way these tokens are compromised is a scammer getting Grandma to open the developer console so they can "fix" things.

> The vast majority of ways to compromise a session already give you access far beyond that session itself (ex: you have user access on a local machine, or physical hardware access, or you're an admin who manages that user, etc/etc/etc). So an expired session is, at most, a small speed bump in those cases.

Or you are employing the common scam above, screen sharing under the guise of helping.

Granted, some of the calculus needs to be "what type of app is this? What does compromise mean?".

> The most secure application runs completely isolated, with no input or output, and is totally, utterly useless. But no worries - it's secure!

I didn't take this as what the op was saying.

Security works in layers and good security imagines that other layers don't exist or might have been compromised. In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats.

You wouldn't eject the lifeboats because "we have two hulls, what could go wrong!"

The actual cost of doing this is generally developer time.

There are certainly practicality limits, but in general a layered approach to security is how you both increase security and decrease compromise impact.

> A short token forces the $1000 withdraw immediately.

No, a short token forces the attacker to continue making requests, but otherwise places very few limits on what they can do with it (since these tokens are almost always something like "15 minutes since the last use")

> In your ship analogy, that's adding a second hull, putting airtight sections between hull locations, and having lifeboats.

This is PERFECT! Because it hightlights exactly the trade off I'm trying to point out. Fucking no one uses double hulls except for oil tankers, and they only do it for a very specific reason: They want to stop oil from leaking out.

They pay a HUGE cost for it, but it happens to be worth it for this very specific trade. Here's the tradeoff:

---

Double-hulled tankers have a more complex design and structure than their single-hulled counterparts, which means that they require more maintenance and care in operating, which if not subject to responsible monitoring and policing, may cause problems.[2] Double hulls often result in the weight of the hull increasing by at least 20%,[3] and because the steel weight of doubled-hulled tanks should not be greater than that of single-hulled ships, the individual hull walls are typically thinner and theoretically less resistant to wear. Double hulls by no means eliminate the possibility of the hulls breaking apart. Due to the air space between the hulls, there is also a potential problem with volatile gases seeping out through worn areas of the internal hull, increasing the risk of an explosion.[8]

---

> The actual cost of doing this is generally developer time.

No - the actual costs are usually actual costs, paid by all members of the system. Developer time is just the most obvious up front cost. There is a cost every time a user has to re-authenticate. There is a cost in resources to handle the extra authentications. There is a cost in complexity to maintain and extend the system doing authentication.

I think this is definitely where the security trends in modern IT have gone very awry, as it _is_ extremely annoying to be an end user having to work with modern IT security practices. Off the top of my head:

- MFA everywhere means that if you have any issues with your alternative authentication devices, you are completely locked out of your work and probably your life until you get that resolved

- broad and vague block geo-based block lists means users just flat out cannot access resources depending on where they happen to be, which means service desk tickets, investigations, and ultimately people who cannot access non-sensitive data they should be able to just because of where they are physically located

- CAPTCHAs can lock entire classes of persons out of specific services as the CAPTCHAs aren't easy for these classes to perform on demand

- SSO/SAML authentication pages take you on a whirlwind tour of dozens of randomly generated authentication pages meant to establish and pass your authentication back to a central location, and it makes it impossible to tell from the URLs themselves whether or not it's suspicious or not unless you know the specifics of the system in use; this is particularly bad because this is exactly what it will look like if you click on a spam site in a search result or a compromised webpage. how is a user supposed to know when they've accidentally gotten tricked into a compromised authentication page? the uniquity of SSO for logins is nice, but it also means that as a user, I expect that I can be taken to an SSO from just about anything, so how am I supposed to know if the entry point from page X is legit compared to the entry point from page Y?

- a corollary to requiring multiple authentications even from the same device (looking at you Microsoft...) is it creates uncertainty as to when I should expect to have to sign in; if opening a link to a report requires me to authenticate or just accessing an internal web portal requires additional auth, why should I be suspicious when my colleague's account gets compromised and an attacker sends me a link saying "hey, we need to respond on this form by EOD; don't have time to explain in full, but it's pretty straight-forward. I'll follow up in a few hours when I'm done with another item"

- Edited: another corollary with SSO means that getting auth'd once means you get auth'd a lot. While you should need to configure additional security and checks on more sensitive services, since you're already auth'd through the main means of identification, it's often trivial to get the access by normal means or to social engineer access

It really sucks to be an end user in such environments, and it's just too easy for IT security to absolutely lock out legitimate users who are following the policies as best they can with earnest intent.

Yup. I'd add to your list: multiple corporate auth systems/domains that are supposed to be in sync, but sometimes aren't. When that breaks, you end up having to turn the Internet off to even log in to your work computer, and find yourself flying out to another country so the IT people there can fix the mess, and this is cheaper than them spending a long time trying to help you remotely, while you can't do any work.

Don't ask me how I know this.

You have printed the rescue codes when prompted, and have put that physical piece of paper into your wallet, haven't you?

Besides, my last Gmail account for work appeared to be locked to my phone and didn't accept backup codes, and was OAuth master to a number of other accounts.

(For real: I lost access to that Google account permanently when my phone screen stopped working due to an internal fault. It wasn't really a problem and I didn't pursue it fully because I left the job soon after anyway, but the fact I couldn't regain access during that time despite copying the broken phone's content to a new device which successfully transferred the 2FA codes for all other accounts, was striking. It's why I don't use Google for id when there's another option. I tend to use GitHub for id at the moment.)

I think normal users don't have a printer or a nearby print shop in 2023. (For those with an inkjet printer, the ink has dried and the head seized up since they printed something last year.)

Many people, who I assume to be normal, don't have a wallet separate from their phone these days. They use virtual payment cards on their phone and store paper notes and if necessary cash and a payment card inside their phone case. Not useful for "lost my phone" recovery codes, terrible for "my phone was stolen" as it reveals too much, but maybe good for "my phone broke".

I keep my backup codes in a GPG encoded document with copies of it in multiple places. It's a big pain in the ass but I know I'm covered. For the vast vast majority of people this is more theatrical bullshit they won't bother with.

Remember where you put it: the answer is trivial and always the same, "your wallet". The tech support will remind you to look in your wallet if you come to them with your problem.

Let me just bind this fucking book over here, after I ran out of printer ink twice while printing it, and shove that right on into my little wallet flap.

Perfect! Why didn't I think of this sooner!

- click print - you lost 50%+ of your users there, as approximately nobody has a printer on stand-by at home; if they have it at all, it's a hassle to turn it on, and half the time it's probably broken (ink dried out, etc.)

- put it in your wallet - where? Also, what if you lose your wallet? At least with everything else in it, there's a reasonable process of recovery, usually involving visiting banks and government institutions in person. No such thing for webshit MFA.

This is worth repeating: literally nothing else in your life works like this. There are no other documents that you need to hold on to for a decade or more[0], that are in any way important, and loss of which can't be recovered from. It's an impossible ask for most people, because nobody has habits or even required perspective for such use case.

(What I usually hear from people is, "you should put it your safe". But I don't have one, and I've never (that I know of) met a single person who owned a safe either. It's some American thing, I believe.)

--

[0] - My Google account rescue codes are over a decade old now. I had to use them last year. It's a miracle I still had that piece of paper in my wallet - I've long forgotten about it, but it happened to be put next to a single-page reference for time travelers, so it got transferred to new wallets along with said reference.

It was sarcastic, right? Right?

I have never seen an authentication page be randomly generated.

Elaborate?

Probably you start at a page like:

sso.company.com

When you try to access a service, you're taken to probably something like

sso.company.com/auth

If your company uses Microsoft or Gmail, very likely before you reach your SSO login, it may temporarily flash MS/Google's auth page briefly before redirecting or loading the elements for your company's SSO portal

After login, probably it will then load something like:

saml_provider.company.com/autheticate/redirect

saml_provider.company.com/[some generated string in the url]/some_action_page

and depending on how it's configured, you might go through a few of those types of URLs with no direct connection to your company or the resource you want, but it's just the authentication process passing your authentication from service to service until finally it figures out to return you to your originally requested resource and it passes an auth token. †

The reason I think this is frustrating is that it's very fast, no user input, but it is observable by the user; you will see the pages loading and the long urls, sometimes some basic info is printed to the page with simple HTML, but the user has no idea what's going on.

Combine this with the fact that this is exactly what happens when you accidentally click on a spam site from search results, and my problem is "how can a user possibly know if this redirect spiral is a legitimate authentication process or if they've accidentally clicked on something compromised?"

† sometimes these auth-spirals don't even take you to the correct item you were trying to get to in the first place, it takes you to a generic landing page...Reddit is guilty of this from my experience where logging in to subreddits that are flagged NSFW will redirect me to the reddit front page instead of back to the subreddit I initiated the log in to check

and we've done such a good job of training users to detect suspicious behavior, and here we are using the same suspicious behavior that spam sites use, it leaves me with a frustrated feeling.

No? They’re almost always “15 minutes since the last use, or 5 hours since it was created”, which results in a completely different security picture.

Sit in a coffee shop and steal credentials for a local bank all day.

One of my favorite sayings is “if you are not careful, you are going to secure yourself right out of business”. Ease of use is a real thing, and if you don’t figure out a way to make a secure app that is also very easy to use, someone else will and your pleas of “but it is not secure” are going to fall on deaf ears.

Honestly, baseline security is part of “essential complexity” https://ferd.ca/complexity-has-to-live-somewhere.html. Essential complexity can’t be removed, but it CAN be moved around. Right now we are talking about the essential complexity of managing security through managing a user’s session length. The advocated solution is to make sessions short so that they expire quickly. This seems to remove all “accidental complexity” so that we are only dealing with the essential complexity. But this is misleading. There is still complexity in juggling those short sessions. As a designer you think this solution is simple, but what you have done is moved that essential complexity over to your users. THEY must now manage the impact of short sessions. The complexity does not go away, you just moved it to your users, hence it is user hostile.

The trick then, if making the best product is important to you, is to figure out a way of letting users have long sessions but managing it on your side. This seems to argue that you are making your system more complex by adding accidental complexity (which is generally a bad thing). But really what you are doing is moving some essential complexity away from your users onto you. You lower their burden. This is how you make competitive applications.

This seems like it could be a really valuable and maybe also fun role, if one can find an org that has made room for it.

Nonsense, defence in depth is a core security principle. You should not rely on a single control to protect you.

And you should not prioritize security over the goal of the product.

The conversation is a discussion of relative value and tradeoffs. Does increasing security make the tool as a whole worse? Sometimes - the answer is yes.

I have a nice set of front windows, but that means a risk of someone breaking through them. I accept that risk for the windows - the extra light and visibility is well worth it, and the windows are not the only way in. Compare to short sessions.

E.g. my bank makes me type my password and sends 2fa codes when initiating/approving wire transfers… even when I just logged in a minute ago. If I’m doing 2 wire transfers in a row, it doesn’t care, it still has me fully reauthenticate for every wire transfer.

But I’m fine with that because moving money is something that I’m willing to accept however many roadblocks are thrown at me.

But do I want that happening when I go to post a tweet? Absolutely not.

In other words, let’s adopt the concept of refreshing authentication upon particularly sensitive user actions and have lax requirements in other cases.

We don’t need to think of sessions as “logged in” or “logged out”. It’s possible to design a system where you’re always logged in forever, but you need to reauthenticate based on certain rules or actions given the context of the app and risk/threat.

The "session" that can do things like change 2fa/billing/contact-info (decidedly not-normal things) should last for exactly as long as it takes you to complete that form, and should require your pass/2fa again to touch.

This is currently Google's approach, and I find it much more sane.

* logs out after 10 minutes of inactivity - so doing anything that involved switching between accounting app and it is annoying * not allowing more than one tab open at once - that's just stupid in its entirety.

Really? I'd change banks over that. If I log into my e-banking website, the main activity I'm going to do is pay bills. I would absolutely not tolerate having to jump through hoops to do it.

In the spirit of adaptive security, someone moving $100k will probably be fine dealing with a couple extra password / 2fa prompts... but I agree it would be annoying to deal with this for day-to-day (consumer) bill pay. A bank could throw fewer roadblocks when paying a $500 invoice vs. a $50,000 invoice

The workflow I described also is part of a dual-approval model where a finance person sets up the transfer and it's approved by a 2nd person (who's presented with a bunch of authentication/password/2fa prompts, almost to a fault).

But again, I'm fine with it because it's large amounts of money in corporate bank accounts. But yea, agreed it would be annoying and should be toned down in a consumer use case.

Okay. I will compare using house to short sessions.

Short sessions is like having house with every doors having a lock and I need to use the keys to get into different room, if I stay in one room for too long, including the shitter. I also need to use the keys to open windows and the oven. And developer going "well, you shat yourself ? That's your fault, should've had keys on you at all times".

That's what short sessions are. Delusional security clowns ignoring usability. It's less than security theatre, it's security circus.

Requiring re-auth to pay some money or delete something important is reasonable stance.

Requiring re-auth few times a day just to browse data in the app is not,

Security is just another non functional requirement (mostly) of a product.

To obtain good enough security, defence in depth is still a good principle to follow. It means you are not putting all your eggs in one basket. It often means that each individual control does not have to be perfect or massively over engineered.

I would argue that you are arguing to prioritize security over the goal of the product. Right here and right now - you are literally doing it.

> To obtain good enough security, defence in depth is still a good principle to follow.

I don't disagree! I just think that each "defense" needs to actually be considered on the whole, not as just another bonus to security. Short sessions SUUUUUUUUUCK. They make your product shitty. Users hate them. They don't add a ton of security.

Are there products that should still have them? Sure. Probably lots of products in VERY specific places. Should they be the default everywhere? Sure as hell not.

Optimize the application to run the best for all the users first and then adjust the security implementation as necessary. Otherwise, you could DoS yourself by trying to be too secure.

I think it depends what kind of buisness you are running and what a security breach means for you or your users. If it is a hobby forum, well yes, UX matters more. But if you screwed up security for anything with big money related - you probably want to prioritize security first and not after you lost some billions.

And then, since the top comment was encouraging a wider view, there's even wider view: business needs. Truth is, short sessions make me viscerally hate the product, creates a desire to avoid using it, and becomes a factor in decision to switch to a competing offering when such possibility arises. Or to not switch - one big reason I'm still using my current bank account instead of another one I had to have to get better mortgage rate, is because the bank operating that other account has short session times and associated pseudo-security annoyances.

In some sense, the problem is that the goal is zero controls breaking, but of course, that also provides no information on security. Intuitively, it would seem that parameterizing security (in a diagnostically useful way) would also require a number of quite different measures. For instance, it matters who (how sophisticated and motivated) your attackers are. And some of the parameterization would be based on use - every time you force someone to type a fixed password, that password is more exposed. Combining all these quantities would just be Bayes-based.

I think an exercise like this could be instructive. For instance, short sessions mean more authentications and both usability and failure modes. But they also mean that an attacker would need to wait until the next session, or have a smaller chance of hitting a session. Again, these are quantifiable, at least in rough terms. And this kind of analysis does expose some additional questions: eg that short sessions make no sense without guaranteeing the security of the client system (ideally by reinstallation from known-good reference).

At least in my experience, "security people"

But the way risk is managed in the industry (multiplying likelihood and impact) is completely incoherent and voodoo. See the book "How to Measure Anything in Cybersecurity Risk" [1] for a good explanation of why it doesn't work and better ways to do it.

Which is a long way of saying, no, security doesn't use quantitative techniques mostly, but it would be possible if people understood how to measure and manage risk properly.

[1] https://onlinelibrary.wiley.com/doi/book/10.1002/97811198923...

I think in some (very narrow) cases, short session times and aggressive reauth do add depth and can be an effective part of a security program.

But, all too often, defense in depth is used to mean:

* Vendors In Depth, whereby every security tool under the sun has to be deployed (or at least purchased) to achieve “security”. Or, worse, the Noah’s Ark model where you buy two of everything.

* Uncoordinated and/or seemingly random layering of controls that either don’t add to the overall confidentiality, integrity, or availability of the system being protected. Or, worse, are positively counterproductive and actively reduce the real-world security of the system.

Vendors will always love the phrase 'defense-in-depth' more than they care about assessing whether additional layers of tooling and controls actually provide more defense, because a vague appeal to defense-in-depth is a great way to justify purchasing more security software.

It would be naive to think this doesn't affect the volume of research produced promoting and emphasizing the importance of defense-in-depth either, or how frequently papers on basically any kind of attack end with something that means 'this is why a defense-in-depth approach is needed in XYZ area' even when defense-in-depth is at best incidental to the substance of the paper.

You can trivially tack that on to the end of pretty much any paper about any exploit, which raises the question of how meaningful an observation it really is.

Why "usually does not"? The stolen hard drive, leaked data, etc. can happen at any point in the future....one minute to one year from now.

For most of those times, a short session will prevent the attacker from exploiting it.

> The vast majority of ways to compromise a session already give you access far beyond that session itself

For the local system, yes. But not the for the remote system.

This is fair, although you've picked a specific case where the local system would not likely access the remote system again after compromise (because theft removes access for the normal user) and an expired session might be helpful as security.

But the other thing about theft is that it also immediately alerts the user, and having a simple "Sign me out everywhere" button is a more robust solution that causes much less user pain and mostly accomplishes the same result.

As for

> one minute to one year from now.

I'm not arguing for indefinite sessions. I'm arguing against short sessions. Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes). It'll catch 99% of the cases you're thinking about solving, and it's literally 3000 times less annoying for your users while being nearly as secure.

The user may or may not know of theft or leak.

And even if they are aware, they may not know remember every remote system they were logged into.

> Rotate it after 30 days if you want (or 5 days, or 1 day - just don't do it every 15 minutes).

So we've gone from arguing that short sessions doesn't work, to arguing that it works for such a large % of the cases that it could be relaxed.

Arguing that short sessions are bad is not the same as arguing that rotation never has its place. Rotation can provide some benefits.

My argument is that EXCESSIVE rotation (aka: short sessions, the whole freaking conversation) is folly.

It's a bad decision usually implemented without thought or understanding (it's on the checklist...), which has a high cost to users, and actively degrades the product.

In return for the costs of short sessions, what are you proposing that your users gain?

Because personally, logging in every 15 minutes for the rest of my life is a god damn travesty of an exchange to make to cover me on the one case where my laptop goes missing. Especially since that's not a very common vector for account theft. It's SO much more likely someone just calls the help center and claims to be me and gets in just fine.

Exploits owning software on machine are far more common than machine itself being stolen.

I'd also argue that tying re-login to the sensitive actions is far better way to fight it. Basically have long session for nondestructive actions but short for any potentially harmful ones like changing payment options.

I’ve seen businesses put used laptops straight up on second hand market, without barely doing basic formatting of the drives, unencrypted. Even less so on private market.

Heard from security friends also that there are examples of attacks that succeeded thanks to drives found in trash outside enterprise.

- Attacker steals Google token from regular employee.. What can they do? No, they can't "make themselves admin, or wire all your bitcoin to their account" because such things are not available for regular employees. Nor can they use email to take over account because all stuff that matters uses corporate SSO without automated password resets. So all they have access to corporate google drive, which has few terabytes of not so-valuable-stuff + important documents somewhere.

With long-living token, the attacker has plenty of time to browse around and download valuable stuff, perhaps even do it slowly so it can fly under radar. But with the shorter token, this does not work: downloading everything will take too much time / trip the alarms, and manual browsing is not fast enough. (I can imagine some sort of sophisticated AI system which auto-downloads interesting docs, but I am sure most attackers have nothing like this)

- Attacker steals AWS credentials -- again, they either have to be fast and get detected (there are alarms on unusual high download rate) or go slow and worry about token expiration. Even if they manage to steal important data, at least the expiration will force them to use faster methods more likely to trip the alarm.

Even with the full machine compromise, the short-lived tokens are useful. A npm package which steals all tokens once, at the install time, will likely go undetected. A npm package which installs a persistent backdoor will be much easier to detect.. So having a long-lived token makes attackers' lives much easier.

The worst hack at a company I worked for was caused because an old server that was supposed to be decommissioned was left plugged in and connected to the network… a good time later, a hacker exploited a vulnerability in an unpatched package on the machine and got in (since the server was supposed to be decommissioned it was not patched when the rest of the machines were patched).

The hacker used old credentials on the machine to gain access to other machines in our network. If we had been rotating credentials more often, this would not have happened.

We had systems in place to patch and maintain our machines, but once the machine got lost in our inventory management system, it was forgotten about. It wasn’t monitored anymore, and other protections lapsed.

This category of exploit is prevented by credential rotation, because this type of exploit is only possible if a system is neglected.