> 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.
I have pretty high confidence in 1password's security, because it's a very attractive target for both security researchers and malicious actors. I just hope they have a decent and fair bug bounty program.
Not really. What is the case for not using well vetted best practices and replacing those with an unvetted proprietary solution? What problems does 1PW solve that necessitates taking on such risk?
We're not talking about social media PWs. ssh keys are not something to add risk to, eh.
1Password is used at a lot of medium-small businesses where employees have shared credentials (usually these smaller businesses don't have built-out identity management systems to cover everything with SSO).
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.
Would that be a good use case for something like Userify, so that there's no need to store any keys in a base image/AMI where they can't be easily updated/removed? Then you don't need to give your private keys to a third party, either.
We didn't store keys in the AMI. We added the public half to EC2 then attached that key to the launch configuration where it gets added to the VMs authorized_keys on startup.
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
Sure but it's still reaching out to a cloud service for auth info.
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.
Well, rather than have my private key stored in a remote repository, I upload only my public key to Userify, and that shim thing automatically distributes my public key to the authorized_keys file in my homedir, exactly in the same way as if I was doing it by hand.
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.
>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!
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.
> 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.
The data that 1Password stores on their end is encrypted with your personal passphrase. So they can't see it even if they want to.
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..
> The data that 1Password stores on their end is encrypted with your personal passphrase.
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.
> What happens when they eat enough of the market and displace enough other tools that the government says "Ok, now MitM the encryption."
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..
> I have autofill turned off because it can fill into nefarious forms if you're not careful.
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.
I am more concerned with the long term social and political implications of giving a small number of corporations elevated privileges (or the ability to obtain them easily) on everything in the world.
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.
I'd suggest taking another look at how 1Password (or any other secrets management tool) deals with secret data. "the ability to obtain them easily" is not the case.
All of these managers that allow automatic updates or run off some cloud loaded executable (which is all of them essentially) can re-encrypt all your data to another arbitrary key on next unlock with some code changes. Those code changes could be pushed/loaded for specific customers only pretty easily.
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.
The intention of the user is to give them encrypted blobs of credentials that are useless to them. Those blobs are only decrypted locally. That distinguishes password managers from traditional SSO solutions where credentials are sent to a centralized system that grants authorization.
Where is the ssh-agent reading your private key from? If from ~/.ssh/, you're just one "npm install" away from the key being exfiltrated by a compromised package. If the private key is on your Yubikey, you're already good. The 1password agent will provide a good hardwareless method of keeping your private keys off the local filesystem, and it'll sync between your devices too.
> you're just one "npm install" away from the key being exfiltrated
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.
Just because I happened to be dealing with this today (on Windows with WSL2 but same rules apply) I'll make a comment.
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.
Your ~/.ssh/ private key is not readable by normal users since it's encrypted, so that isn't going to work.
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.
A process can not dump the memory of another process if those processes are executing under different users, or the process performing the dump is root.
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.
they would have access to the socket not the key, sure a very elaborated attack can probably figure out how to exfiltrate a lot of things (since they have already compromised the host) but for most, if they don't see things in ~/.ssh they would just go away and figure out another host to exfiltrate keys
Other commenters have mentioned sync, which is absolutely nice, but one other advantage is shared keys.
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.
Point of order: afaict currently keys can be put in a shared vault but only keys in a private vault can be accessed by the agent. So the workflow would be everyone copies the shared keys into their private vault.
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.
But why are you "rotating" keys? Most of the reasons people give involve unnecessary exposure of the private key material, which is exactly what you're encouraging by having 1password keep these keys instead of them living on individual hardware.
You may notice they aren't called "Fun size sharing keys" or "Family pack keys" but instead "Private keys" because of that word "Private".
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.
Has anyone compared the new 1password GUI for ssh keys to the Userify one, esp for a team? The userify one is only for SSH keys, but it seems great for safely managing public keys and leaving the private keys safe on our dev laptops (you can put in more than one key so a user can just disable one key at a time, and then it also has a great feature of actually killing all remote sessions when you remove the user account across all the servers -- haven't seen anything else that can do that.) The UI is perhaps a bit simplistic but it seems to do the job.
The cloud syncing, I suppose. If you migrate devices frequently and have more than a single ssh key, it might make sense to log into 1Password instead of trying to securely copy your private key from one device to another.
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.
