TOPT

[nodeam]

Just updated to 0.9.2.7. TOPT is great feature. Thanks for that. There would be almost no need for Authelia & co. But really only 16 characters?

Why not something like that:

head -c 20 /dev/urandom | base32 | tr -d '=' | cut -c1-32

[eliandoran]

@JYC333 , perhaps you could pitch in.

@nodeam , do you have some security concerns about 16 characters? The length by itself is not a good measure.

[nodeam]

The length by itself is not a good measure.

Off course not, but it is a part of it.

1. Secret Length:

A TOTP secret with 16 Base32 characters equals 80 bits of entropy (16 characters × 5 bits per Base32 character = 80 bits). This is barely sufficient for TOTP but sits at the lower end of the secure spectrum.

3. Hash Algorithm (SHA-1):

SHA-1 is no longer considered cryptographically secure, mainly due to known collision vulnerabilities. In the context of TOTP, however, SHA-1 is used for HMAC, not for digital signatures, which makes the risk somewhat lower. Still, SHA-256 or SHA-512 would be more appropriate today.

5. Missing OTP rate limiting is a serious security concern

• The TOTP code changes every 30 seconds, but during that window, an attacker can still try up to 1 million possible codes (000000–999999).
• If there’s no enforced delay or cap on failed attempts, an attacker could theoretically try thousands of codes within those 30 seconds — especially if using automation.
• Even with the 30s limit, without throttling, offline brute-force attempts (e.g. on self-hosted instances) are realistic.

Best practice is to enforce:
• a rate limit (e.g., 3–5 attempts per minute per account/IP)
• lockout or CAPTCHA after repeated failures
• logging and alerting for suspicious activity

Comparison:
Many modern TOTP implementations (e.g., GitHub, Google) use:
• a 160-bit secret (Base32 = 32 characters)
• SHA-256 or SHA-512 as the HMAC algorithm (often configurable)

BTW: since my last update Trilium Notes doesn't send any error codes like (401|403|404|429|500) back on failed login attempt anymore. So there is no use case for fail2ban at caddy point anymore.

Logs looks like:
178.13.xxx.xxx - - [12/Apr/2025:06:14:28 +0000] "GET / HTTP/2.0" 302 34
178.13.xxx.xxx - - [12/Apr/2025:06:14:28 +0000] "GET /login HTTP/2.0" 200 819
178.13.xxx.xxx - - [12/Apr/2025:06:19:41 +0000] "GET /login HTTP/2.0" 304 0
178.13.xxx.xxx - - [12/Apr/2025:06:19:56 +0000] "POST /login HTTP/2.0" 200 858

0.92.4 provides 401 on failed login attempt:
178.13.xxx.xxx - - [12/Apr/2025:06:58:32 +0000] "POST /login HTTP/2.0" 401 783

[JYC333]

I'll create an issue to fix and improve the TOTP feature.

[eliandoran]

@nodeam , appreciate the detailed response.

[nodeam]

It would be great to get:
• a 160-bit secret (Base32 = 32 characters)
• SHA-256 or SHA-512 as the HMAC algorithm
• OTP rate limiting with lockout (3–5 attempts)
• Error codes in log for both wrong password and/or wrong TOPT

If OTP rate limiting were not doable for any reason , then error codes in log for both wrong password and/or wrong TOPT would be IMHO sufficient. fail2ban can lockout then itself due to user/admin preference.

Thank you all for your time and effort.

[eliandoran]

Closing as we now have https://github.com/TriliumNext/Notes/issues/1684 to track it.