Hacker News Reader

Comment by Eduard | Hacker News Reader

that's more secure, but still not bulletproof:

A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation.

Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key revocation), a MITM with a shorter trip time to SE's servers could race for wrecking havoc until the revocation happens.

Nevertheless, SE's revocation tactic contributes positively to a defense in depth strategy.

View on HN

Nothing could possibly be bulletproof. You sent a key over the wire unencrypted. You were in trouble before the data even got to the server to do anything about it.

This approach is a practical choice based on the reality that the bulk of unencrypted traffic is not being actively mitmed and is at most being passively collected. Outside of actually developing cryptosystems, security tends to be a practical affair where we are happy building systems that improve security posture even if they don't fix everything.

as an old-school reader of the cypherpunks email list from before HTTPS existed, I'm still mad about this part:

Outside of actually developing cryptosystems, security tends to be a practical affair where we are happy building systems that improve security posture even if they don't fix everything.

there was a time in the 1990s when cryptography geeks were blind to this reality and thought we'd build a very different internet. it sure didn't happen, but it would have been better.

we had (and still have today) all the technology required to build genuinely secure systems. we all knew passwords were a shitty alternative. but the people with power were the corrupt, useless "series of tubes!" political class and the VCs, who obviously are always going to favor onboarding and growth over technical validity. it's basically an entire online economy founded on security theater at this point.

> we had (and still have today) all the technology required to build genuinely secure systems.

True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been.

Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willing to work with for a particular use case. There's a reason that most people don't secure their houses by removing all windows and installing vault doors.

I’d disagree that there has to be a trade off at all. Using hardware security keys or device based passkeys, secure authentication is actually pretty convenient now.

yeah, the assertion is entirely false. there doesn't need to be any such tradeoff.

there's probably a term for the cognitive fallacy where you assert that however it happens to be is how it had to be. it's like normalcy bias, but retroactive.

> there doesn't need to be any such tradeoff.

Maybe you're right. I've certainly heard others make this claim. I just personally haven't seen a real-world example of this being true.

I disagree that hardware security keys or passkeys are more convenient. I ditched them because they greatly complicated authentication for me.

Interesting; I have had the opposite experience. Many websites will directly enroll my Yubikey and will even let me use it instead of a password, and logging in is as simple as touching the button at the prompt. It’s honestly much simpler then using a password for me, and MUCH more convenient then pulling out my phone for 2fa codes (especially for the university site’s painfully short session times)

I'd argue your reasoning is incorrect. By the time your service is developed you would have already changed it to https, as during development every time you tried your API keys sent via http got disabled. So an in-the-wild MITM would never get to see your http request

That's a very good point, I agree. You're always going to run a service at least once.

I agree from a developer point of view, but the people configuring and deploying the application aren't always the same people developing it.

As a developer I like to make many options available for debugging in various situations, including disabling TLS. This isn't controversial, every Go and Rust library I've ever seen defaults to no TLS, preferring to make it easy rather than required, so reflecting those defaults in the service's configuration is natural and intuitive.

I make sure my example configurations are as close to what will be needed in production as possible, including not just TLS but at least one "mutual TLS" validation. I even sync these back from production if it turns out something had to be changed, so the examples in the repository and built artifact are in line with production.

Yet I routinely find at least some of these disabled in at least some production deployments, presumably because the operator saw a shortcut and took it.

Let's rework Murphy's original law: if there are multiple ways to deploy something and one of those will be a security disaster, someone will do it that way.

Won't those people have the same experience? The app won't work until they configure it securely

It appears the trick they've found is to disable TLS on both ends :)

There is a non-zero number of developers out there who would sooner deploy a proxy that upgrades http to https because the thought of changing the application code wouldn’t spring to mind

The MITM can be between the developer's machine and Stack Overflow, e.g: the classic Evil Cafe Wifi.

There's absolutely nothing you can do to prevent an active MITM attack over HTTP

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

What's stopping the MITM just copying that header?

There's complicated authentication schemes around hmac that tries to do this, but if you're putting that much effort into it you might as well give up and use https.

Some of these include a nonce and/or are deployed over TLS to prevent replay attacks and avoid sending bearer tokens over the wire. AWS sig v4 and RFC7616 come to mind.

Even if the copy the header, they can only perform a replay attack, which is an improvement over leaking an API key. Also, you could include a timestamp in the signature to limit the amount of time it could be replayed.

Sign a nonce.

It’s preventing the theft of the API key. The attack can, at most, replay that specific request (which you could also mitigate with a nonce and expiration).

I think the CONNECT proxy protocol carrying TLS over HTTP/1 is a counterexample.

ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CO...

  > that's more secure, but still not bulletproof

I've never heard of bulletproof ever actually being achieved in IT security. Not even air gaps.

You tend to only hear about the systems where security was successfully broken, not the systems nobody managed to penetrate.

The thing about bullet proof is that nothing is bulletproof when you have a big or fast enough bullet

Yes, but what is meant, that it provides protection against common calibers. So you can have bullet proof security in IT. That does not mean it is blast proof, or acid resistant, or prevents someone using a backup key on the second entrance. It is just a metapher saying this security is very solid. Might be true, or not, but that nothing is 100% secure is quite known.

Reply on news.ycombinator.com