> Based on the comments I see here, I think the focus is going on the turnstiles just as it did when I worked there.

You titled the piece after the turnstiles and spent the overwhelming majority of the post talking about them (and surrounding physical features). The Jira ticket felt secondary, and when it was introduced in the middle of the post I was genuinely confused, thinking why the heck the card system was contacting Jira.

People reading your writing are going to focus on whatever you did when you wrote it. The turnstiles read like the important part.

The part about Jira is important because it highlights that while the company claims to take security seriously, they in fact do not take it seriously.

The incompetence of the turnstiles makes it a good focus for the story while the juxtaposition of the turnstiles with Jira exposes the company's hypocrisy.

What's the threat model for cookie theft? That if someone gets access to your company hard drive, but not enough access to install a keylogger, then instead of invalidating a session you also have to invalidate the password too?

It's an issue but I wouldn't call it a particularly big issue. I don't think it's very damning for how much the company cares about security.

And it sounds like the turnstiles did work for actual security? Sure, they gave up on per-floor security, but that's a lot less important.

Edit: And if employees are reusing passwords then we should be getting them password managers (or SSO) as the top priority, much more than we worry about logins in cookies inside the building. I mean, there's a point where a single purpose password and a login token become the same thing.

A threat model is you can steal the creds of any high clearance officer in the organization. If they reuse the password on the network, you now have unfettered access.

SSO is much more common these days, but that it wasn't the case back then.

Steal the creds by doing what, though? Most attacks could get their password even if it wasn't in the cookie.

And password managers have been plenty well known for a long time.

How do you get the password if it's not in the cookie? When it's in the cookies, any 3rd party script can swipe it.

A third party script that's embedded into the task management website? Otherwise I don't see how it's going to get to the cookie. And if it is embedded into the website, it can force a fresh login and steal the cookie that way.

And you can set HttpOnly to stop javascript from being able to access the cookie... but that still won't stop the attack of making them log in again.

The threat model I imagined here was:

1. Initial access to physical machine, most likely via phishing malware, reckless employees downloading untrusted content, or bad luck.

2. Malware looks for browser cookies, hoping to steal temporary credentials but instead gains persistent creds, which grant Jira access. People re-use passwords; malware tries this password against AdUser and any other systems or other corp user accounts it can find

3. Direct Jira access used to pivot, that custom Jira app is probed for app vulns (likely given design).

So with a better system the malware has to wait an extra couple hours to get the password (by dropping the non-password authentication cookie and making the user log in again), and it can still prod Jira in the meantime. That doesn't strike me as a very big difference. It's an improvement in security but not a big one.

More likely:

1. Get e-mail from boss, look at headers, find boss IP addy

2. Failing that, memorize boss office number or workstation tag, run stealthy network scan, do reverse dns lookup

3. Be a router, arp spoof mitm attack

4. ?????

5. Profit

I believe like that was the intent, but the (very few) mentions of Jira feel like a bit of a non sequitur; they don't belong.

I care a lot more about my life (or my car's catalytic converter, which was stolen off my car in my work parking lot before they inatalled a gate for the lot) than any of my work-related IT credentials. Health and safety threats are a much bigger deal to people than nebulous, difficult to exploit threats to IP.

Except the turnstiles and swipe cards do almost nothing against an active shooter situation.

But missing in this discussion is a risk and consequence analysis. If the risk is armed attackers, do something that targets that. For physical theft, target that. Likewise IT risks. The core problem is that risks were not being identified (systematically or in response to expert feedback) and prioritised.

Incidentally, the solution to car park access is ALPRs, and the solution to most of the physical security is solid core doors at the workgroup level with EACS swipe and surveillance cameras there, and at the front desk have face level 4k video surveillance. With an on duty guard to resolve issues with access.

> The core problem is that risks were not being identified (systematically or in response to expert feedback) and prioritised.

Or the person who wrote the article just wasn't involved in that loop, or otherwise disagreed on what threat models mattered.

It seems much more a compliance and auditing goal. To meet some objective of knowing who is in the office at what time, which informs office space leasing decisions, return to office mandates, decisions of charging for staff parking, etc. Personnel protection seems almost an afterthought.

Protecting JIRA auth tokens is quite likely low down the list for IT security. Making sure your workers are not remote North Koreans is indeed a security benefit of secured physical offices with regular on-site work.

But the author did have a deeper point -- visible security theatre gets lots of money and management attention, while meaningful expert driven changes are mired in bureaucracy.

I still challenge whether his proposal was actually "meaningful, expert driven changes" - is this actually a serious threat vector? How would you actually exploit it, without having access to dozens of other vectors? Can you even meaningfully resolve that vulnerability when you have people walking in off the streets due to a lack of physical security?

I don't think you could take over the company with a jira token. Another factor for consideration with turnstiles is disability access and fire egress. Those are covered by building code but since this is a parable, it's worth noting that physical security has often caused tragic stampedes that have killed many.

You are right, it's much harder to compromise a system with the jira token, which is why it was the solution for the username/password stored as cookies. Plus the token was never exposed to the client.

You're right, but the consequences of different security failure are different, no?

Perhaps part of the problem is that an active shooter is easy to visualize and understand whereas unsecured credentials stored in cookies are an abstract and difficult to visualize problem for management.

Furthermore, turnstiles are easy to promote and take credit for. Secure web authentication would have to be explained to and understood by the boss's boss before credit for it could be claimed.

I suspect it's these aspects of organizational reality that results in security theater.

I think it has less to do with ease of visualization and more to do with priority of consequences.

Do a poll of whether people would prefer that a mass shooting or a mass data breach occur at their place of work while they are there. I bet I know which one wins.

The majority of commenters don't actually read the article, or at least not the whole thing.

I was disappointed by the lack of photo of the single turnstile.