Jump to content

DavidRa

Members
  • Posts

    32
  • Joined

  • Last visited

Recent Profile Visitors

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

DavidRa's Achievements

  1. The API pool was indeed stopped and the API was returning 503 as a result. Starting it (and moving to a new VM host that wasn't overloaded) has fixed, thank goodness.
  2. Summary - the web extension never turns blue or black after upgrading the server from 9117 to 9300. Looks like I busted something with the upgrade from build 9117 to 9300. Passwordstate itself is working as expected - it's all still branded / coloured correctly, and it does show up as build 9300. The settings under Adminstration show that the browser extension is enabled for all: But the extension (I'm using version 9117 from the Microsoft Edge store - https://microsoftedge.microsoft.com/addons/detail/pbbamlchainnpdodbeobfpgcpffpclka, on Edge 93.0.961.10 (Official build) dev (64-bit) in case it's relevant) stubbornly refuses to change from red to black even after a reinstall and clicking on the "Confirm" option for the URL. The server error console is empty. Any suggestions?
  3. Ohhh! That's much better. I completely misunderstood the process it seems.
  4. Could someone point me in the direction of the upgrade file and process to get from 8993 to 8995? My current 8993 deployment wants to switch straight to V9 and I'm not ready for the license and functionality changes, and the manual download URLs I thought used to be on the change log are no longer there.
  5. I don't see how to get this pricing. If I go to the Buy Now page, the best I can see for 5 users is $573.54. It's $434.50 for the licenses and $86.90 for the maintenance, both ex GST. Could you clarify please, Support? As an aside, ~$600 is a tough price hike to swallow (from $0 previously, I was using the free version while I spruiked it to customers) with no notice - the 8995 build was released only yesterday so I didn't see the post-upgrade notification; and now my 8993 deployment wants to go straight to 9050.
  6. 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.
  7. Thanks - the record is gone, and now my API calls work. Win!
  8. 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!
  9. 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."}]}]
  10. 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>" }
  11. 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
  12. 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).
  13. 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.
  14. 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.
  15. +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).
×
×
  • Create New...