search

Graylog2 / graylog2-server

Free and open log management
https://www.graylog.org
Other
7.36k stars 1.06k forks source link

As an Admin User Access Tokens of other users can be viewed in Plain #9124

Open HenryTheSir opened 4 years ago

HenryTheSir commented 4 years ago

Dear Graylog Team,

we happiliy read the news about Graylog 3.3 with encrypted tokens https://docs.graylog.org/en/3.3/pages/upgrade/graylog-3.3.html#api-access-token-encryption . Our expection of this news, was that token are now handled similar to passwords. Unfortunely as an Admin one can see tokens of other users in Plaintext.

Expected Behavior

Tokens are hashed and salted in MongoDB and can not be seen anywhere in plain after creation.

Current Behavior

Tokens are visible in Plaintext although they give the same access as the users password.

Possible Solution

Handle tokens as passwords and give only during creation of token the possiblity to read the token in plaintext.

Ideally a User gets an E-Mail if someone creates a token in his usercontext, so he can control if the creation is wanted, additionally it would be a nice feature if tokens could be bound only to specific functions in a usercontext e.g. execution of a specific search.

Steps to Reproduce (for bugs)

  1. Assign/create Token to/as User
  2. Admin and User can see the token in Plaintext

Context

Tokens should be treated as passwords and should have the same security regulations (salt and hash)

Your Environment

edmundoa commented 3 years ago

I think this was fixed in #9746, please reopen if needed. Thank you!

HenryTheSir commented 3 years ago

Hi @edmundoa ,

I am not sure as this should be closed. The 'GUI Way' is now closed but the tokens are not hashed and salted in Database (if I did not made any mistake reviewing the linked issue)

In my opinion a follow up task would be in a upcoming release to hash and salt new tokens as if they were passwords and an migration step which 1.) Decrypts current Token (as they are currently ony crypted) 2.) Hash+Salt Token 3.) Save in DB as new value.

As this would be a breaking change one can not downgrade graylog version without restoring mongodb backup but this was in the relese for 3.3 the same for token encryption.

best regards

thll commented 3 years ago

Hi @HenryTheSir ,

it's true that the tokens are not hashed but only encrypted. This offers some means of protection by preventing the extraction of plaintext tokens if someone gains access to MongoDB alone. For decryption, additional access to the encryption key in graylog.conf is required.

Is the current solution posing a security concern for you?

Changing this to a salt+hash approach is unfortunately not as simple as salting, hashing and re-saving the token. When a token-based API request is authenticated, the Graylog server is presented a header of the form <plaintext-token>:token. It then needs to perform a lookup in MongoDB to find the token and the associated user. We are currently doing this by encrypting the incoming token and doing a simple index lookup for the encrypted value.

If the token was however hashed with an individual salt in MongoDB, we would need some additional information like a username or a token ID to look up the candidate tokens. This would mean a breaking change for our API.

We could investigate if storing the hashed token without a salt would be secure enough to do. After all, we are aiming to protect random values and not user-generated passwords. If so, this would probably be a solution for the lookup problem.

HenryTheSir commented 3 years ago

Hi @thll , as in the opener of this issue: In my opinion the tokens should be handled as if they are a password, as they give the same access but are probably less frequently changed. Are the password for local users only encrypted as well in the mongodb? (I doubt it)

I would understand the described problem if the salt for every token would be different, but the implementation in the moment for hashing and salting passwords for local users uses for all passwords the same salt (password_secret of the graylog.conf). So one could query for the hashed+salted value in mongodb. Server takes incoming 'username' which is the token, salts and hashes the value and than looks up the value in mongodb. This brings just the 'breaking' change that with access to mongodb and graylog.conf one can not restore the actual token, as its handled with same privacy concerns as a password.

best regards

thll commented 3 years ago

Are the password for local users only encrypted as well in the mongodb? (I doubt it)

No, they are hashed.

I would understand the described problem if the salt for every token would be different, but the implementation in the moment for hashing and salting passwords for local users uses for all passwords the same salt (password_secret of the graylog.conf).

Actually, each user's password is salted with a unique salt. The default algorithm we are using is bcrypt. Unless I'm mistaken, password_secret is not used for peppering user passwords. The name of that config parameter is a bit misleading and probably has historic reasons.

So one could query for the hashed+salted value in mongodb. Server takes incoming 'username' which is the token, salts and hashes the value and than looks up the value in mongodb. This brings just the 'breaking' change that with access to mongodb and graylog.conf one can not restore the actual token, as its handled with same privacy concerns as a password.

As I mentioned, hashing the tokens without a salt might be an option. Because unlike user-chosen passwords, they are less susceptible to rainbow table attacks. Using password_secret from graylog.conf as a system-wide pepper on top of that is probably not a bad idea either.

So I think this is a solution worth to further pursue. I'm reopening the issue.