Jump to content

API returning HMAC Hash Validation Failure


DavidRa

Recommended Posts

I'm trying to write myself a little script to match Passwordstate hashes to HIBP and I've fallen at the first hurdle.

 

My PWS server is in a remote network so I'm trying to use the standard API. I've generated a new admin API key in Administration > System Settings > API, saved it and restarted IIS. I appear to have the correct API key in my script, because when I set it to a known incorrect value, I get a different failure mode.

Correct API Key:

PS> try { $PWSRecords = Invoke-Restmethod -Method GET -Uri $PWSAPI -Header @{ "APIKey" = $PWSAPIKey }  } catch {  $_.Exception.Response | fl *}

IsMutuallyAuthenticated : False
Cookies                 : {}
Headers                 : {Pragma, Strict-Transport-Security, X-UA-Compatible, Content-Length...}
...
LastModified            : 17/01/2019 10:23:06 PM
StatusCode              : Forbidden
StatusDescription       : [{"errors":[{"message":"Forbidden"},{"phrase":"HMAC Hash Validation Failure."}]}]
...
ResponseUri             : https://passwordstate/api/passwords/?QueryAll&PreventAuditing=True
Method                  : GET
IsFromCache             : False

Wrong Key:

PS> try { $PWSRecords = Invoke-Restmethod -Method GET -Uri $PWSAPI -Header @{ "APIKey" = "SomethingInvalid" }  } catch {  $_.Exception.Response | fl *}

IsMutuallyAuthenticated : False
Cookies                 : {}
Headers                 : {Pragma, Strict-Transport-Security, X-UA-Compatible, Content-Length...}
...
StatusCode              : Unauthorized
StatusDescription       : [{"errors":[{"message":"No Authorization"},{"phrase":"An error has occurred trying to validate the API Key as specified in the 'System Settings' section of Passwordstate. Please check the API Key value 
                          has been specified, and is correct."}]}]
...
ResponseUri             : https://passwordstate/api/passwords/?QueryAll&PreventAuditing=True
Method                  : GET

I have found that if I target a specific shared list it works:

PS> $PWSRecords.Count
0
PS> $PWSAPI = "https://passwordstate/api/passwords/10?QueryAll"
PS> try { $PWSRecords = Invoke-Restmethod -Method GET -Uri $PWSAPI -Header @{ "APIKey" = $PWSAPIKey }  } catch {  $_.Exception.Response | fl *}
PS> $PWSRecords.Count
15

But a specific private list does not:

PS> try { $PWSRecords = Invoke-Restmethod -Method GET -Uri $PWSAPI -Header @{ "APIKey" = $PWSAPIKey }  } catch {  $_.Exception.Response | fl *}

IsMutuallyAuthenticated : False
Cookies                 : {}
Headers                 : {Pragma, Strict-Transport-Security, X-UA-Compatible, Content-Length...}
...
StatusCode              : Forbidden
StatusDescription       : [{"errors":[{"message":"Forbidden"},{"phrase":"The System Wide API Key cannot be used with Private Password Lists."}]}]
...
ResponseUri             : https://passwordstate/api/passwords/14?QueryAll
Method                  : GET

I do not think I have any lists with any form of API restrictions (e.g. restricted groups, IP ranges or different API keys) and I believe everything is set to defaults for the server itself (no restrictions on access by user or IP, etc). Is there a log I can look at to find the cause of failure? Am I unable to retrieve all passwords because some are in private lists? That seems ... annoying for audit purposes :)

Link to comment
Share on other sites

Hi David,

 

Are you wanting the API to return Hash values of the passwords? If so, the documentation below shows how this can be done.

 

Also, the System Wide API key is not designed to return password from Private Lists - this is for security reasons. You either need to use the API Key specific to those lists, or instead use our Windows Integrated API - but that only gives you access to the same credentials you would see when logged into Passwordstate.

 

hash.png

Link to comment
Share on other sites

I was actually trying to retrieve "everything" - getting hashes will be better, but I was starting from this:

Retrieving all Passwords in all Password Lists

GET /api/passwords

You can retrieve all Passwords in all Shared Password Lists by specifying the System Wide API Key, with a simple GET request - this is similar to the 'Export All Passwords' feature available in the Administration area of the Passwordstate web site.

red-info-16.png Note: By default, the retrieval of all Passwords records will add one Audit record for every Password record returned. If you wish to prevent audit records from being added, you can set the PreventAuditing parameter to true - if this parameter is omitted, the default option is false.
 

    # PowerShell Request
    $PasswordstateUrl = 'https://passwordstate/api/passwords/?QueryAll&PreventAuditing=<value>'
    Invoke-Restmethod -Method GET -Uri $PasswordstateUrl -Header @{ "APIKey" = "<apikey>" }
Link to comment
Share on other sites

I do and (as per OP) if I don't specify that key I do get a different error.

 

Right key:

StatusDescription : [{"errors":[{"message":"Forbidden"},{"phrase":"HMAC Hash Validation Failure."}]}]

 

Wrong key:

StatusDescription : [{"errors":[{"message":"No Authorization"},{"phrase":"An error has occurred trying to validate the API Key as specified in the 'System Settings' section of Passwordstate. Please check the API Key value has been specified, and is correct."}]}]

Link to comment
Share on other sites

Hi David,

 

I've just done a code search on "HMAC Hash Validation Failure", and this is reporting an issue with the GUID column in the Passwords table - sorry I did not pick up on this originally. So this is not really related to the API at all, and you should see issues in the UI with one Password List at least for this problem i.e. a "database integrity issue" page.

 

Can you have a look in this table and see if any of the GUID values is set to '0x' - we've seen this before where Antivirus software can cause issues with saving encrypted data. Or someone has been trying to manipulate data directly in the database, but I doubt that has occurred?

Regards

Click Studios

Link to comment
Share on other sites

I can confirm no tuples in the Passwords table have a GUID of 0x. All 300+ entries have comparable length and are in the form:

 

0x07B431134861EFFC04E9...
0x084D3322F13EBE8A8891...
0x08EDF4D709B2B937D1BD...
 

All are "0x" followed by 128 characters, so 0x and 64 bytes hex-encoded. I believe I have had a corruption in the past, but as far as I know it's all been OK for months. The host has no AV software installed and I don't believe there's been any manual adjustments to data (other than execution of scripts from Click Studios support in the past).

 

However, based on your comment, I have indeed found a password list with an integrity problem. There's a password marked with the title "NEW OBJECT: <Account>" which might have been auto-discovered. Perhaps I should lodge a support call outside the API thread. Thanks!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...