Jump to content

DavidRa

Members
  • Posts

    32
  • Joined

  • Last visited

Everything posted by DavidRa

  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).
  16. 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.
  17. Adding my own +1 to this. Ideally, it's part of the standard documentation suite that comes in the upgrade ZIPs.
  18. 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.
  19. It's failed to show the panel when the icon is clicked - the icon gets the blue underline from the click, but it doesn't show. Probably reproducible 2 out of 5 clicks, maybe 3/5? Clicking twice more (close, open) seems to show it: Then the panel itself has shown about 4x final size, then sometimes resizes to correct and sometimes not - haven't managed to capture that one yet.
  20. It was looking good, I have had some success. Looks like the recent MS updates may have gotten in the way again though (a couple of rendering issues). This is very annoying (and I know it's not ClickStudio's fault). Still seems to be working enough though.
  21. Certainly is (it was buried deep in the text, would have been nigh on impossible to see sorry). Happy to provide further info if it'll help.
  22. Just noticed it's appeared in the store. Downloaded it on two machines both running version 1709 (16299.15 and 16299.19) which I think should meet the requirement on the store (build 14393.0 or later). Seems like I'm missing a setup step - as can be seen, it appears to be "not quite right" (and I did restart the browser, enable the plugin and browse to my Passwordstate site (v8.1.8114) first): No build number shown, doesn't recognise the ClickStudios community as a saved site, none of the menu items work. Not even generating a new password :(. Still good to see it's present, hopefully we can get an update soon!
  23. As I understand it, the current extension is compatible with Chrome. I also understand that Chrome extensions are, by and large, compatible also with Edge (they just need to be placed in the Windows Store). I'd really really like to see this, because it's now just about the only feature keeping me from using Edge more frequently.
×
×
  • Create New...