Jump to content

Search the Community

Showing results for tags 'security'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Essentials
    • Announcements
  • Passwordstate 8.x
    • General Support
    • Feature Requests
    • Feature Requests - Completed
    • Known Issues
    • Installing Passwordstate
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • Mobile Client
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 7.x
    • General Support
    • Known Issues

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL





Google Plus Account







Found 6 results

  1. Aaron Falzon

    Block Excessive Use

    Having the email when a user is viewing an excessive number of accounts is good. However, it would be nice to have an option to lock an account (either for a time or until unlocked by admin) when this happens
  2. Would like to see option to limit users from adding attachments to specific folders. Since it's already a global configuration, would expect not to be big thing to make per folder setting for it too.
  3. Dear Clickstudios, actually we are Installing Passwordstate for our internal Services and also one of our Customer. For both Installation we would be able to add Azure MFA as an additional Authentication Option. Actually there are some multi-factor provider available, but we would like to Implement it with our Existing Azure MFA instead of Implementing another third-party authentication. Is it Possible to Implement this feature? Hope someone else is also missing this feature. Thanks in Advance and Best regards, Mario
  4. Hiya, I was poking around the MSSQL database backend for PasswordState and noticed a few fields that are not stored with encryption, while they could be (ab)used to gain access to sensitive data. Or to wipe tracks should an actor gain access to the database and/or PasswordState. Obviously it's imperative that the database backend is secured to the teeth, but it's also not unlikely that the designated DBAs do not have admin-rights in PasswordState. Having access to the database may thus lead to an escalation of privileges. Most notably: Valid usernames may be harvested from the database, but I realize there's not much we can do about that. The dbo.SecurityAdmins and dbo.SecurityGroupsMembership tables are unencrypted. Could it be that the GUID field plays a role in checksumming the data, to ensure that nobody is adding access rights to their own account? Valid usernames in dbo.PrivilegedAccounts are not encrypted, giving insight into juicy targets for other platforms. Is there some method of auditing the dbo.Auditing table? What prevents a DBA from diking out a bunch of incriminating evidence? Anywho... just some thoughts, while at the office in those lost days between one holiday and the next
  5. Purpose: This process shows you how to generate a new wildcard certificate from your AD Certificate Store, which can be used for your Browser Based Gateway or you can assign it to your Passwordstate URL. Assigning it to your URL will make for a nicer end user experience, as the all browsers will automatically trust the certificate, assuming the user is accessing Passwordstate from a domain joined machine. Disclaimer: These instructions involve granting your web server permissions to a Web Server Certificate template in your AD Store. We encourage you to review and have this process approved before applying to your production environment. 1. Log into your Active Directory Certificate Authority server as a Domain Administrator 2. Open certtmpl.msc 3. In the Properties of the Web Server template, give your Passwordstate web server Read, Write and Enroll permissions, and click OK. 4. Log into your Passwordstate web server as Domain Administrator, open certlm.msc 5. Expand Personal -> Certificates 6. Right click Certificates -> All Tasks -> Request a New Certificate 7. Click Next 8. Click Next 4. Select the Web Server template, and click "More information is required to enroll for this certificate" 4. Change Full DN to Common Name and type in your domain as a wildcard. Click Add. Change the Directory Name to DNS and also type in your domain as a wildcard. Click Add 6. Under the General tab, enter a Friendly name 7. Under the Private Key tab, select the option to make the certificate exportable 8. Click OK and then click Enroll **NOTE** If you are following this process to generate a certificate to be used with your Browser Based Gateway, please refer to Gateway Install instructions in Section 6: https://www.clickstudios.com.au/downloads/version8/Passwordstate_Remote_Session_Launcher_Gateway_Install_Guide.pdf Otherwise, use these instructions below to use the certificate on your Passwordstate website: 9. Open IIS, and set the new certificate to your HTTPS web binding 10. Now from your desktop, you should be able to browse to your Passwordstate website, and Chrome will now treat it as secure Related Error #1: Certificates with a Signature Hash Algorithm of SHA-1 can also generate security warnings in later versions of Chrome. You may see this error below if your certificate is signed using SHA-1. There are different ways to upgrade your Certificate Store to SHA-256 but one of our customers kindly linked us to this article (Thanks Luis ), which helped him out: https://technet.microsoft.com/en-us/library/dn771627.aspx Related Error #2: When requesting this certificate on your web server, the wizard installs it in the Intermediate Certificate Authorities store, which can cause the browser on the web server not to trust the certificate. You may notice this behavior: To fix this, either install the certificate using Internet Explorer into the Local Machine Trusted Root Certification Authority, or just copy and paste the certificate as per the below two screenshots. You'll need to restart your browser for this to become effective: Copy Certificate from This Location: Into this Location:
  6. Greetings! I noticed that emails generated by the Community service don't pass email SPF authentication checks, and also that they aren't being DKIM signed. As a result, all emails from "Click Studios Community <support@clickstudios.com.au>" will end up in our spam filters and I'm sure other email systems as well. Here is a section from the headers of a recent message: Received-SPF: neutral (google.com: is neither permitted nor denied by best guess record for domain of support@clickstudios.com.au) client-ip=; Authentication-Results: mx.google.com; spf=neutral (google.com: is neither permitted nor denied by best guess record for domain of support@clickstudios.com.au) smtp.mailfrom=support@clickstudios.com.au From what I can tell there isn't even an SPF record for the clickstudios.com.au domain. The DKIM signature isn't critical but ClickStudios should at least have an SPF record configured to validate where email is sourcing from for the domain. Adding an SPF record to your DNS zone file should be fairly easy and quick to resolve I would think. Thanks in advance. Ryan