5 ms·

Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.

by Saint_Genet 5y ago

cpach 5y ago
To each their own.
- chiefalchemist 5y ago
  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.
  - culturestate 5y ago
    > 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.
    - deleted 5y ago
      [deleted]
  - nijave 5y ago
    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.
    - hobobaggins 5y ago
      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.
      - nijave 5y ago
        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
        gunapologist99 5y ago
        The Userify daemon in this case is just a shell or python script (https://github.com/userify/shim https://github.com/userify/shim) so pretty simple to audit.
        nijave 5y ago
        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.
        gunapologist99 5y ago
        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.
  - staticassertion 5y ago
    Who says your best practices are well tested?
    - chiefalchemist 5y ago
      Who says they are my best practices? They are established industry best practices. So again I'll ask: what case does 1PW make to deviate from those?
dividedbyzero 5y ago
Then don't? It's not like anyone is going to force you into using 1password.
- jiveturkey 5y ago
  Isn't that what he said? He won't.
Cthulhu_ 5y ago
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.
- jolux 5y ago
  https://bugcrowd.com/agilebits https://bugcrowd.com/agilebits
  - roustem 5y ago
    Also, 1Password security audits: https://support.1password.com/security-assessments/ https://support.1password.com/security-assessments/
- MajesticHobo2 5y ago
  They also hire firms for regular security assessments (I did one of them) and publish the reports: https://support.1password.com/security-assessments/ https://support.1password.com/security-assessments/
barkerja 5y ago
They have a nice little tidbit on this: https://developer.1password.com/docs/ssh/agent/security https://developer.1password.com/docs/ssh/agent/security > 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.
- zimmund 5y ago
  > your private keys will never be used without your consent. Unknown vulnerabilities won't need your consent.
jeffybefffy519 5y ago
The bigger issue is the attack surface of the app is now much larger.

Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.

cpach 5y ago

To each their own.

chiefalchemist 5y ago
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.
- culturestate 5y ago
  > 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.
  - deleted 5y ago
    [deleted]
- nijave 5y ago
  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.
  - hobobaggins 5y ago
    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.
    - nijave 5y ago
      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
      - gunapologist99 5y ago
        The Userify daemon in this case is just a shell or python script (https://github.com/userify/shim https://github.com/userify/shim) so pretty simple to audit.
        nijave 5y ago
        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.
        gunapologist99 5y ago
        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.
- staticassertion 5y ago
  Who says your best practices are well tested?
  - chiefalchemist 5y ago
    Who says they are my best practices? They are established industry best practices. So again I'll ask: what case does 1PW make to deviate from those?

dividedbyzero 5y ago

Then don't? It's not like anyone is going to force you into using 1password.

jiveturkey 5y ago
Isn't that what he said? He won't.

Cthulhu_ 5y ago

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.

jolux 5y ago
https://bugcrowd.com/agilebits https://bugcrowd.com/agilebits
- roustem 5y ago
  Also, 1Password security audits: https://support.1password.com/security-assessments/ https://support.1password.com/security-assessments/
MajesticHobo2 5y ago
They also hire firms for regular security assessments (I did one of them) and publish the reports: https://support.1password.com/security-assessments/ https://support.1password.com/security-assessments/

barkerja 5y ago

They have a nice little tidbit on this: https://developer.1password.com/docs/ssh/agent/security https://developer.1password.com/docs/ssh/agent/security > 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.

zimmund 5y ago
> your private keys will never be used without your consent. Unknown vulnerabilities won't need your consent.

jeffybefffy519 5y ago

The bigger issue is the attack surface of the app is now much larger.