Na obrazovce Bezpečnost je možné změnit konfigurační parametry zajišťující bezpečný provoz aplikace. Jmenovitě jsou to následující:
Minimální délka hesla
Minimální délka hesla uživatelů i administrátorů. Délka hesla se kontroluje při přidávání nového záznamu a při změně hesla.
Heslo musí obsahovat
Zaškrtnutím požadovaných skupin znaků (malá a velká písmena, číslice, symboly) je možné zvýšit složitost použitých hesel. Za symbol se považují znaky: ! @ # $ % ^ & *. Skupiny znaků se kontrolují při přidávání nového záznamu a při změně hesla.
Životnost odkazu pro obnovu hesla
Pokud má lokální uživatel (viz typy uživatelů) problém s přihlášením a vyžádá si obnovu hesla, přijde mu na email jednorázový token umožnující heslo změnit. Tato položka určuje kolik minut je tento token platný.
Životnost odkazu pro obnovu hesla (odeslaného adminem)
Pokud administrátor požádá o obnovu hesla lokálního uživatele, přijde uživateli na email jednorázový token umožnující heslo změnit. Tato položka určuje kolik minut je tento token platný.
Životnost odkazu pro obnovu hesla (založení nového uživatele)
Při zakládání nového lokálního uživatele má administrátor možnost místo přímého nastavení hesla poslat uživateli jednorázový token umožňující heslo nastavit. Tato položka určuje kolik minut je tento token platný.
Životnost JWT tokenu
Při přihlášení do aplikace je uživatelům i administrátorům vystaven JWT token. Ten je serverem vrácen v HTTP cookie a je tak prohlížečem odesílán při všech dalších požadavcích na server. V JWT tokenu je obsažena doba po kterou je platný. Pokud na server přijde JWT token s prošlou dobou platnosti, je uživatel odhlášen. JWT token je aktualizován a doba platnosti znovu nastavena při každém úspěšném požadavku, proto dokud uživatel aplikaci aktivně používá, nebude nikdy automaticky odhlášen. Toto nastavení určuje ve vteřinách dobu platnosti autentizačního JWT tokenu.
Zjednodušeně řečeno, tento parametr určuje dobu pro automatické odhlášení v případě nečinnosti.
Klíč pro podepisování JWT tokenů
Při přihlášení do aplikace je uživatelům i administrátorům vystaven JWT token. Token je podepsaný tajným soukromým klíčem a podpis každého přijatého tokenu je pomocí toho klíče ověřen (tak je zajištěno, že není s tokenem mimo server manipulováno). Klíč by měl mít alespoň 32 znaků. Změna klíče zneplatní všechny dosud vydané JWT tokeny a prakticky tak dojde k odhlášení všech uživatelů i administrátorů. Klíč je uložen na serveru. Z bezpečnostních důvodů ale nikdy nesmí opustit server, a tak ho není možné zobrazit, pouze změnit. Výchozí klíč je vytvořen jako náhodný řetězec při instalaci aplikace.
Salt přidávaný k XSRF tokenu
Při přihlášení do aplikace je uživatelům i administrátorům vystaven JWT token. JWT token obsahuje mimo jiné XSRF token který pomáhá chránit proti XSRF (Cross-site request forgery) útokům. XSRF token je náhodný řetězec spojený s tajným klíčem (“salt”), toto nastavení nastavuje právě tento salt. Změna saltu zneplatní všechny dosud vydané tokeny a prakticky tak dojde k odhlášení všech uživatelů i administrátorů. Salt je uložen na serveru, z bezpečnostních důvodů ale nikdy nesmí opustit server a tak ho není možné zobrazit, pouze změnit. Výchozí salt je vytvořen jako náhodný řetězec při instalaci aplikace.
reCAPTCHA secret key
...
Password reset link lifetime
For user requested reset
If the local user (see user types) has problems logging in and requests a password reset, a notification is sent to his email, containing a temporary unique link allowing him to set a new password. This setting specifies for how many minutes is this temporary link valid.
(default: 30)
For administrator requested reset
If the administrator requests a password reset for some local user, a notification is sent to the user’s email, containing a temporary unique link allowing him to set a new password. This setting specifies for how many minutes is this temporary link valid.
(default: 1440 = 24 h)
For newly created user and administrator accounts
When creating a new local user or administrator, the administrator can, instead of directly setting the password, send a temporary unique link allowing the recipient to set his initial password himself. This setting specifies for how many minutes is this temporary link valid.
(default: 20160 = 14 days)
Login and authorization lifetime
After logging in a JWT token is issued to both users and administrators. It is then returned by the server in a HTTP cookie and is then always sent back by the browser in all requests to the server. The JWT token contains an expiration time, until which it is valid. If the server receives a token, which is already expired, the user is logged out. The JWT token is updated and the expiration time extended during every successful request to the server, so if the user is actively using the application, his login session is being extended continuously.
Idle login session timeout
Lifetime of authentication JWT tokens in seconds (60 - 1000000). The token is renewed by every user action so it is also a session idle timeout before logout.
(default: 1800 = 30 min)
Maximum login session timeout
Absolute lifetime of authentication JWT tokens in seconds (60 - 1000000). After this time, the token cannot be renewed by user action any more and user is logged out.
(default: 28800 = 8 h)
Password protected package access validity
Number of seconds for which a password protected package can be accessed without re-entering the password (60 - 1000000).
(default: 1800 = 30 min)
Validity period of one access to a package with a limited number of accesses
Time in seconds allowed to access a package with a limited number of accesses that will count as one access (60 - 1000000).
(default: 1800 = 30 min)
reCaptcha
reCAPTCHA secret key
Sets the reCAPTCHA secret key in case the reCAPTCHA anti-spam mechanism is used (see https://developers.google.com/recaptcha/intro). Pokud není vyplněn, reCAPTCHA se nebude používatIf not set, the reCAPTCHA will not be used.
reCAPTCHA site key
Nastavuje Sets the reCAPTCHA site key v případě použití in case the reCAPTCHA anti-spam mechanismu (viz. mechanism is used (see https://developers.google.com/recaptcha/intro). Pokud není vyplněn, reCAPTCHA se nebude používatIf not set, the reCAPTCHA will not be used.
reCAPTCHA
...
score threshold
Sets the reCAPTCHA score threshold, specifying the score value above which a request is not considered spam (number from 0 to 1, see https://developers.google.com/recaptcha/docs/v3#interpreting_the_score). Výchozí doporučená hodnota je 0,Default recommended value is 0.5.
Povolit logování reCAPTCHA výsledků
Zapíná nebo vypíná logování výsledků reCAPTCHA testů do audit logu. Mělo by být zapnuto jen dočasně při řešení problémů s odesíláním zásilek, protože může vytvářet velké množství záznamů.
Celá obrazovka s nastavením pak vypadá například takto:
...
(default: 0.5)
Enable reCAPTCHA results logging
Enables or disables the logging of reCAPTCHA test results into the audit log. Should be enabled only temporarily during debugging of problems with sending of packages, because it may create a lot of log entries.
(default: disabled)
Other settings
Trusted proxies
The list of IP addresses (comma separated) of trusted proxies.
If the application is running behind a proxy (e.g. WAF like F5, FortiWeb, etc.), it cannot directly see the IP addresses of connected clients, because the clients connect to the proxy instead. It can only see the IP address of the proxy passing the requests to the application. All the audit logs and also settings limiting administrators' logins to selected IP addresses then work with this proxy IP address, which is usually not what we want.
If we fill in this setting with IP addresses of trusted proxies, which are passing the requests to the application, and they support adding the X-Forwarded-For header (which should be common), the application will ignore the IP addresses of these trusted proxies for the sake of audit logs and access control and will use the IP addresses of clients passed by these trusted proxies (and only by them) in the X-Forwarded-For header instead.