Reduce risk of oauth token compromise by storing tokens in $XDG_RUNTIME_DIR

[nickweeds2]

Feature description

On Desktop Linux Git Credential Manager stores Azure DevOps oauth tokens encrypted in Gnome Keyring, but on headless Linux it stores them unencrypted and outputs a warning.

It is understandable that GCM stores oauth tokens unencrypted on headless Linux because headless Linux does not provide a standardized credential store. However, headless Linux is used much than desktop Linux, and storing oauth tokens unencrypted on disk remains a security concern.

What can be done ?

One simple improvement would be to store oauth tokens under directory $XDG_RUNTIME_DIR when this exists.

Many Linux distributions use systemd and create a user session when the user logs in or starts an SSH session. When the user session is first started the system creates a tmpfs runtime filesystem and sets $XDG_RUNTIME_DIR to point to it. When the user's last session ends the system deletes the user's runtime filesystem. This is observed on both Ubuntu and Mariner (with systemd).

Storing oauth tokens under $XDG_RUNTIME_DIR would have two immediate benefits:

1. The runtime filesystem uses tmpfs so oauth tokens stored in $XDG_RUNTIME_DIR are not stored on disk.
2. The runtime filesystem is deleted when the user sessions terminate, so oauth tokens stored in $XDG_RUNTIME_DIR are deleted at the end of the user session.

These two benefits protect the oauth tokens almost as well as Gnome Keyring. Gnome Keyring does not protect against people who have access to the user session (see Gnome Keyring Security Philosophy), so the main difference is probably not encryption but Gnome Keyring having better protection against memory being swapped to disk. (I don't think Windows DPAPI protects encrypted data from people who have access to the user session either, so Windows might not be much better.)

Side effects of the proposed change:

• Users who exit SSH sessions then start a new SSH session need to re-authenticate.
• Processes left running after the SSH session ends (e.g. using nohup or tmux) lose access to oauth tokens.

Since GCM is intended for interactive use these side effects are probably acceptable, but if not we could allow users to override this behavior and store oauth tokens under $HOME rather than $XDG_RUNTIME_DIR (at the cost of persistent oauth tokens on disk).

Proposed Solution

When storing unencrypted oauth tokens on Linux, check whether $XDG_RUNTIME_DIR is set and refers to a valid directory, and if so store oauth tokens under $XDG_RUNTIME_DIR rather than $HOME.

[mjcheetham]

Hello @nickweeds2, thanks for opening this issue with all these details.

On Desktop Linux Git Credential Manager stores Azure DevOps oauth tokens encrypted in Gnome Keyring, but on headless Linux it stores them unencrypted and outputs a warning.

Git Credential Manager's own storage system on Linux comes un-configured out of the box, and you must select a storage option using credential.credentialStore or GCM_CREDENTIAL_STORE.

However, you are correct when referring to the MSAL (Microsoft Authentication Library) token cache, which on Linux only uses either the Secret Service store or a plaintext fallback.

I can see that you've created some issues in the MSAL repos about this, and got a reply in the MSAL Python repo that it's the application's choice where to store the cache.

It is correct that the applications set the location for this fallback cache file, however GCM's locations are being kept in step with other Microsoft developer tools (such as Azure PowerShell) that use MSAL and the token cache. We implemented this on the advice of the MSAL team at the time.

@rayluo + @bgavrilMS would be able to update on what the latest advice for the token cache on Linux?

[bgavrilMS]

Hi @mjcheetham - @rayluo and myself focus only on confidential client scenarios nowadays. For public client scenarios, including token caching for CLI / desktop apps on Linux, @iulico-1 @ashok672 can help.

[mjcheetham]

Hi @mjcheetham - @rayluo and myself focus only on confidential client scenarios nowadays.

Hi Bogdan! Thanks for the reply and redirect to the correct people. I was aware you had moved to other focuses but didn't know who else to reach out to on GitHub.

[nickweeds2]

@mjcheetham
Thanks for looking at this.
I closed the issues I raised against the MSAL libraries because the token cache is implemented by the application not the MSAL library.
I think the question is whether we can (a) improve GCM security (b) update the MSAL security guidance accordingly.
As it stands GCM prints out scary-looking warnings on headless Linux, and there's no good way for users to address this. I think that in itself says that improvements are wanted (otherwise let's remove the scary warnings). The suggestion made here is a relatively easy to implement, easy for users, and would reduce the risk of oauth token compromise.

[nickweeds2]

Further observation:
The GCM oauth tokens appear to be pretty long-lived - I don't seem to need to authenticate every day as I do with AZ CLI.
If so that has 2 impacts:

• the seriousness of compromised GCM oauth tokens is greater - it's less likely that tokens obtained by an attacker will have expired, and the attacker will be able to use the token for longer.
• deleting tokens at the end of the user session will be much more visible to users