export SSH_AUTH_SOCK=~/.1password/agent.sock
We're not talking about social media PWs. ssh keys are not something to add risk to, eh.
I mean, 1Password already stores my credentials for the AWS console, Cloudflare, Netlify, GitHub, et al. I’m not sure adding my commit keys to that pile is dramatically increasing my exposure.
A place I worked before would store SSH keys for build machine base images (AWS AMIs) in 1Password. It wasn't worth the trouble trying to setup SSO since the machines rarely needed accessed and only by a handful of people to troubleshoot/manage them.
It's also common to share credentials when you're working with small SaaS that don't support multiple users or SSO. In addition, sometimes business integrations will have fixed credentials (like the SSH key to upload reports to a business partners SFTP server). People still need access to the keys for troubleshooting and debugging.
I don't think running a Userify daemon on the server is better than a private key in 1Password. At least with the private key approach, you can layer on network access restrictions (firewall rules or VPN). Userify would need to create an outbound connection to its control plane to manage keys
You swap "someone could steal my private key from SaaS" with "someone could upload an additional key to SaaS" which I guess just helps if you're reusing keys for unrelated systems?
I think Userify could potentially increase auditability by limiting key sharing but I don't see it actually increasing security assuming you can revoke/rotate shared keys.
If 1Password was ever compromised, the attacker could use my private key to log into any server that I have access to at any time forever, and in fact I won't even know! But, if Userify is compromised, then the attacker can only deploy their OWN public key but my private key is still safe.
This means that if 1Password is compromised, ALL private keys are compromised forever. If Userify is compromised, the compromise only lasts for as long as the attacker is actually logged in as you, and the prize for the attacker isn't getting your key (because it's public already), but only that they can deploy their own public key (and that produces a notification).
So, you're right in that you still have to place some degree of trust in a third party SaaS, but the simplicity of Userify's model and narrow scope which minimizes access to any secret material is very appealing because it's very easy to understand and audit. Userify is about as close to Zero Knowledge as you can get for an SSH connection.
And, if that's not enough, I can just buy my own Userify Express server and close it off on my own private Wireguard network or VPC and never let the outside world anywhere near it.
Right, this is only a problem if you don't have another form of key and don't have login auditing
With access to Userify, an attacker could upload a key to any server anywhere and still have access.
In the original post, I mentioned we already had an easy way to rotate keys via automation. We also had CloudTrail alerts and AWS Config alerts around port 22 security group rules (they were closed by default).
Sure Userify provides a lot of these things like key management and audit trails but my original point was it's silly to worry about storing private keys in SaaS when you use SaaS for other authentication and authorization anyway.
So again I'll ask: what case does 1PW make to deviate from those?
> The standard OpenSSH agent (ssh-agent) that comes preinstalled on most systems requires you to add keys to the agent (ssh-add) every time it launches. After you've added your keys, any process can use any SSH key that the OpenSSH agent is managing. It is then up to you to remove those keys when they're not needed anymore.
> The 1Password SSH agent uses a different approach. 1Password will ask for your consent before an SSH client can use your SSH key. Because of this, there's no concept of adding or removing keys like with the OpenSSH agent.
> When your turn on the SSH agent from the 1Password preferences or settings, every eligible key is automatically available to use for SSH, but your private keys will never be used without your consent.
Unknown vulnerabilities won't need your consent.
It's not like I'll ever need to manually interact with the socket, so keeping it out of the way would seem logical.
That's a general theme I see with all this SSO stuff. You have a few companies with root on the universe. Am I weird that this concerns me?
Unless their local client was compromised (not impossible - but if your local is compromised you're in trouble regardless), even if someone hacked them and stole their data, they would not have your clear-text info.
It's everyone's choice to make but I am personally OK with this security/convenience trade-off.. It's "good enough" for me - mostly because I trust them to know how to do this better than I could - if it means I can manage all my passwords in one place and access them from any device.
1Password also has useful (to me) quality-of-life features like integration with HaveIBeenPwned, it can also show you re-used passwords, and if you store credit cards or other info, it will also tell you when they're about to expire etc..
Plus you can store any arbitrary metadata with any record, so I even use it to store non-sensitive, but still private, info associated with logins, docs, ID, etc..
If the NSA asked for escrow or root everywhere people would freak out, yet central SSO mostly accomplishes the same thing and people are running toward it because convenience. Of course the same is true for surveillance. Private adtech does things with surveillance that would give people a heart attack if the NSA did it, and unlike the NSA they don't even pretend to be accountable to anyone we can elect.
(It's the same because governments can compel corporations under their jurisdiction and there isn't a ton a company can do about it.)
While some may find this debatable, I happen to think we just had a rather incompetent but still very concerning fascist coup attempt in the USA. Historically civilizations lose their collective minds periodically. Given that computing infrastructure is becoming the basis for virtually all communication and much of life, is it wise to centralize access control like this?
I feel like younger people of virtually all political stripes are just blithely unconcerned with this and assume "it can't happen here" or "that's something that happened back in the early 20th century but not anymore, we have totally solved stable government." I think that's incredibly naive.
It’s not ‘all my passwords stored in their database unencrypted’ easy to compromise, but it’s also not protection against a motivated agency with jurisdiction said service has to respect, and it’s also not solid protection against any state level actor if they really care/want to spend resources targeting someone.
That said, it’s all about threat assessment and trade offs. Especially for a business, what are the consequences if the NSA does x, or China does y?
For 99% of businesses? Nothing except some irritation if you find out. Same as with most things.
If someone is an activist going after those agencies/gov’ts? Probably quite severe consequences.
If I remember correctly, some of the fallout from the Chinese gov’t hacking Gmail was folks being ‘disappeared’, extended families being held hostage in China, etc.
For now. What happens when they eat enough of the market and displace enough other tools that the government says "Ok, now MitM the encryption." All they would need to do is push an update and re-encrypt the first time you unlock it. Now, this has always been true, but it's not on your servers and source repos yet, right now it's sandboxed.
How about internet outages? Service outages? Sure, local cache, but that cache expires.
I love PW managers, even cloud ones, but I wouldn't tie on directly to my local login and auth infrastructure to the exclusion of other local options.
I have autofill turned off because it can fill into nefarious forms if you're not careful. And I copy and paste from my pw manager into my terminal when required, because again I don't want it automatically being helpful when I want to be careful.
I hope no other apps are watching your clipboard.
I'll take that risk, given probability over possibility. But thank you for pointing out at least one scenario I hadn't thought of!
> How about internet outages? Service outages? Sure, local cache, but that cache expires.
Local cache doesn't expire, also the probability of me being offline for so long that this becomes a problem is close enough to zero for my comfort.
That said, I am guessing you might be responsible for some kind of critical (even just to you) infrastructure so we probably have different variables in our "is this for me" math..
One nice feature that 1pass has is that it will warn you when you attempt to autofill credentials for a url or mobile application that isn't listed as part of the credential.
e.g. 1pass "Logins" have a URI associated with them like "google.com" and if you visit a phishing site like "g00gle.com" and hit autofill 1pass says something along the lines of "Are you sure you want to fill these creds into g00gle.com?" and not fill until you approve. It's not foolproof, but certainly provides a nice barrier against fake login/phishing sites.
It does seem like a weirdly specific use-case. I wonder if they're trying to instead target people who need to use ssh keys but aren't comfortable generating or managing them on the command line. With Github requiring SSH keys for command-line pushes, this is probably a growing demographic.
Obviously it's not ideal to share SSH keys, but lots of teams will share the default EC2 keypair for example. This makes it much easier to pop that key into 1Pass, share it with the team, and easily get everyone into the box.
And, frankly, 1Password gui is much more user-friendly than other SSH agents. Personally, I'll stick with the tried and true OpenSSH agent, but I know many will be attracted by this feature.
Isn't this an anti-feature? The ability to revoke an SSH key specific to a stolen laptop from a server or your Github account seems like a benefit. Using the same SSH key on every machine is a downgrade.
On the other hand, the ability to manage access to shared keys is really nice.
You don't need to wait for people to "exit the company". Sharing private keys was wrong, invalidate those keys. If somebody else knows your private key it isn't private any more. Get this stuff right and rotating keys is unecessary, get it wrong and rotating keys can't help you.
On many OS's there are even more strict restrictions, where within a user a process can only dump the memory of processes that are its direct descendants.
It's not as easy as that if your private key is protected with a passphrase, which IMO ought to be the default option.
I am amused by the rationalization going on here, though... taking extra steps to secure your SSH private key because you might "npm install" something bad. There's nothing wrong with enhancing the security of your private keys through dongles or TPM chips but it's a lot better to attack the root of the problem: just don't run "npm install" (or similar untrusted code) in an environment that you don't want to get pwned.
My day job has me working with javascript packages but I don't have npm installed on my system, and never will. All of my work with npm happens inside docker containers. This offers many workflow advantages besides a layer of security.
So it is unreasonable to want to develop a JS app on the same machine I use for SSH?
Docker works I guess, but adds a lot of mental (and in the case of Docker for Mac, performance) overhead.
The issue I ran into was due to Docker for Desktop binding the local filesystem into the devcontainer running in a WSL2 VM.
The solution to this is to instead use a named volume in your docker-compose.yml and in your Dockerfile copy the files from your working directory into your devcontainer.
This provided an incredible improvement in the performance of using devcontainers in vscode. The one big drawback to this approach that I've run into is needing to make sure I commit and push my code to a git repo when I'm done working as there's not a copy stored on my local machine.
The main security benefit is here:
> 1Password will ask for your consent before an SSH client can use your SSH key. Because of this, there's no concept of adding or removing keys like with the OpenSSH agent.
This prevents SSH agent hijacking, requiring either a social engineering attack to bypass or a privesc.
This is the way.