Signotaur holds the private keys it signs with, so its web interface includes protections for sign-in, sessions, browser behaviour and security logging. This page describes those protections and the settings that affect them.
These protections are a second layer, not a substitute for keeping Signotaur off the public internet. Deploy it on a trusted internal network and reach it remotely over a VPN. See Installation.
Repeated failed sign-in attempts temporarily lock the account, including attempts made from different machines. The sign-in page still reports Invalid username or password, so it does not reveal whether the account exists or is locked. The actual reason is recorded on the Events page.
To clear a lockout, an administrator opens the Edit user details dialog on the Users page and re-enables the account. This also resets the failed-attempt count.
An account that signs in only through Google or GitHub has no password, so failed password attempts do not lock it.
Password reset and email confirmation behave similarly: the response does not reveal whether the address belongs to an account, nor whether that account has a password to reset.
A temporary password created for a new account is 20 characters long. The password policy governs what a person may choose for themselves; if its minimum length is longer than 20, that length is used instead.
Only a temporary password expires. Once the account holder sets a password of their own it does not age, and they are not asked to change it on a schedule.
Session lifetime is configured on the Options tab using Remember me lifetime for persistent sessions and Session idle timeout for sessions where Remember me was left unticked.
Signed-in sessions are periodically checked against the stored account details. Disabling an account ends its current sessions, and role changes take effect without the user signing out and back in.
This revalidation interval is set by SessionRevalidationIntervalMinutes in the configuration file. Changing it requires a restart.
The sign-in cookie and the cookie that remembers a machine for two-factor authentication are always marked Secure, so a browser only ever sends them over HTTPS. This holds even where a reverse proxy terminates TLS and forwards plain HTTP.
Signotaur sends response headers that restrict what a browser can do with its pages.
HTTP Strict Transport Security tells browsers that visit Signotaur to use HTTPS. It is sent only on the HTTPS port and does not apply to subdomains or the Internal CA's plain-HTTP validation port.
HstsMaxAgeDays in the configuration file controls how long the browser remembers this. The default is 7 days. Set it to 0 to withdraw an existing policy, or to a negative number to stop sending the header.
A content security policy restricts where the interface may load scripts from, and Signotaur cannot be displayed inside a frame on another page.
Sensitive forms use anti-forgery tokens so another site cannot submit them through your browser. A submission refused for a missing or invalid token is recorded on the Events page. The usual cause is an ordinary one: a page left open across a sign-out, so its token no longer matches. Submit the form again after signing back in.
Do not configure a reverse proxy to strip or rewrite these headers. See Running Behind a Reverse Proxy.
Signotaur fetches Gravatar images itself, so browsers never contact Gravatar directly. Set EnableGravatar to false in the configuration file to disable these lookups, such as on a server with no internet access or where you do not want Gravatar to be told which email addresses have accounts. Users then see their initials instead.
Security events record the address the request came from, shown at the end of the message as (Client IP: …).
Behind a reverse proxy, every request appears to come from the proxy. Add the proxy to TrustedProxies so that the original client address is recorded instead. See Running Behind a Reverse Proxy.
Events, error messages and API responses do not include full server paths, because clients are not necessarily operated by administrators of the Signotaur host.
Checking for updates requires a signed-in session, and the update indicator is shown only while you are signed in.
If the update feed redirects Signotaur elsewhere, the server follows it only when the document containing the new address is signed by VSoft and its signature can be verified.
When the server has no internet access, the check falls back to the browser instead. Failed checks are cached briefly to avoid repeating the same failed request and warning on every page load.