Local Authentication and 2FA
First factor (email + password), TOTP 2FA from an app or by email, sessions, account lockout, and the 2FA reset procedure
Differs depending on the model
Shared Model (SaaS): 2FA is available and optional at account level; an organization may enforce 2FA for all of its users. Enterprise Model (Dedicated): on some dedicated installations 2FA may be unavailable — in that case the option does not appear in the interface, while the first-factor rules and account lockout remain in force.
This page describes the authentication controls for local accounts, that is, accounts that authenticate with email and password. Federated authentication is covered separately in SSO — OIDC and SAML.
For accounts that access the platform exclusively through the organization's identity provider, authentication, the second factor, and access recovery are managed by the organization, not by the platform support team. On a password authentication attempt, the platform responds with the message „Acest cont se poate autentifica doar prin SSO. Te rugăm să contactezi organizația ta.” (“This account can only authenticate through SSO. Please contact your organization.”)
For step-by-step procedures aimed at end users, see Account security.
First Factor — Email and Password
The first factor is always the email + password combination and applies to all local accounts, whether or not 2FA is active.
| Element | Rule |
|---|---|
| Identifier | the account's email address |
| Case sensitivity (email) | the email address is not case-sensitive |
| Accidental whitespace | leading and trailing spaces in the address are ignored |
| Password length | minimum 8 characters, maximum 128 |
| Case sensitivity (password) | the password is case-sensitive |
| Password storage | passwords are stored hashed — they are not stored in clear text and cannot be recovered |
Email Address Confirmation
When the account is created, the email address must be confirmed through the link received by email. Authentication is not permitted until confirmation. The confirmation link does not expire.
When the email address is subsequently changed, the new address must be confirmed in turn. Until then the account remains associated with the previous address, which continues to work for authentication — an unconfirmed change cannot cause loss of access.
Password Reset
Password reset is performed from the authentication page, through a link sent to the account address, valid for 6 hours. After expiry a new link is required.
The recovery form does not confirm whether the account exists. The message displayed is identical whether or not the address entered is registered in the platform — the form only confirms that the request was submitted. This is an intentional data-protection measure: it prevents the form from being used to determine whether a particular person has an account in the platform (account enumeration).
Resetting the password does not disable 2FA. After setting a new password, the verification code is still requested at authentication. Password recovery and 2FA reset are entirely separate procedures.
In SSO-exclusive mode, an organization's users cannot reset the local password — see Account Rules.
Sessions
| Situation | Behavior |
|---|---|
| Ordinary session | expires after 30 minutes of inactivity; re-authentication is required |
| With “remember me” enabled | the session does not expire through inactivity, for 2 weeks |
| Manual sign-out | ends the session and cancels “remember me” on all devices |
The “remember me” option retains access to the account for two weeks without asking for either the password or the 2FA code — it is not recommended on shared or public computers.
Second Factor — 2FA
2FA is the second authentication factor and is enabled individually, per account. An organization may require all of its users to enable it.
The Standard Used
The verification codes are TOTP (Time-based One-Time Password) codes compliant with RFC 6238 and, by inheritance, with RFC 4226 (HOTP).
| Element | Value |
|---|---|
| Algorithm | TOTP, HMAC-SHA-1 |
| Code rotation interval | 30 seconds |
| Code length | 6 digits |
| App enrollment | QR code, in the standard otpauth:// format |
| Validity at verification | approximately 3 minutes from code generation |
| Code reuse | an accepted code cannot be used a second time |
Being an open standard, the platform's 2FA works with any TOTP-compatible authenticator app (Google Authenticator, Microsoft Authenticator, and others). The code is always 6 digits, both in the authenticator app and in the codes sent by email.
The 3-minute acceptance window is wider than the 30-second rotation interval. The tolerance is intentional and exists for the email method: several tens of seconds usually pass between code generation and the moment the user reads it in their inbox, and without this margin the code would expire before it could be used.
Available Methods
One of two methods is chosen at activation. The method cannot be changed directly — changing it requires disabling and re-enabling 2FA, with a new enrollment.
| Authenticator app | Code by email | |
|---|---|---|
| How the code is obtained | generated locally by the app | sent to the account's email address, at every authentication |
| Requires a phone / app | yes | no |
| Requires email access at every authentication | no | yes |
| Works without internet on the device | yes | no |
| Recommendation | preferred method | alternative |
Both methods use the same TOTP algorithm and the same 6-digit code format — only the delivery channel differs: the app displays it locally, while the email method transmits it in a message. The difference has security consequences: with the email method, the security of the second factor depends on the security of the mailbox — if the email is compromised, the second factor is compromised. The authenticator app method does not depend on email delivery, and the code does not transit a channel that can be intercepted.
The email method is intended for situations where the user does not have a phone on which an authenticator app can be installed, or cannot use such an app.
Organization-Wide Enforcement
An organization may require 2FA for all of its users. While the setting is active, an account without 2FA cannot access the organization's data. The setting can be enabled only by the Super User, and only if they already have 2FA active on their own account — a safeguard against locking themselves out. The setting applies only to the organization that enabled it, not to the other organizations of the same account.
The configuration, the exceptions, and the exact behavior are documented in Settings — Mandatory two-factor authentication (2FA).
No Backup Codes
The platform does not use backup codes. This is a design decision with a direct operational consequence: if the user loses access to their 2FA method — lost phone, reinstalled app, lost access to the mailbox — the only recovery path is deactivation of 2FA by the support team, following the procedure below.
If the user has lost access to the email address itself, there is also the option of being re-invited on a new address by the organization (see Loss of Access to the Email Address).
Deactivation Notification
On any deactivation of 2FA, the platform automatically sends a notification email to the account address, with the subject „Autentificare în doi pași dezactivată” (“Two-step authentication disabled”). The email is sent in both situations: when the user disables 2FA themselves and when deactivation is performed by the support team as part of the reset procedure.
The notification acts as a detection mechanism: a user who receives this email without having requested deactivation must contact the support team immediately — the account may be compromised.
As long as the user can still authenticate, deactivation is self-service. On deactivation, the account's 2FA configuration is permanently deleted; a later re-activation requires a new enrollment, and the previous QR code is no longer valid.
2FA Reset Procedure — Dual Authorization
2FA reset is a dual-authorization control. It is performed only on the basis of two independent requests — the user's request, for their own account, and the confirmation of the organization's Super User. Neither is sufficient on its own, and the two must reach support through separate channels.
| Step | Action |
|---|---|
| 1 | The user submits the request, preferably from the email address registered on the account |
| 2 | Support separately requests confirmation from the company, which verifies the requester's identity |
| 3 | Support disables 2FA; the user automatically receives the notification email. No notification is sent to the organization |
| 4 | The user authenticates with email and password only, and re-enables 2FA themselves, through a new enrollment |
The previous 2FA configuration is never recovered. The support team can only disable 2FA — it cannot transfer, reconstruct, or enroll a method on the user's behalf.
Account Lockout
Account lockout is a mechanism independent of 2FA: it protects the account against repeated guessing attempts, regardless of which factor was entered incorrectly. It is also the mechanism through which throttling at the authentication layer is achieved (see Network Security).
The account is locked automatically after 10 failed authentication attempts. The counter is shared across both factors: it counts wrong passwords and wrong 2FA codes alike. Ten wrong passwords lock the account even if the 2FA verification step was never reached.
| Stage | Behavior |
|---|---|
| Wrong password | failed-authentication message, retry possible |
| Wrong 2FA code | message „Codul de autentificare este incorect.”, retry possible |
| 9th failed attempt | warning „Mai ai o singură încercare până se blochează contul.” |
| 10th failed attempt | the account is locked; if the lock occurred at the 2FA step, verification is cancelled and the user is returned to the authentication page |
| Locked account | message „Contul tău este blocat. Verifică contul de email pentru instrucțiuni deblocare.” |
The counter resets on a successful authentication or when the account is unlocked.
Unlocking the Account
Unlocking is self-service, by email:
- At the moment of locking, an email containing an unlock link is sent automatically to the account address.
- If the email did not arrive or the link is no longer at hand, the user can request another one from the authentication page.
- Following the link unlocks the account and resets the failed-attempt counter.
The lock is not lifted by the passage of time — a user action is required. There is no automatic expiry window for the lock.
A second unlock path: if the user goes through the password recovery procedure and sets a new password, the account is unlocked automatically at that moment, without needing the unlock link. This path is useful when the lock was caused by wrong passwords.
Like the password recovery form, the unlock form does not confirm whether the account exists: the message displayed is identical whether or not the address entered is registered in the platform.
Unlocking Does Not Replace a 2FA Reset
Unlocking only returns the attempt counter to zero; 2FA remains active on the account. If the user entered the codes incorrectly but still has access to their 2FA method, unlocking is sufficient.
If, however, they have lost access to the 2FA method, unlocking solves nothing: the code will be requested again at authentication, and after 10 failed attempts the account will lock once more. The only solution is a 2FA reset. If the account has also remained locked in the meantime, unlocking is required as well — these are two distinct operations.
Loss of Access to the Email Address
If the user no longer has access to the account's email address, they can neither recover the password, nor receive 2FA codes by email, nor receive the unlock link. In this case the organization can disconnect the account from the organization and send a new invitation, to the current address, from the staff administration area.
Existing data is not lost. Only the link between the person and the authentication account is broken: the person's record and their history in the organization remain untouched. After the invitation is accepted, access is via the new email address.
Exception: the Super User cannot be disconnected in this way; for them, access recovery is resolved together with the support team.