Hacker News Reader

Comment by barredo | Hacker News Reader

So if you offer a https only API and anyone makes the mistake of using http instead, what should be the response of your system? A simple error message with 404 code and without special/identifying headers?

View on HN

From the article:

    close port 80 on your API host

The main problem isn't the response, the problem is that on the initial request, the insecure password will be sent in plaintext.

Isn't this sort of issue basically only going to happen during development or such?

But that's not the problem of the API provider. If you explain that you only allow HTTPS and someone makes an HTTP on an unsecured connection, well...

Oh but it IS the problem with the provider. Or rather, it will be when some crazy PR storm hits the interwebz with "$YOURCOMPANYNAME leaked passwords!" when someone comes up with some clever way to hack/manipulate traffic with XSS or something. I was able to fetch private authtokens of a Wii game because port 80 was open on one of nintendo's servers(I assume it's there to test in plain text and just didn't close it later) and I was able to fool the software into using port 80 instead of port 443. That wouldn't have worked if port 80 was closed.

Makes total sense. Thanks

Pretending that your customers won't make mistakes?

Sounds insecure.

The proper response should be to expire the insecurely-sent passwords.

Clever. I like this much more than just closing the port 80.

Reply on news.ycombinator.com