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

[eripa]

• 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]):
  
  
  
  • [x] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] 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

[lunny]

Tested on https://try.gitea.io and didn't reproduce this. And the gist cannot give more detail.

[pgaskin]

Can we see the two factor secret inside the database? I think that's corrupt.

[eripa]

@geek1011 Sure! Is this the one? Looks like a base64 encoded random string.

Edit: FYI the scratch_token does not work (same behavior).

gitea=> select * from two_factor;
 id | uid |                          secret                          | scratch_token | created_unix | updated_unix
----+-----+----------------------------------------------------------+---------------+--------------+--------------
  1 |   1 | 1TgjXjPabmY9q2WNRcLj084LZjpZNh1wbF4XOz11lH8yF9ZQekZvAg== | LeHfzlRJ      |   1489266134 |            0

[pgaskin]

@eripa it needs to be decoded with aes and the secret key in the config file.

[eripa]

@geek1011 any pointers on how to do that?

[pgaskin]

Have a look at the code for twofa.

[eripa]

I've extracted the functions required to perform the decrypt and used my setting.SecretKey and the stored secret (above).

I'm getting the same behavior (illegal base64 data at input byte 0), and looking at the decrypted string it doesn't seem to be a Base64 encoded string anymore.

2017/06/02 07:57:01 Encryption Key: [224 57 13 76 58 236 90 197 81 132 150 250 213 142 213 246]
2017/06/02 07:57:01 Key: [224 57 13 76 58 236 90 197 81 132 150 250 213 142 213 246]
2017/06/02 07:57:01 Block: &{aesCipherAsm:{aesCipher:{enc:[1275935200 3311070266 4204168273 4141190869 1330592504 2316687042 1887654547 2253839430 353078140 2669567422 4020047661 1774965611 1794282526 4125936032 443664013 1941575142 3833421903 294758895 199257954 2019195524 3150044805 2857400170 2712672264 3656016524 3757332751 1973694053 3558094445 234771681 656663151 1384631306 2257844839 2339221126 1662967307 832115201 3070945382 1013401312 2197117770 3010218315 73834797 939648973 1072834536 2359193251 2298007438 2969118787] dec:[1072834536 2359193251 2298007438 2969118787 1001008857 4063930812 726288838 333834767 3996063857 3381692261 3648053370 951034825 598601704 666869524 283141919 3789505459 4074475226 68317436 929036299 4047447212 2047630602 4140432934 860719351 3328236711 4276948392 2361762604 3313792721 4113388624 3586526990 1915268740 1229051389 816390785 1762672302 2817433994 996768633 2045310844 2100139781 3472793380 2626149107 1115786245 1275935200 3311070266 4204168273 4141190869]}}}
2017/06/02 07:57:01 Text: [45 15 123 88 196 201 15 55 162 8 244 179 2 118 60 189 214 94 111 14 161 225 214 87]
2017/06/02 07:57:01 Text (string): -{Xv<oW
2017/06/02 07:57:01 illegal base64 data at input byte 0

[eripa]

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.

[uncled1023]

I'm having this same issue. The reason behind mine is due to me having another application generating the encrypted secret and then saving it to the Gitea DB. I'm still trying to work through it, and will report back when I can get it working.

[uncled1023]

Ok, an update. My app (c#) that was generating it needed to process it with a feedback size of 128 instead of the default 8. This required me padding the input text for encryption/decryption, then remove the padding after processing it. Seems the 'GO' implementation is streaming it, which does not require padding.

[ghost]

I am experiencing this same issue, using Gitea via Cloudron.

Sep 01 18:24:40 2017/09/01 18:24:40 [...routers/user/auth.go:212 TwoFactorPost()] [E] UserSignIn: illegal base64 data at input byte 1
Sep 01 18:24:40 2017/09/01 18:24:40 [D] Template: status/500
Sep 01 18:24:40 [Macaron] 2017-09-01 18:24:40: Completed /user/two_factor 500 Internal Server Error in 2.890691ms 

Any chance this gets fixed?
Thanks.

[eripa]

@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.

[ghost]

I noticed this using the Bitwarden Firefox extension TOTP feature. At least one of the times I moved the 2FA between sites, that may have something to do with it. I'll make sure I don't move it and see if it happens again.

[gramakri]

@eripa Thanks for the hint! That was indeed the problem with the Cloudron package.

[eripa]

@gramakri happy to help! :)

[noe-spi]

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.

THX to @eripa - just wanted to mention that in the end my problem was table "two_factor".
It had no entry/data at all.
So I just inserted the SECRET_KEY from app.ini into two_factor table with an uid of 2 - that worked out.