Search the Community
Showing results for tags 'security'.
Found 3 results
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
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
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 <email@example.com>" 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: 126.96.36.199 is neither permitted nor denied by best guess record for domain of firstname.lastname@example.org) client-ip=188.8.131.52; Authentication-Results: mx.google.com; spf=neutral (google.com: 184.108.40.206 is neither permitted nor denied by best guess record for domain of email@example.com) firstname.lastname@example.org 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