I’m a bit concerned about how CLI login and session maintenance currently works. The docs say not to store the session token on disk due to unencrypted disk concerns. In many ways, storing it in the env has similar issues, as on a multi-user/tenant system you can’t really be sure that the person who has read access to that should. Also, accidental exposure of env
is super easy. For more reasons you shouldn’t, I found this Why you shouldn't use ENV variables for secret data googling returns plenty of results, though. I would argue, in the current state of things, this is a reasonably serious security vulnerability in shared environments.
One solution to the env issue is to store the key in /run on Linux systems. I’m not certain if OS X and Windows offer any similar file systems that are automatically a ramdisk. There are places that a user has write access to create their own files that are readable only by them.
The is to simply store the session code in the system’s keyring. This has a problem of, what if you’re using Bitwarden as the system’s keyring? Or there isn’t one.
I’m not entirely certain how keyring’s unlock and stay unlocked, but I know that ssh, and GPG, both have agent daemon’s. That may mean that Bitwarden might also need to provide a bw-agent program that maintains the unlocked state. This in fact might be the best solution of all, and perhaps the desktop client could use it as well, so that both integrate into the same thing. This is probably the best solution, but I believe can, should also integrate with ASKPASS.
As another comment, passing the argument via an option is also insecure.
Further per security issue. Yes I could have reported this privately, but this is a very public API, certainly not a zero-day.
https://cwe.mitre.org/data/definitions/526.html
https://cwe.mitre.org/data/definitions/214.html