I'm currently implementing a small webserver on an embedded platform which is quite resource-constrained. I am planning to use unsecured communication because TLS might not be possible in my embedded environment, but nevertheless I do not want to have username / password pairs transmitted in cleartext.

I have looked at Basic Authentication which is not the best solution in terms of security as we do transmit all information, including username and password in cleartext.

Compared to Basic Authentication, Digest Authentication seems more secure but the big problem here is that the HA1 sum stored in the database must be treated as real passwords (because that's actually what they are). As soon as you get a peek at a user's HA1 sum you can get access to all areas the user can get access to as you'd be able to calculate a valid HA1 sum for every nonce the server sends.

Is there any other established authentication method that can be used in the context of HTTP while avoiding the vulnerabilities described above? Note that I only need secure authentication and not secure communication. If there isn't I might really need to reconsider using TLS in which case basic authentication would be enough.

  • 1
    If you can guarantee the integrity of both client and server software, you could take a look at SRP, but I doubt you can get secure communications going without spending the necessary resources to enable encryption, whatever the setup.
    – Jacco
    Jul 4, 2017 at 8:13
  • 1
    you can use another server w/https to login, then talk to your site from that server, which at least eliminates "coffee shop" password vectors, even if behind the scenes where few have access it's in the clear.
    – dandavis
    Jul 4, 2017 at 8:50

1 Answer 1


A common use case for old systems with few resources was to use a login form that was the only page served as HTTPS. It is not as secure as a fully HTTPS service, but at least the password is only transmitted in encrypted format and only a hash is stored on server. And as only the login page is served in HTTPS the overload on the server is still low.

But this still forces to setup a SSL configuration on the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .