Here at Ur Solutions, we have long encouraged and facilitated the use of password managers to securely store and share passwords, codes, API tokens and other secrets. Until the New Year, our preferred service was LastPass, but in light of new information surrounding the extent of the data breach they experienced this fall, the decision was made to switch to 1Password. Our CTO Ola has posted a comment as to why this swap was necessary.
In the context of the release of version 8 of its software in 2022, 1Password has rolled out a number of features directly aimed at developers. I've picked out three that I particularly like.
SSH Agent
When I mention the word “SSH keys”, most people probably think of the obscure file one once created so that they wouldn't have to enter their password every time they push something to GitHub. Now it should be said: There is nothing fundamentally wrong with SSH keys as it works today, given that one uses a secure enough cryptosystem. The potential pitfall is that one is happy to reuse the same key across different services — in the same vein as reusing passwords when one does not have a password manager. If you have several machines, you will also have to create your own keys for each of them, as well as maintain them.
The good news is that 1Password has support for both generating and storing SSH keys, as well as a separate SSH agent to feed in the correct key to various services on the machine that use SSH -- git, for example. This means that you can go from one key per machine, to one key per service. These keys can further be synchronized across all devices on which you have 1Password installed. In the event that one of the keys is compromised, it is quickly done to replace it on this one service, without having to make it an all-day operation to change everything.
The function itself is easy to use: just open the settings and turn on “Use the SSH agent”. If you have biometric unlock enabled, you will receive a request every time a key is attempted. If you prefer a mix of local keys and keys stored in 1Password, it is quite possible to achieve this by adding one or more exceptions to your local SSH configuration.
Sign git commits
SSH keys can be used for more than just authenticating network connections, such as signing git commits. Basically git doesn't verify the author's identity, which can be (humorously) exploited in git-blame-someone-else. This, on the other hand, is a real vulnerability that can be used to trick in malicious code: Raise your hand those who remember to ask their colleagues if they were the ones who indeed wrote the code you're going through.
Fortunately, in the same way as with the SSH agent, one can configure git to sign commits using keys from 1Password. If you put this key in the user settings on GitHub, for example, you will get a nice green “Verified” sign on all commits you push up. checkout this video for how easily it can be configured!
Provisioning of .env files
For an average developer, checking in the .env file in git must be experienced as breaking one of the seven deadly sins. One regularly hears horror examples where secrets leach out because someone had forgotten to add the file to .gitignore, and uploaded it by mistake. No, the correct the way is of course to create a separate file, without the secret values, which can be safely checked in. When new developers are going to set up the project just ask them to extract the values from the password manager — optionally share their own .env file.
Since one already has all the secrets of 1Password, wouldn't it be better to have their application retrieve them directly from there? It's actually possible using 1Password's command-line tool. Behind the scenes, each field one enters in the password manager is assigned a separate, path-like ID. We can later use this to commission the real, secret value before the application is to run -- even in production. Thus one can safely both check in the .env file in git as well as push it up, yet how sinful it feels!
Let's say we have an application that is going to make use of our AWS account. Then a typical .env file would look like this:
To run the application locally, one uses the command-line utility to commission all environment variables before starting the application in the usual way:
When the application is to be deployed to production, some additional setup is required to ensure secure provisioning of external services. A recipe for how to do this can be found at 1Password's website.
More Possibilities
These three functions are the ones I immediately saw the usefulness of, and have adopted in my daily work. On the other hand, there is more functionality than this, and in particular the command line tool, combined with various SDKs, allows one to develop applications that use 1Password as a secure cloud storage platform. Then you suddenly have a full-fledged alternative to a “keyvault” service from the big cloud solutions.
