GHSA-456h-ww26-f758: Go/github.com/tinyauthapp/tinyauth vulnerability
Summary It's possible to enumerate users through a timing oracle. In other words: I can easily check if a username exists or not by observing the timing differences between logins.
PoC Setup a tinyauth server with a local user. It can be over the network.
Try to log in with the local user, using an incorrect password: there is a noticeable delay. You know that the user exists.
Now try to log in with a username that does not exist, using an incorrect password: it will complete almost immediately. You know that the user does not exist.
Expected vs actual behavior
Login attempts should take roughly the same amount of time when the user exists vs when the user does not exist. Right now, nonexistent user attempts are way faster, meaning if your login attempt is slow, then the username exists for sure.
Details
Existing usernames will take an extra ~50 milliseconds to respond to login attempts, while non-existing usernames will take only ~50 microseconds (1000x less time) to return an incorrect password response.
Even taking network traffic into consideration, it is trivial to check whether a local user exists or not.
=== Existing user, wrong password === #1: 50.52ms #2: 46.24ms #3: 43.57ms
=== Nonexistent user === #1: 43.03µs #2: 48.45µs #3: 59.33µs
Suggested fix
This can be solved by checking a dummy password hash when a user is not found before returning a query, this will mimic the exact same delay irrelevant of hardware capabilities.
Potential patch: From ca102773e0303f6025480efb26db379e3570a350 Mon Sep 17 00:00:00 2001 From: Disyer <daniel@tohka.us> Date: Tue, 14 Jul 2026 12:35:07 +0300 Subject: [PATCH] fix: prevent user enumeration by means of timing attack
--- internal/controller/usercontroller.go | 1 + internal/middleware/contextmiddleware.go | 1 + internal/service/authservice.go | 10 ++++++++++ 3 files changed, 12 insertions(+)
diff --git a/internal/controller/usercontroller.go b/internal/controller/usercontroller.go index ae6c23b..2ecc996 100644 --- a/internal/controller/usercontroller.go +++ b/internal/controller/usercontroller.go @@ -90,6 +90,7 @@ func (controller UserController) loginHandler(c gin.Context) { if err != nil { if errors.Is(err, service.ErrUserNotFound) { + controller.auth.DummyCheckPassword(req.Password) controller.log.App.Warn().Str("username", req.Username).Msg("User not found during login attempt") controller.auth.RecordLoginAttempt(req.Username, false) controller.log.AuditLoginFailure(req.Username, "unknown", c.ClientIP(), "user not found") diff --git a/internal/middleware/contextmiddleware.go b/internal/middleware/contextmiddleware.go index f49c85a..f70c9e7 100644 --- a/internal/middleware/contextmiddleware.go +++ b/internal/middleware/contextmiddleware.go @@ -244,6 +244,7 @@ func (m ContextMiddleware) basicAuth(username string, password string) (model. search, err := m.auth.SearchUser(username) if err != nil { + m.auth.DummyCheckPassword(password) return nil, nil, fmt.Errorf("error searching for user: %w", err) } diff --git a/internal/service/authservice.go b/internal/service/authservice.go index eeb5c8e..9cbc105 100644 --- a/internal/service/authservice.go +++ b/internal/service/authservice.go @@ -28,6 +28,10 @@ import ( const MaxOAuthPendingSessions = 256 const OAuthCleanupCount = 16 +// a dummy hash to check when a user is not found, to prevent user enumeration +// hardcoded to prevent having to generate a hash on every startup +const dummyHash = "$2a$10$iFQ6./j2a.UShYQOzWh4vOlnoze5DmHI3tRY3WU4YMj3zwp.t3TnO" + var ( ErrUserNotFound = errors.New("user not found") ) @@ -204,6 +208,12 @@ func (auth AuthService) CheckUserPassword(search model.UserSearch, password str return errors.New("user authentication failed") } +func (auth AuthService) DummyCheckPassword(password string) { + // When a user is not found, we still want to perform a password check to prevent + // timing attacks that could reveal whether a user exists or not + bcrypt.CompareHashAndPassword([]byte(dummyHash), []byte(password)) +} + func (auth AuthService) GetLocalUser(username string) model.LocalUser { if auth.runtime.LocalUsers == nil { return nil -- 2.55.0
After testing the proposed fix, there is no discernible timing difference:
=== Existing user, wrong password === #1: 43.23ms #2: 43.26ms #3: 42.57ms
=== Nonexistent user === #1: 42.45ms #2: 42.11ms #3: 47.71ms
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/tinyauthapp/tinyauthto a version that resolves this vulnerability.Fixed in 1.0.1-0.20260714134959-c22925c2fba9 - Compensating control
When a user is not found during authentication, perform a bcrypt password-hash comparison against a hardcoded dummy hash before returning the authentication failure, so existing and nonexistent usernames incur the same password-check delay.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Tinyauth deployments with local users are exposed. The timing difference can be measured over the network, so an attacker does not need to be on the same host.
What does an attacker need to exploit it?
An attacker needs to submit login attempts for usernames they want to test. They can use an incorrect password and infer whether a local username exists from the response time.
How can I tell whether my deployment is affected?
Compare failed login timings for a known local username and for a nonexistent username. The reported behavior is roughly 50 milliseconds for an existing username with a wrong password versus roughly 50 microseconds for a nonexistent username.