Vikunja: Plaintext storage of password-reset/email-confirm tokens in database enables account takeover on DB read access

### Summary Vikunja stores password-reset, email-confirmation, and account-deletion tokens in the `user_tokens` table in **plaintext**. If an attacker gains read access to the database through a backup leak, misconfigured storage, or SQL-level exposure, they can immediately use pending tokens to take over user accounts without knowing passwords. ### Details `pkg/user/token.go` — `genToken()` stores the raw random string directly: ```go func genToken(u *User, kind TokenKind) (*Token, error) { tokenStr, err := utils.CryptoRandomString(tokenSize) ... return &Token{ UserID: u.ID, Kind: kind, Token: tokenStr, // stored as-is, no hashing }, nil } ``` Lookup also uses plaintext equality: ```go func getToken(s *xorm.Session, token string, kind TokenKind) (t *Token, err error) { has, err := s.Where("kind = ? AND token = ?", kind, token).Get(t) } ``` Affected token types: - `TokenPasswordReset` (`pkg/user/user_password_reset.go:120`) - `TokenEmailConfirm` (`pkg/user/user_create.go:101`, `pkg/user/update_email.go:88`) - `TokenAccountDeletion` (`pkg/user/delete.go:102`) Note: CalDAV tokens correctly use `generateHashedToken` with bcrypt — the same protection is absent for the above types. ### PoC ```sql -- Attacker with DB read dumps all pending password-reset tokens: SELECT u.email, t.token FROM user_tokens t JOIN users u ON u.id = t.user_id WHERE t.kind = 1; -- Then takes over any account: curl -X POST https://vikunja.example.com/api/v1/user/password/reset \ -H 'Content-Type: application/json' \ -d '{"token": "<plaintext_from_db>", "new_password": "AttackerPass1!"}' ``` ### Impact Any read access to the database (leaked backup, cloud misconfiguration, secondary SQLi) allows an attacker to take over every user account with a pending reset token within the 24-hour token lifetime. Full account takeover including admin accounts. ### Fix Replace `genToken` with `generateHashedToken` for `TokenPasswordReset`, `TokenEmailConfirm`, and `TokenAccountDeletion`. Update the corresponding lookup to use bcrypt comparison (`bcrypt.CompareHashAndPassword`) rather than direct SQL equality, mirroring the existing CalDAV token implementation in the same file. If possible, please apply for a CVE number when posting.