Digest Access Authentication

vmailvmail Junior MemberPosts: 11
Hi, I would like to web scape some data from a web page that uses digest access authentication.

I've captured this from Charles

telnet 192.168.1.11 80
GET /cgi-bin/minerStatus.cgi HTTP/1.1
Authorization: Digest username="root", realm="antMiner Configuration", nonce="e9e1achanged7", uri="/cgi-bin/minerStatus.cgi", response="b47changed342a", qop=auth, nc=00000001, cnonce="a3changed0"

This is nothing like basic authentication, how do I go about implementing this in either AMX or Telnet?

Comments

  • MiferMifer Junior Member Posts: 1

    Even though the OP is about a year old I'll answer since I had to deal with this recently. Digest authentication essentially hashes (using MD5) several pieces of login information several times that makes decoding this information very difficult. I couldn't find any netlinx libraries that offered the functionality of MD5 hashing (which, by itself, is not a secure way of hashing sensitive information) but you can create your own function based on this pseudocode. https://en.wikipedia.org/wiki/MD5#Pseudocode

    The process requires you to first send a simple request for the desired resource on the server and the response will be 401 (Unauthorized) along with a few pieces of information that you'll need to authenticate as seen in this example.

    The pieces of information needed to finish authentication are as follows:

    username: sent as "plain text"
    realm: sent by the server in the first response
    nonce: hash generated by the server and sent in the first response
    uri: the resource you are requesting from the server (without the protocol and host)
    qop: sent by the server in the first response. Depending on the value given from the server, you may need to hash different pieces of information together
    nc: 16 bit counter padded with 0's. Depending on the server, you may have to increment this. In my case I could always send 00000001 and there was never a problem
    cnonce: a random 4 Byte hex provided by the client device
    response: this is the MD5 hex that is calculated based on what the value of the qop field is, sent by the server
    opaque: a hash string sent by the server in the first response. In my case the server never sent this so I omitted it in consecutive requests

    I had to develop a module that would connect to a server for a REST Web API. If I got the 401 response code I would go through the authentication process and save the necessary values if I needed to continue sending requests to that server.

    Wikipedia was extremely helpful in developing the module as well as this collection of libraries (especially the includes for http and uri):

    https://en.wikipedia.org/wiki/Digest_access_authentication
    https://github.com/AMXAUNZ/amx-util-library

Sign In or Register to comment.