241–250 of 310 posts
The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
Careful, someone might use that as an API! https://xkcd.com/1172/
Revoking an API key upon a single http request assumes you have a competent team. Have worked with people that have committed sensitive credentials into public repositories, used PRODUCTION secrets for testing, and of course sharing secrets in plain text over IM and group chats. The number of times I have had to deal with password or secret key resets because of this is way too high. I remember working with a guy tha…
It assumes nothing like that. It provides you and your team with a safe opportunity to learn and grow. Revoking a key like this is a problem that's solution is at worst a dozen clicks away fix. The alternative, leaking keys can be much worse. So go and reset those creds for the guy who made a mistake happily and be grateful. He had an opportunity to learn.
That second person is way to common in companies that hire from the bottom of the barrel.
Earlier quoted context omitted.
MITM generally refers to someone who can intercept and modify traffic, i.e. they sit “in the middle”, between you and your recipient, reading/modifying/relaying traffic. “Passive eavesdropper” is often used to describe what you talk about. Someone on an unencrypted WiFi network sniffing your traffic isn’t really “in the middle” at all, after all.
I disagree. So does Wikipedia ("where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties ... for example, an attacker within range of an Wi-Fi access point hosting a network without encryption could insert themselves as a man in the middle") and so I be…
The "eavesdropping" attack happens when you capture unecrypted packets. From there, you could either try to hijack the session by inserting yourself into the local conversation (effectively launching a "MITM" attack) or completely independently of the local conversation attempt to impersonate the login session (effectively launching an "impersonation" attack).
I appreciate the author calling this out because creating an HTTP-redirect-to-HTTPS is something I'll do almost without thinking about it. "If it has HTTPS, I'll set up an HTTP redirect." Now I know that I need to think about it before setting that up. It also made me realize that cURL's default to not redirect automatically is probably intentional and is a good default. Praise be to Daniel Stenberg for this choice w…
I hope that providers whose APIs responded and interacted fully over unencrypted HTTP would go back to their historical access logs and check how widespread using plaintext HTTP is. If they don't have access logs for their API then they could just sample next 24 hours for API accesses. Popular providers have so many API users today that even a rare mistake could expose quite many users in absolute numbers. Would rath…
If you make a breaking API change like this, some portion of clients are just never going to update. If you’re a usage-based billing SaaS provider, that means lost revenue.
Likely the only way this issue is fixed widely is if it ends up on a security audit checklist.
Earlier quoted context omitted.
> 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.
The thing about bullet proof is that nothing is bulletproof when you have a big or fast enough bullet
Earlier quoted context omitted.
Careful, someone might use that as an API! https://xkcd.com/1172/
I mean... it is a lot easier to do, than to program a procedure to revoke an api key.
Earlier quoted context omitted.
I've been thinking for about 5 minutes about this comment and what to write but i've come to the conclusion that this is really not the best thing to do, but the correct thing to do. It's not different levels of good or bad... everything else is wrong.
One of the approaches mentioned in the article is to just not listen on port 80. Supposedly that’s equally good because the connection should get aborted before the client has the chance to actually send any API keys. But is that actually true? With TCP Fast Open, a client can send initial TCP data before actually learning whether the port is open. It needs a cookie previously received from the server to do so, but t…
Returning an error (and/or blocking the port entirely) allows the developer to understand he is using the wrong protocol and fix it.
In this scenario, the end user never actually performs an http request, because the protocol was fixed by the service developer.
Earlier quoted context omitted.
I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Bei…
Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps; 1. Install and run certbot (+the DNS plugin for your DNS provider). 2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config. 3. Set up a gene…
Anyway, all the steps together take what - all of 5 minutes? - that's if you do DNS Challenges. If you do HTTP challenges it doesn't even take that.
So you're saying this 5 minutes isn't worth the effort? That it's somehow too hard?
Earlier quoted context omitted.
So what? My point was the encryption doesn't matter, it's just the reason you have to impersonate in order to merely evesdrop sometimes.
The point is that you don't need to be 'in the middle' to evesdrop unencrypted data - you can sniff traffic without either end being any the wiser, but if the data is TLS encrypted then you can only decrypt it if you interpose yourself.
One of us has not understood the others purpose, because I don't understand the point of your response to my first comment. Nothing is making sense after that.
My initial point was to show that mere evesdropping on an encrypted link is still mitm, and so the full interposition is merely an implimentation detail, required by the encryption.
If mere evesdropping is still mitm, then as far as I'm concerned any other evesdropping is also mitm.
But then I also add that a keylogger is an evesdropper and I wouldn't call that mitm so maybe the argument is missing something.
Maybe the way I should think of it is "Yeah. It's an implimentation detail. An implimentation detail called man in the middle. Evesdropping on an encrypted link requires mitm, but not all evesdropping is mitm the way all beef is meat but not all meat is beef."
IE the fact that you chose not to do anything with the mitm but merely evesdrop isn't really significant the way I argued at first. That particular example of "mere evesdropping" is still called mitm not because "therefor evesdropping is a form of mitm", but because that instance of evesdropping required mitm to do it.
Allll that said, I now actually think all those other examples of evesdropping like even a keylogger should be considered mitm. Because they are all examples of you're not talking to who you thought you were talking to. In the case of a passive observer like a wifi or keylogger or phone tap, you thought you were talking to a certain listener, but in fact you were talking to them plus other listeners.
It's perfectly logically arguable both ways.