Is it possible to make a login safe without a TLS certificate?

Question

I'm using free hosting and I would like to know if there is a way to have a safe login system without a TLS certificate. All I do with this server is: POST HTTP Request with username and hashed password, then search for those values on server, and reply with "x" for yes and "y" for no. It's my first week working with databases and servers, this is why I'm not paying for a hosting service.

If the information is transmitted as hash to the server, and the answer from the server is NEVER the same (I mean, "x" is ALWAYS a different value and "y" is ALWAYS a different value), do I still need a TLS certificate?

The login is made on a desktop application and then is hashed and sent to the server.

There is no credit card info or any sensitive information, only username and password for MY application.

Please don't say "I don't know why you want to do it without TLS certificate because they are free" and such, I already talked with their support and they don't support TLS.

Answer 1

If you control the client and server software completely, you can re-implement enough of TLS for security without bothering with public key infrastructure (PKI) - the certs and such - by hard-coding the trusted public key(s) into your client. This is a terrible idea, though; TLS is really, really hard to get right (witness the constant stream of bugs in libraries like OpenSSL) and contains a lot of stuff learned in decades of trying to perfect transport-level security (SSL 1 was so insecure it was never published, SSL 2 was found to be insecure pretty shortly after publishing, SSL 3 was found to be insecure a few years ago and is deprecated, TLS 1 - essentially SSL 3.1 - has in turn been deprecated by newer versions, etc.).

Trying to do authentication without TLS or something like it is not going to be secure. Technically there exists a protocol, Secure Remote Password, for authenticating securely over an untrusted network, but it doesn't support registration (you need to have some other secure way to tell the server the user's credentials) so it is probably unsuitable for this. There exist ways to be secure against a passive eavesdropper, such as HTTP Digest authentication, but an active man-in-the-middle - which is easier to get than you might think - can still compromise such schemes.

If your hosting provider genuinely won't permit HTTPS (and dear $DEITY what is wrong with them?), find a different one. For hobby projects or small-scale prototypes, there are tons of free providers. While you're at it, have a care for how you store and look up passwords; simple hashing (even with a salt) is insufficient, and beware of issues like SQL injection. Additionally, if the server and client exchange any information other than the login request and response, make sure the other endpoints have adequate security (HTTPS or similar, but also proper authorization checks, no XML attacks, deserialization attacks, etc.; web services are easier to secure than web sites, but there's still a ton that can go wrong).

Answer 2

CBHacking's answer is correct: just use TLS.

That said, hashing the password before sending, as you described, is a good step. This has saved my neck before when someone in school thought they were cool, did a passive intercept, and deleted half of a forum that I was an admin on (I was 17 and the free forum host did not offer HTTPS). The attackers got stuck when they didn't have the admin password to enter the admin panel (a million kudos to SMF Forums for implementing the hashing and extra password check).

Now consider this: you send the password hashed, but an attacker can observe the hash being sent. They do not know the original password, but they can replay the request. They can just send whatever you sent, and the server will accept it.

So another step is to make this a challenge-response system. This is what a lot of protocols use, for example NFC: the card (also known as 'tag') will generate a challenge and the reader has to respond correctly before being allowed to read the tag. This can be a secure authentication system.

You should also use slow hashing, such as Scrypt or Argon2 if possible. See: How to securely hash passwords? This makes it harder for an attacker to attack your password hash.

Next, you should encrypt and sign the traffic: it's great that you can authenticate securely, but an attacker can still modify the commands you are sending and see the data you are transmitting. Something like AES-GCM does both, or if you want to do it with more traditional methods, AES-CTR with HMAC is a common choice. You could use the solution to the challenge-response system as password, and instead of submitting the response, you encrypt the text "correctpassword" (or something like that) and send that to the server. If the server can decrypt it correctly, it knows that you had the right password.

Finally, an attacker can still do a replay attack: you have a good login, you have encrypted requests, you sign the requests... but what if an attacker just replays a random request? The server does not know that it is invalid. Therefore, you should include a sequence number on both sides (from the client to the server and vice versa).

You know what you just did? You just re-implemented a large part of TLS, basically the part after the key exchange. Now think of the history of vulnerabilities that TLS has had, which is huge, despite having experts working on it. It is fun to thinker with this sort of thing, but please do not use it for anything that matters! I'm just answering the question because it's interesting stuff, at least to me, not because I think you should actually use this in production! :)