Jump to content

DavidRa

Members
  • Content Count

    27
  • Joined

  • Last visited

About DavidRa

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Support - you're right. There's definitely a "report" request here, as that means the security admin can report on all passwords, not just those in shared lists. But the other side of the coin is to able to show end-users that a password that might previously have been "ok" has now been compromised. For example, I create a secure unique password for a site, let's say, "correct horse battery staple". Months after the password is created and stored successfully, Randall releases his comic, and thirty million people use it in various places. That password then is compromised somehow and added to HIBP. The user views their password list and now knows their password was potentially compromised and can take action as appropriate. I can also see a use case to expand that notification into the browser extension - perhaps the icon can flash, or the extension can turn the password fields red, or show an alert that the password (not necessarily the site) is no longer secure. I interpret the "once every update" to mean that passwords need only be re-evaluated across the board when Troy updates the downloadable lists and, simultaneously, the API results and versioning.
  2. Thanks - the record is gone, and now my API calls work. Win!
  3. 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!
  4. 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."}]}]
  5. 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. 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>" }
  6. 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
  7. Nah most of those were already in the list, the current 10GB->40GB dataset only gained 20M new password hashes in 550M total. That page you linked also includes a screenshot from 1Password I expect, showing the Pwned status of passwords against the list (right under that quote).
  8. Yes - 1Password includes something they call Watchtower: I don't necessarily have useful suggestions about storage and searching, though, or at least likely none you wouldn't already have considered.
  9. It's a fair point, but since the 1Password service integrates, there might be a way forward. It may end up depending on having a local cache (40GB) - but I'd definitely be OK with that as a requirement/tradeoff.
  10. +1 To clarify - blocking save on validation failure prevents changing other details on an entry that already exists - so you can end up editing a password to change details and not being able to save until you update the application or device using that password (plus any dependencies).
  11. I'm not sure about this one. I've found that the plugin sometimes populates random fields with usernames and passwords (which seems to be because the site just names the signin fields "text2" and "text3" and those can appear almost anywhere). I think if it was in the plugin as "Fill and submit" or similar that might work though.
  12. Adding my own +1 to this. Ideally, it's part of the standard documentation suite that comes in the upgrade ZIPs.
  13. This feature suggestion is twofold - reports and immediate visibility of Pwned Passwords. I'd like to see the possibility of running a report that lists passwords that are in the Have I Been Pwned dataset. I've got 151 passwords just in my own personal Web Passwords list, let alone the hundreds of other passwords to systems, customer environments and other personal lists etc. It's not feasible for me to check them all (even if I can get access via the backup administrator account) - going one by one in the Edit Password screen is too slow. Ideally the report can be run (say) monthly and show the number of times the password has been found this month as well as last month - highlighting changes and new entries, which would be a good indicator of the passwords most at risk. For example, if you had a table like this: You could colour code rows, and allow the administrator to set specific thresholds, or even support different reports, for example: Only include entries that have changed Only include entries that have increased by more than X occurrences Highlight entries with more than X occurrences Send a report to each user with their own passwords that have been found Since the API seems to be present (and I'm already checking new entries for matches to the list), it could even be added as a banner to the top of each password list or highlighted directly in the web UI - red lists have pwned passwords, for example, and red entries in lists are the pwned entries.
×
×
  • Create New...