Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security issue: scratch tokens are plaintext in the database #3389

Closed
2 of 7 tasks
ghost opened this issue Jan 17, 2018 · 6 comments · Fixed by #4331
Closed
2 of 7 tasks

Security issue: scratch tokens are plaintext in the database #3389

ghost opened this issue Jan 17, 2018 · 6 comments · Fixed by #4331
Labels
topic/security Something leaks user information or is otherwise vulnerable. Should be fixed! type/enhancement An improvement of existing functionality
Milestone

Comments

@ghost
Copy link

ghost commented Jan 17, 2018

  • Gitea version (or commit ref): 1.3.1
  • Git version: 2.15.1
  • Operating system: FreeBSD 11 x64
  • 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:

Description

User scratch tokens are stored in plain text in the database. These should be encrypted because it will allow anyone with database access to grab the token and bypass 2 factor authentication. While not likely still should be considered an issue. I would also suggest in allowing for more than one token which would all be stored encrypted in some fashion in the database.

@lafriks lafriks added type/enhancement An improvement of existing functionality topic/security Something leaks user information or is otherwise vulnerable. Should be fixed! labels Jan 18, 2018
@ghost
Copy link
Author

ghost commented Apr 12, 2018

Any progress on resolving this?

@lunny
Copy link
Member

lunny commented Apr 12, 2018

Any suggest to resolve this problem?

@ghost
Copy link
Author

ghost commented Apr 22, 2018

I think for this you could store only the hashed or bcrypted value and handle it like a password. If the user loses said token then they just cannot recover their account, similar to how it works with GitHub if you lose your 2FA token.

@TangentFoxy
Copy link

Another +1 for bcrypt as a valid, secure, and tuneable implementation for hashing. ^^

@daviian
Copy link
Member

daviian commented May 5, 2018

@lunny @Guard13007 @cezar97 I suggest using the same KDF as we do for passwords. So PBKDF2 with SHA256. So we can almost copy/paste the hashing from user creation.

@TangentFoxy
Copy link

@daviian That is also a completely valid option. And if it allows for more code re-use, probably a good idea.

@lafriks lafriks added this to the 1.6.0 milestone Jul 27, 2018
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic/security Something leaks user information or is otherwise vulnerable. Should be fixed! type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants