Application Personal Access Tokens are stored as plaintext in the database. Easy fix maybe.

[BranndonWork]

• Gitea version (or commit ref): 1.3.0
• Git version: 2.7.4
• Operating system: osx
• Database (use [x]):
  • PostgreSQL
  • [ x] MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • [ x] Not relevant
• Log gist:

Description

After creating an application token, I checked the database, and the token is stored in plaintext in the database! This is bad because anyone that may gain access to the database would have access to all tokens.

Suggested fix is just to hash the token before storing it locally, for example, the token you give the user is 30ab72898b83c8549e510ee36cde7c7d7be01d97 becomes A6DCC734FFB0E5A1E871E10C1B2A48CA60E9104F8F61FD41BD1DC01789062D81 when ran through a sha256 hash.

This way you can take what the user provides turing an authorized token use, and run the value they give you through sha256, and validate that the result matches what's in your database.

...

Screenshots

[adelowo]

@lunny can I work on this ? What key should be used for creating the hash ?

[jonasfranz]

This would be breaking since you can get the token via the API

[lunny]

@adelowo Yes, please do it and send a pull request. The filed is https://github.com/go-gitea/gitea/blob/master/models/token.go#L21, as @BranndonWork 's suggest we could use a hash256, I don't think we need a key to do that.
@JonasFranzDEV this will not break anything if @adelowo add the migration of the field Sha1 on https://github.com/go-gitea/gitea/blob/master/models/migrations/migrations.go

[jonasfranz]

@lunny I think that you're wrong since

curl -X GET "https://try.gitea.io/api/v1/users/JonasFranzDEV/tokens" -H  "accept: application/json" -H  "authorization: Basic CENSORED"

Will return my access token:

[{"name":"api","sha1":"31df5baaf69024d08a884261e180de00b3983bfa"}]

I've created the token here:

So If you only save the SHA256 hash of the access token you will have no way of providing the access token via the api. This would be breaking.

[adelowo]

So we need some form of hashing key so as to keep default behavior ?

[jonasfranz]

@adelowo I think it is not possible the hash the application keys securely if we want to expose those via the mentioned API.

[BranndonWork]

Correct, while submitting this issue, I wasn't aware that we could pull the key via API.

What's the need for providing the key again after the fact? Aren't most tokens/secrets provided by vendors only given out once, and not available for retrieval if lost?

In my opinion, this grants full account access, and should be treated no differently than a username/password combination.

If you DO need to retrieve the actual token later, while securely storing it in the database, you can encrypt it using the users salt (which already exists in the DB) and a custom system level salt, which never changes, and is created in the filesystem during initial install. Then you can decrypt the token with the standard basic authentication method of user/password. Would that work?

[lunny]

I agreed with @BranndonWork we should remove the API even it will break the compatible but it's more secure. The token only be returned to user once when created via UI or API.

[jonasfranz]

@BranndonWork Decrypting a user token with the username password combination would not work since you could also retrieve the token by an application token. I think that there's no way to not remove this possiblity of retrieving the token via API.