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


Forums

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 3 results

  1. Mario Härdi

    Azure MFA Authentication

    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
  2. 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
  3. 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: 202.136.110.111 is neither permitted nor denied by best guess record for domain of support@clickstudios.com.au) client-ip=202.136.110.111; Authentication-Results: mx.google.com; spf=neutral (google.com: 202.136.110.111 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
×