Feature Request: Add GOTIFY_TOKEN_LENGTH configuration option

[Pyvonix]

Is your feature request related to a problem? Please describe.
When Gotify generates tokens (for applications, clients, etc.), they are always 15 characters long. This length is hardcoded and cannot be changed either through the UI or any configuration option. For environments with stricter security requirements, 15 characters may not be sufficient, and there is currently no way for an administrator to enforce a longer, more secure token length.

Describe the solution you'd like
A new application configuration option GOTIFY_TOKEN_LENGTH should be introduced to allow administrators to configure the length of generated tokens. The option should:

• Default to 15 if not provided, preserving the current behavior and ensuring backward compatibility.
• Accept any integer value greater than or equal to 15 to ensure a minimum level of security.
• Be documented alongside the other existing configuration options.

Example configuration:

server:
  [...]
  tokenlength: 15

Or via environment variable:

GOTIFY_TOKEN_LENGTH=32

Describe alternatives you've considered
Manually editing tokens after generation: Users could theoretically update tokens manually in the database, but this is error-prone, not user-friendly, and not a scalable solution for administrators.

Enforcing a fixed longer token length: Hardcoding a longer token length (e.g., 32 characters) instead of 15 would improve security but would not give administrators the flexibility to define their own required length based on their specific security policies.

Additional context
Allowing configurable token lengths is a common best practice in security-conscious applications, giving administrators the ability to align token generation with their organization's security policies or compliance requirements (e.g., NIST, OWASP recommendations). This change is fully backward compatible since the default value remains 15.

[eternal-flame-AD]

I think we can consider bumping the default token length but I don't think it's a good idea to make the token length configurable (I'm pretty sure this is a duplicate of a previous discussion but I'm too lazy to find it ..)

giving administrators the ability to align token generation with their organization's security policies or compliance requirements (e.g., NIST, OWASP recommendations).

Which OWASP recommendation said token length should be configurable? I was looking at this one:

If MFA is not enabled passwords shorter than 15 characters are considered to be weak (NIST SP800-63B). https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

Currently gotify tokens are technically 15 characters but only 14 letters are random, so we are slightly behind recommendation.

Just to be future proof if we later need to use token for other purposes like E2EE we may want to bump the strength to 128 or 256 bits (currently my math shows 84.3 bits), but I don't see why it should be configurable.

[Pyvonix]

If we consider tokens to be authentication credentials (like passwords, since they grant access to the app), 15 characters (using only upper and lower case letters) is quite short. The OWASP recommendation clearly states 15 characters when "Allow usage of all characters including unicode and whitespace", whereas tokens cannot use this full character set.
For comparison, ntfy uses 32-character tokens (with 3 fixed characters and 29 random ones).

My proposal is to provide a configuration option to shift the security risk to users, allowing them to strengthen security based on their specific needs rather than enforcing it for everyone.

I don't understand the objection to making it a configuration option. Another example is Gokapi, which is also a Go API project, offers this as a configurable option and it works as perfectly.

[eternal-flame-AD]

The OWASP recommendation clearly states 15 characters when "Allow usage of all characters including unicode and whitespace", whereas tokens cannot use this full character set.

No, th OWASP recommendation says a password is considered strong at 15 characters , not that the password must be generated from a uniform distribution out of all Unicode code points for it to be "strong", if we take it as your interpretation all password managers that don't generate Unicode characters are broken.

My objection is actually very straightforward: you said there is an industry standard recommending suppliers to make token configurable, I never remember reading such a recommendation. I also proposed an IMO workable alternative of bumping the token length universally to at least 128 bits of strength while not increasing any user facing complexity or footgun (128bits is the same strength as current TLS standards in your browser's resistance against offline save now brute force later decryption attacks, in gotify your token is never used to encrypt anything and only online attacks are on the table). Even if we used 1024 bits of token, in a security audit as long as you use a standard browser TLS stack to put in your credentials the actual strength is capped at 128 bits.

Of course you are welcome to bypass me and ask the owner for a second opinion, but I don't think this is a useful configuration knob to add.

[Pyvonix]

You misunderstood the security argument.
The discussion is not about Unicode support but about entropy and attack surface.

The Password Manager "Broken" Claim is a False Equivalence

Here's why:

1. URL-Safe Requirements: tokens passed as URL parameters (as in Gotify: https://push.example.de/message?token=<apptoken>) are constrained by RFC 3986 (URI Generic Syntax):
   • RFC 3986, Section 2.3: "unreserved characters" = A-Z a-z 0-9 - _ . ~
   • Special characters require percent-encoding, making them impractical
   • This is a protocol limitation, not a security choice
2. Password Manager Context is Different:
   • Password managers generate passwords for rate-limited and monitored authentication endpoints
   • OWASP Password Cheat Sheet explicitly states password requirements apply to "passwords used for interactive authentication"
3. The Real Issue: Attack Surface
   • Passwords: Protected by account lockout (OWASP recommends lockout after 5-10 attempts)
   • API Tokens: Can be attacked through distributed attempts across multiple endpoints
   • This is the critical difference

OWASP's 15-Character Recommendation is for Interactive Passwords:

• This applies to user-chosen passwords with complexity requirements
• Assumes rate-limiting and account lockout mechanisms
• Does NOT apply to machine-generated API tokens

Why 15 Characters is Inadequate for API Tokens:
Let's do the math with alphanumeric tokens (a-z, A-Z, 0-9 = 62 characters):

15 characters: 62^15 ≈ 2^89 ≈ 89 bits of entropy

Attack feasibility:

• Bitcoin network hashrate (as of 2024): ~450 EH/s (exahashes per second)
• This represents ~2^88 hashes per second
• A 15-character token could theoretically be brute-forced in days with specialized hardware

Have You Ever Seen a 15-Character API Token?
The shorter that I found is Gitlab Personal Access Token with 20 chars for ~119 bits.

The minimum that I suggest is token of 22 characters (131 bits), but most of the applications or frameworks have an option for this (Django, Ruby on Rails, etc...). I let the developer choosing what he want to do.

[eternal-flame-AD]

Have You Ever Seen a 15-Character API Token?

I do, stripe tokens are 16 char , admittedly it's "legacy" but they have not disabled it yet, IMO there stance is also we should migrate away but not an catastrophically small keyspace.

To give a professional reply as a bug hunter: I’ve maintained the perspective that >80 bits of entropy is mathematically sufficient to prevent online brute-force attacks, you mentioned the lack of rate limiting but no rate limiting does not automatically admit massively parallel cracking like SHA256 mining, due to the centralization of the server and the latency overhead of database lookups (SQLite/Postgres). The comparison to one other offering token length adjustment also doesn't override the goal of keeping Gotify 'Secure by Default' without unnecessary configuration complexity or imply an industry trend to add a knob for this.

I am open to re-evaluate my stance if you can provide PoC showing an attack against a live Gotify instance is feasible and you can explore a significant portion of the 85 bit keyspace by "distributed" attacks, but so far I'm not satisfied this is an "a Bitcoin farm can crack it" urgency like you implied it is.

Again , to acknowledge the lack of built-in rate limiting I propose bumping it to 128+ bits of strength to secure against even theoretical massively parallel attacks to match the brute force resistance of TLS handshakes, and anything beyond that is security theater as long as Gotify is an HTTPS application.

[Pyvonix]

I do, stripe tokens are 16 char , admittedly it's "legacy" but they have not disabled it yet, IMO there stance is also we should migrate away but not an catastrophically small keyspace.

Yes, but the difference is that Stripe token is for single use only:

You can’t store or use tokens more than once.

Whereas in the case of Gotify, once the token is generated it can be reused an unlimited number of times (until deleted, because I haven't seeing rotating or re-generating feature).

I'm also giving my opinion as a pentester. That's why I'm proposing a configurable option. Those who think 15 characters is enough can continue as is, and those who consider it insufficient can increase it. It's shift the decision to user based on their preference without impacting the Gotify default design.

I admit that "normally" the application doesn't protect ultra-confidential data, but since we don't know how users might use it (and their security sensitivities), it's best to take maximum precautions.

[eternal-flame-AD]

I will go ahead and put in a PR shortly bumping this to 128+ bits and propose closing this. I don't see this being very productive.

I gave you multiple opportunities to show the standards you have been alluding to or quantitative data from even a theoretical PoC (which should have been a very simple task, you can rig up an online password cracker, scale it up with a theoretical multiplier of NumUsers*BestCaseQps/LocalQps, and compute your chance of cracking one token within 1000 years) support your claim that the brute force resistance is weak, and all your response are either one off anecdotes (as your single project example with the token length knob) or categorically different comparisons (like Bitcoin mining).

[Pyvonix]

You dismissed established standards as "not applicable" while simultaneously demanding quantitative proof - that's not a consistent standard of evidence, since those standards exist precisely to codify that research.

I proposed a configuration option, not a vulnerability report. Reframing it as one to then publicly "debunk" it was a rhetorical move, not a technical one - especially when the practical case you used wasn't even consistent with the tokens used in Gotify: One-Time Token (OTT) vs Access Token.

And if the bar for raising a concern is "provide a working exploit first", then by that logic most security research is worthless. That's not a position anyone serious about security would actually defend. Following your logic, the deprecation of TLS 1.1 would have been unjustified, since no practical exploit was required to justify moving away from it.

I appreciate you moving forward with the PR, but it doesn't retroactively justify how this discussion was handled.

[eternal-flame-AD]

I proposed a configuration option, not a vulnerability report.

The bar for a configuration option is utility (and in Gotify's precedent in accepting feature requests, often substantial demand by more than one person). You also haven't met the bar for proving any viable utility which is additional security (which I have repeatedly pointed out is capped at 128 bits due to the hard dependency on TLS).