Hacker News Reader

Comment by martin-adams | Hacker News Reader

If we're worried about a man-in-the-middle attack sniffing insecure credential on port 80. If the host closed port 80, couldn't the man in the middle just open it up again, you know, in the middle?

Maybe one recommendation should be supported vendor supplied SDKs which don't touch HTTP, only HTTPS. Another option is to detect credentials being sent over HTTP and notifying the clients, maybe deactivating their key if action isn't taken in a period of time.

View on HN

I think the idea is that if the real port 80 never answers, real customers are highly unlikely to set up their apps in the vulnerable state in the first place. That said, having port 80 open, but returning an appropriate error code to all attempts to use the API, would probably have the same effect (while still answering on port 80, for anyone who just wants to ping it to see "are they up" --- one of the excuses the OP has heard for leaving port 80 open).

No, that's exactly the problem the post is complaining about. It still results in credentials being sent in plaintext in the original request.

Right, but the problem will be caught when the app is still in development. Then the devs will fix the app and by the time it gets to end-users, it won't do that anymore.

Yeah, but then you have to do it in "real time".

The request won't go through and end up in a log somewhere if there's no MITM.

Reply on news.ycombinator.com