Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Hi Mark, Can you please run the following SQL statement below using SQL Server Management Studio, as this will clear the list for you. USE Passwordstate DELETE FROM [PR_BadPasswords] I tried copying this List to excel, and Excel even timeout out for over a minute before it was responsive. I'm not sure if there's a great deal we can do around performance for this, except I would recommend using our Password Policies instead - you can enforce the use on strong passwords, which would negate the requirement to check these "simple" passwords in the list. Regards Click Studios
  3. I've been trying to configure our Password Reset Portal with the "Bad Passwords" feature, by uploading the top 100,000 most common passwords from the seclists repository: https://raw.githubusercontent.com/danielmiessler/SecLists/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt Unfortunately, the upload seemed to fail partway through, and I'm left with only a portion of the passwords loaded in the "Bad Passwords" list. Unless I'm missing something obvious, there doesn't seem to be any way to delete the list and retry the upload other than clicking delete on each entry.
  4. support

    Have I Been Pwned? Integration

    Hello Markeldo, We do plan on looking into this as an option at some stage, as soon as we can allocate some time to it. This may be quite a bit of work, as we need to consider everywhere Bad Passwords are used i.e. UI, API, Windows Service. We'd also need this to be an option, for customers who do not want to allow Passwordstate to communicate on the Internet. Regards Click Studios
  5. Hello, Yes, if you are not using AD Integrated authentication, then unfortunately you cannot use this version of the API. If you're interested in converting to this, let me know and I can email you some instructions. Regards Click Studios
  6. I tried to check out the Win API documentation. However, I experience the same problems as described in this post. In addition, we only have the forms based authentication for passwordstate, therefore the Win API is of little use to us, right?
  7. markeldo

    Have I Been Pwned? Integration

    Is there any plan to integrate the Pwned Passwords API as an option in the existing "Bad Passwords" feature? The existing Bad Passwords feature is only really useful for short wordlists, and even if it could handle 300+ million records, Troy Hunt's lists come as SHA-1 hashes.
  8. Last week
  9. Hi Lucas, Thanks for your request. We believe having some sort of additional Auth for the API would cause issues with various scripting environments, which is why we have not considered it to date. We're also considering adding a "per user" API Key as well in a future build. Have you considered the use of our Windows Integrated API - this does not require API Keys at all, and gives you the same level of access as logging into the UI. You also have complete control over who is allowed to use either API, which can be found in the Administration area. So if you have some concerns here, you can restrict access to a certain degree. You can also restrict which IP Addresses can be used to make API Calls from - this can be found on the screen Administration -> System Settings -> Allowed IP Ranges. Regards Click Studios
  10. Hello everyone, first of all I want to stress that I really like Passwordstate a lot. Great product which is easy to use and provides a ton of features! Nevertheless I think the current Web API implementation is quite problematic. Right now, every person with knowledge of the Web API Key of a password list can access the stored information in the respective list. In my understanding, this policy is a serious security vulnerability since such easy accessibility thwarts the whole concept of role-based permission handling. For the following two reasons I would urge an additional authentication via Username and Password in the API Call: API usage becomes highly inconvenient in situations where a specific API Key is utilized by multiple users. Every change in the group of authorized persons must subsequently result in the generation of new API key to ensure the application of the authorization model. Especially when people leave the company one cannot risk to expose new or changed passwords / hosts via the API. However, this has to be done manually for every password list. Therefore, the whole process of enforcing permissions is highly prone to errors since one has to track down every affected list. API-Keys cannot be stored in any code that might be visible to a 3rd party. Since knowledge of the API key equals access to the password list such non private code offers access to passwords to completely unauthorized individuals. Having some (optional) form of authentication (preferably via Oauth) in the API call would help a lot to ensure that authorization models can’t be breached via an “API Backdoor”. See also: https://nordicapis.com/why-api-keys-are-not-enough/ Kind regards, Lukas
  11. In one type of system yes and that's how we'll setup that sub-set, although they have another problem entirely which will need more scripting to solve :( Other types of devices have both root and "normal" users with root not being able to login. Of course we could forego changing the root password, but that would leave the console open. So in those cases we'll need that script I described (or we open root up for SSH, but naahhh).
  12. Hi Buckit. Not exactly sure of your environment, but is it possible these accounts can reset themselves without a Priv Account? As long as they have the required permissions, then this is possible in Passwordstate. Regards Click Studios
  13. I appreciate it It's of course well and good for me to say "it should be as simple as ...", but that's a stupid remark of course. I have no way of knowing your code. The end-result may be simple (an added HTML tag), but there's no telling how the page gets generated. Something-something-assumptions.
  14. Thank you very much @support, for your patience with me. I honestly think we don't pay you guys enough to deal with the amount of shite I send your way. You are of course utterly correct. Thank you for snapping me out of my stuck-thinking: I was in some recursive loop, not properly thinking about how to tackle my current problem, also because I was avoiding something specific. As you say, the only right solution here would be to make use of the API by building a script to tackle the situation. New IoT device? Run the script which: Defines the host, Defines the privileged password object, Defines the privileged account and the Defines the other password object(s) and ties them to the C privileged account. The downside to this is that you'll get a wild-growth of priv.accounts. The reason I kept avoiding this solution, is because it means I have to write a lot of Powershell code. Why? Because I'm stubborn. I don't want to make a one-off script that works for one specific solution, with hardcoded script IDs and other hardcoded settings. No, Mr Smug here wants to make everything a lookup through the API There's a Powershell module out there already, but it uses API keys instead of kerbauth which we prefer right now. But yeah. You're right. I'll get over myself and start tackling this problem the right way. That module needed to be written anyway and I'm postponing the inevitable. It ain't gonna write itself.
  15. Hey Buckit, We we take a look and see if this will be a simple change. If it is we'll include it in a future build. Regards, Support
  16. support

    Password Extension: Fill on click instead of auto fill

    Thanks for the vote Greg. We'll consider this request when we next work on feature development for our extensions. Regards Click Studios
  17. Hi Buckit, Thanks for your request. At this stage we're not sure this is something we would like to implement, as it goes against best practice fur using unique passwords across your hosts. It would also required a complete redesign of our Password Reset Engine, Account Heartbeats, Remote Site Locations, Reporting, API, etc, etc. Regards Click Studios
  18. GregSmid

    Password Extension: Fill on click instead of auto fill

    Hey all, I happened across a good example of an undesired auto-fill today. This is the settings page for our Barracuda email device, which has fields to set the address of the outbound SMTP host and username/password fields for the Barracuda to authenticate with that SMTP host. The PasswordState plugin sees those username and password fields, and fills them in with the credentials I have saved to log into the Barracuda web GUI... which of course is not what should be in those boxes. Having an option to only fill a page after clicking the PS plugin icon would solve this situation.
  19. Hey guys, Just a tiny suggestion: would it be possible for you to update the PasswordState Change Log webpage to include anchor tags in each update's header? For example, if I'd like to specifically link to build 8180, it'd be great to have something like https://www.clickstudios.com.au/passwordstate-changelog.aspx#8180. The changelog has grown to considerable size, so it'd help my colleagues if they didn't have to <ctr><f> for a buildnum. It could be as simple as changing this: <h3> Passwordstate 8.1 - Build 8180 (21st November 2017)&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> ...to this: <h3> <a name="8180">Passwordstate 8.1 - Build 8180 (21st November 2017)</a>&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> Take care! :)
  20. Buckit

    SSH key rotation

    Glad to hear that it's been of some help! I have a setup where an AD-account is used as privileged Linux user for the password changes by PasswordState, it uses the SSH keys you can store in PState and does it exactly in the way I've explained: pubkey in AD. What's more, we even pull our SUDO commands for the account in question from AD, as explained on my blog. I'll have to look into automating the key rotation you've asked about, as that will up the security a bit more :)
  21. 1527460Kevin

    SSH key rotation

    Hello Buckit Thank you for your answer! The solution looks pretty good, I might just go for that!
  22. Good morning everyone :) The past two weeks we've discussed this a bit, so I thought I'd make it a real feature suggestion. I would very much like the possibility to define one-to-many relationships for accounts to hosts (1:N). The biggest use case I can think of for this, is Linux privileged user accounts in Linux/Unix environments where a centralized IAM-platform is not available. For example, a network with many IoT devices which allow SSH for management functions, but which cannot integrate with AD or LDAP. In such a case it would be a great hassle to define privileged accounts on a 1:1 basis. If I would be able to define one Linux account, with a strong SSH keypair (or a frequently rotating strong password), that is to be used on the relevant systems as the designated privileged user, that would be ever-so-helpful. #RunOnSentence.
  23. Buckit

    SSH key rotation

    Aye, it should be possible to achieve, but it'll need some work on multiple ends of things. The biggest problem is the distribution of the private key. @1527460Kevin suggests generating them on the Linux box and then pushing them out to PasswordState. Personally, that's not something I'd recommend because now you're transporting the literal key to your system, which either is not password protected, or your transporting along with its password. That could/would be not a problem, except that you're wanting to do it unattended. I mean, if you're doing it personally, you can immediately tell if something's gone wrong. The prettiest solution I can think of is to: Generate the new keypair on the PasswordState box using puttygen. Import the private key into the appropriate account object into PasswordState using the API and remove the original file from the file system. Have the Linux/Unix hosts use AD for their authentication backend (through SSSD). Push the public key into the relevant user's altSecurityIdentities field in AD. All this should be doable with Powershell, combined with API calls to PasswordState. It also takes care of the public key distribution, saving you the effort of sending the pubkey to X amount of servers. Alternatively you could of course push the pubkey to each of the X servers that the account exists on, using pscp (the Putty CLI SCP client). However, that brings me back to an issue I was having earlier last week: PasswordState does not have a way of linking one account to X amount of hosts. Unless it's an AD account, you'll find 1:1 - account:host relationships. That's not always ideal.
  24. support

    SSH key rotation

    Hi Kevin, We believe the only way this would be possible would be via our API, but unfortunately we've never tackled something like this. Hopefully someone in the community has strong linux scripting skills, to point you in the right direction. Regards Click Studios
  25. So that's good news twice! For me because I now know that I am not doing it wrong, for you because you can now fix a bug. I will have to do my work double now, because I need to write a procedure to do the update process from dev/test, via acc, to prod. Which now means I have to describe both the manual and the "regular" internet disconnected upgrade method. But at least I now know what to do. Thank you for all the effort!
  26. 1527460Kevin

    SSH key rotation

    Hello, Anyone that has added some sort of SSH key management with Passwordstate, maybe with the use of API's? I've read in the user manual that it is possible to start a remote session via an SSH key in a password list, is it however also possible to do some sort of SSH key rotation? maybe via the use of a script that generates new keys on the hosts and pushes them to Passwordstate or something like it? I'm curious wether someone here has done it or has thought about it. Thanks for all the help so far, I'm loving both Passwordstate and the community!
  1. Load more activity
×