gitea: Unable to Login using 2FA, Internal Server Error 500

Gitea version (or commit ref): Gitea version 1.1.1 built with: bindata, sqlite
Git version: 2.1.4
Operating system: Debian 8.8 Jessie x86_64
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: https://gist.github.com/eripa/1b1633a7c6225074e5911bde1edba4e7

Description

After running without issues for a long time Gitea suddenly started to fail on 2FA authentication. The regular password authentication works (verified using a non-2FA-enabled account). After entering the TOTP code, or the scratch code, I end up on a status page for internal server error 500.

The main clue that I can see is in the gitea.log file (see the log gist for more details) :

2017/06/01 07:27:20 [...routers/user/auth.go:212 TwoFactorPost()] [E] UserSignIn: illegal base64 data at input byte 0

Please get back to me if there is more information that I can provide in terms of debugging this issue.

Screenshots

screen shot 2017-06-01 at 9 32 51 am

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (7 by maintainers)

Most upvoted comments

I’ve now restored my ability to login, I did the following

Connect to the database (psql in my case)
Move away my 2FA configuration UPDATE two_factor SET uid='2' WHERE id='1';
Stop the service
Update the SECRET_KEY in my app.ini
Start the service
Login
Generate a new 2FA token
Verify that the new encoded and encrypted value in the two_factor table is decryptable using the previously extracted code snippet. (it worked and I got the same secret key from when setting up the 2FA token)
Remove the corrupt 2FA token: DELETE FROM two_factor WHERE id='1';

The question is why this would happen in the first place?

EDIT: I figured out that the Salt formula that I use had an unintended behavior which caused the SECRET_KEY to be updated. So I could probably have solved this by restoring the old secret key.

eripa on Jun 2, 2017

@bellinom In both my case and I believe uncled1023’s case it was caused by an invalid or changed secret being used since generating the 2FA code. Make sure to verify that you haven’t mistakenly changed the gitea secret and try again.

If you don’t have too many user relying on your service, you can also regenerate the 2FA code. Look at my comment above for some pointers.

eripa on Sep 1, 2017