Hacker News Reader

Comment by latexr | Hacker News Reader

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

View on HN

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.

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.

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

Reply on news.ycombinator.com