CODEWITHSUNDEEP
javascriptesp8266sha256subtlecrypto
Dan Forever
Dan Forever

Reputation: 431

How do you implement digest authentication with SHA-256 when modern web browsers disable SubtleCrypto when you're not in a secure context (https)?

I've got a very basic web server running on an ESP8266 microcontroller, so system resources are very limited, but I figure it can probably deal with SHA-256 (I'll guess we'll see, but that's a separate issue).

I've got the barebones digest authentication implementation working well enough that I can access the site via curl.

This microcontroller is not meant to be exposed to the internet, it's only something you'd access internally via your lan, so SSL isn't an option (not sure how well the microcontroller would hold up if it tried to support HTTPS).

So, here's my scenario: User tries to access the site on the microcontroller from their favourite web browser. They are given a 401 code and redirected to a login page (along with the WWW-Authenticate header). This login page needs to take the information from the WWW-Authenticate header, as well as the username and password input by the user and generate the hash it needs to send in an Authorization header.

Unfortunately, the built in functionality for generating SHA-256 hashes is disabled if you're not connected via HTTPS (according to https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto) - So does this mean that digest authentication is not supported by web browsers natively (unless they choose to use MD5 instead of something more secure)? If you're implementing digest authentication, you need to supply your own hashing functions? I also don't quite understand why disabling the ability to do hashes helps user security (in a non-https context).

An assumption:

Upvotes: 1

Views: 705

Answers (1)

Dan Forever
Dan Forever

Reputation: 431

So to answer my own question (partly):

It turns out that the user side is handled entirely by the browser (i.e. Generic login modal pop-up). Java script doesn't even have access to the response headers anyway.

I guess to prevent poorly implemented non-secure logins?

The examples I've seen work around it by providing functionality entirely via xhttprequests.

I still don't know what benefit denying access to hashing algorithms provides though

Upvotes: 1

Related Questions