A huge problematic deficiency of 1Password is that it lacks literal multi-line text field types.
The items in its database let you define custom fields for them, but there is no literal multi line text field. There's a "File" type, but you can't simply define fields with multi-line text values. However, every item has exactly one built-in "notes" field, but that's actually styled markdown text. And you only get one. And its name is always "notes".
It would obviously be extremely useful to be able to define an arbitrary number of arbitrarily labeled multi line text fields that are not interpreted as markdown text.
It boggles my mind that 1Password doesn't support this. What were they thinking??? It makes it a real pain in the butt to store ssh keys and certificates and a lot of other types of information in 1Password.
A single markdown "notes" field just doesn't cut it. It's not as if it's technically challenging or a security risk. It already has a "notes" field, so just turn off the "rich text" feature and allow me to make my own! I would have thought it was a pretty obvious and often requested feature, but as far as I can tell, it's impossible!
SSH keys have both a private and a public file. The private file is multi-line text.
I don't like putting the private key in the notes field, because its name is still "notes" (but I'd prefer the label be the key's file name), it's actually markdown formatted text, not literal text, and what if I still want to write a note, but I've already used the notes field for the key?
HTTPS certificates including multiple certificate chains, and private keys, and those are all multi line files. And each part should go into a separate clearly labeled multi line field. And I don't want to be forced to write a copy of my server's ssh key into a local file on my laptop in order to attach it to a 1Password file field, and remember to delete it quickly before Time Machine backs it up for posterity.
Right now I am forced to concatenate all my certificates and keys into the "notes" field, and write the file name before each part, and put blank lines between each file, which is terribly inconvenient and error prone.
I also put a multi-line list of all the user names and passwords that I set up on a server.
There are millions of other reasons why anyone might want to use a multi line text field beyond ssh keys and certificates, just use your imagination.
My question is why wasn't this obvious feature supported from day 1, like I fully expected it to be with I bought a 1Password license? Why did I have to find that out for myself the hard and disappointing way, because I never noticed a section in the 1Password manual or promotional advertisements about why 1Password made the decision not to support multi line text fields. I'd love to know the reasoning behind that decision.
[Edit in response to "Maybe I don’t understand, but couldn’t you use the notes section? Wrap whatever you need in triple backticks to create a code block?":]
I PAYED for 1Password, and the company I work for standardized on it and requires we use it, so I kind of expect not to have to jump through those kinds of pointless hoops with a commercial product. I should be able to select-all/copy/paste without meticulously selecting just the right text character-by-character. The time I waste doing just that would pay for a yearly subscription to a better product.
We spoke about it internally many times in the past but couldn't get the solution implemented because there was always something in the way. After reading your comments and I talked to the team and we just merged a change that should appear in the nightly build and make the handling of the multi-line fields better. Having a single core in 1Password 8 makes things so much easier when it comes to implementing changes across all platforms.
Also, there is a new SSH Key item type that might help in this particular case.
1Password has literally blown me away every second that I've used it. And the ability to sync MFA between all your devices was the push that I needed to start using MFA.
I do have a feature request though - any chance we could lock our 1Password wallet using 2FA with SMS (like Office365 or banks) rather than a device authentication key? Main concern is that personal devices are breaking all the time ... SMS is "strong enough" and yet pretty much the only second factor that is convenient to recover in the event of a disaster.
SMS is not strong enough, especially for protecting ALL of your 2FA codes + passwords. SIM swapping attacks frequently occur, and it doesn't even have to be with your carrier.
Just wanted to add that the nightly build 80600030 is now available. Would love if you could give it a try and see if the newly added textfields are working better for you?
Thank you so much! Works as expected, with a small caveat: note that only newly created text fields support multiline; text fields which have already been created with an older build than 80600030 seem to remain single line.
Thank you, I really appreciate that, and it will save me and others a lot of time and effort! Spectacular turn-around. I'm looking forward to upgrading to 1Password 8. Please also put some love into the 1Password CLI utility "op" too, so it's safe and useful for unattended scripts.
I don’t know your workflow or demands so maybe this is simplistic. But you can just drop any file over a 1Password entry and it gets attached to that entry.
So, if you have a .crt, .pfx, .txt or whatever, just attach it to the entry.
Maybe a solution would be to get inspiration from keepass(xc) attachement's feature. It allows you to save abitrary files as attachement to an entry (btw this is how keepassxc does ssh key managment). Other keys/ certs (like HTTPS certs) would be supported such a feature too.
The 'only' downside is the comparatively high increase in database size for the hoster.
Judging by both the GP's not having been aware of it, and the process described in a sibling comment [1], I suspect the feature has a discoverability problem.
(Does the same feature exist on mobile? How are file attachments represented on mobile?)
The feature exists on mobile, there's a "Related items" section that has a list of file names with a ">" caret next to each one. If you tap on an entry it opens in a new page where you can tap "View document" to see its contents. You can also see when it was created and updated, share it, add tags to it, add it your favorites, and more.
It works perfectly fine, with no missing features. I use it to store private keys and recovery codes, mainly.
If you're in here collecting feedback, I would second this request for the same reasons (keys, certs, other structured text I wish I could just copy/paste easily from the UI).
Been a happy paying customer since 1Password v4, but I agree this seems like an easy win.
I’ll add a “me too” comment as well as add that I’d expect to be able to have what is essentially a multi line password field where the contents are obscured.
Or a special feature to transform a set of OTP recovery codes into separate password fields so I can easily copy just one and then remove it without having to edit a multiline field to remove the one I just used.
P.S: I'm not one to write "me too" comments, but there's no upvote count visibility for users. And since a designer working at 1p has eyes on the thread, it might make sense to add "me too" comments?
Same for things like recovery codes / recovery phrases, although I'm not sure how highly i'd rate a security posture of keeping a password, a 2fa code generator, and recovery codes all in the same entry in a password manager.
I know HN probably isn't representative of the population, but I imagine we skew heavily on the technical side of this and I would echo OP's suggestion. It would be very helpful for many developer and potentially other use cases as others have made a case for.
I am trying it out, and hope it will be as useful for cases like using the Google Cloud CLI's secrets command to retrieve secrets in automated scripts, like "gcloud secrets versions access latest --secret=wildcard_foo_com_pem".
I've followed the installation and authentication instructions, and ran "op signin my.1password.com foo@bar.com", entered my account's secret key, my account's password, then it prompted for "Enter your six-digit authentication code:". But I didn't receive any text messages with authentication codes on my phone.
So now I am stuck. I don't have 2FA set up on my 1password account, apparently. Do I need to do that in order to use "op", and how do I do that?
More importantly, when I write a script that authenticates using the "op" command line utility, how can it accomplish the two-factor authentication step without me being present behind the keyboard and entering a response manually? And is there a better way to write a script that authenticates somehow without using my literal secret key and password and 2fa code?
This seems to be an open issue since at least March 2019. Has it been fixed yet, or is a fix planned? Should I just give up trying to use "op" to write automated unattended scripts, the way I use "gcloud secrets"?
>I am using the op CLI and I also have two-factor authentication enabled. Every time I authenticate to op, it asks for the authentication code. This gets annoying quickly and does not help in my quest to automate CLI signin.
>$ op signin YYY
>Enter the password for XXX at YYY.1password.com:
>Enter your six-digit authentication code:
>Is there a way to convince op that it is running on the same host similar to the way the 1password application and browser extensions do?
>Reply:
>@razorsedge unfortunately the CLI has something of an "incomplete" implementation of 2FA, only in that it does not persist the 2FA secret after the first authentication. All the other apps persist this secret, allowing them to do 2FA "silently" in the background, but that has not yet been implemented on the CLI. It's something we look to do in the future, but I can't give a timeline on when it will be available.
>I have TFA enabled for my 1password account. Unfortunately, 1pass can't handle this and instead of letting me input the token, the TFA prompt instantly returns and fails.
While I agree about the specific ask for multiline support (and the decade plus hourly usage of 1p), it's abundantly clear that things are slipping with regards to the core product. For awhile there were no public links to any downloadable desktop apps for macOS while they pushed web + subs + and the MAS version.
These days I'm just delighted when 1password doesn't open a totally different browser when invoked from the active one.
Totally agree there are many other frustrating things with 1P. I’m still self-hosting my vault locally and I hate that someday they’re going to force me to switch to their cloud based options. Just on my list of issues lack of multiline support is near the bottom.
I believe on other fields you can click on them to copy their values. With the notes field you have to select the part of the notes yourself and copy that.
I store my ssh keys, with notes, in the same note. I wrap the ssh key in backticks and put the relevant notes above or below the key. Granted I can't just triple click to select the entire note then copy, I have to interact with it more to copy it, but I very rarely copy my ssh keys. Like once every few years when I'm setting up a new machine. So maybe you're copying them more than I am and it's more of an issue
Attaching files is the worst functionality of 1password.
I put images of my health insurance card in 1pw.
do this. now, pretend you want to upload those image to a web portal that's asking for your insurance information. To pretend, just try and put the images of your insurance card into an email body to yourself.
I find it to be a decent experience (and use it for exactly what you mentioned).
Comparing the two methods I've personally used to store my insurance card below. What are you comparing to?
1Password:
- Search
- Click on the relevant entry
- Click "Quick Look"
- Click down menu
- Click show in Finder
- Drag onto upload form field
Google Drive:
- Search
- Right click
- Download
- Right click on downloaded file botton
- Show in finder
- Drag onto upload form field
- Right click on file
- Delete
Local Filesystem
Not really worth comparing. Could be made much quicker than anything else.
Ideally I should be able to copy things directly out of 1PW. right click, copy. Or the app should use a widget that supports click/drag.
It took me a while just to DISCOVER the steps to getting a file out of 1pw, which involved a lot of false starts into different menus/screens that allow you to view the file's metadata (or preview) without actually getting the file.
Considering "copy field" is THE main functionality of 1PW, it's absolutely insane you can't just copy a file field.
the comparison to me is having the file in my downloads/desktop, which is a very simple procedure to do, as many or fewer clicks, and is a well-worn path.
Agreed it could be a bit quicker or more intuitive, but this seems to be a use-case I don't need to work with too often, so it's not bothered me.
I'm guessing there's a mix of performance concern and privacy concern. They want to make sure you're intentionally revealing the secret (image) and they want to hold off on decrypting the file until needed. It feels like decrypting a file is a fairly slow operation (although I'm not really sure why).
I just don't think comparing to the file in your local files is quite the same, since it's not encrypted / behind password protection. If you did this sort of thing a lot, you'd probably have it optimized down to a very accessible shortcut, after all.
Have you tried actually using that in practice? It's extremely clumsy and inconvenient, requiring a whole lot more pointing and clicking and waiting and typing to attach the file, look at its contents, copy its value, or even edit it, than a simple multi-line text field would require.
And in the common case that the text is only on my clipboard, for example if I copied it from a web page or shell, then I have to go to all the effort of first saving it locally into a file somewhere in the file system, before laboriously navigating to it again with 1Password (often having to wait for my USB hard drives to spin up again as my Mac is frozen for 50 seconds showing the file dialog that scans all the attached storage devices) and finally adding it as a file attachment.
And then after all that extra busy work, the plaintext secret file now is floating around unencrypted in my file system somewhere, which is exactly what I didn't need.
I support your request for basically making the "notes" field for 1Password entries into a field type, so you can have multiple ones.
Having said that, I admit I generally haven't missed them for the use case of SSH keys, even though I do occasionally store those in 1Password -- I use the Secure Notes feature for that. Copy the key to the clipboard with "cat ssh.key | pbcopy", make a new Secure Note, paste. I suppose it hadn't occurred to me to do anything else in part because, well, I can't -- but also because I don't think of these as username/password combinations, I think of them as "SSH for server foobar," and the search feature works perfectly well for that.
This is arguably a workaround instead of the ideal, but I actually use Secure Notes pretty frequently. WiFi base station passwords, recovery keys, personal access tokens, stuff that in general doesn't fit the "web site with username and password and possibly 2FA key" model I'm fairly sure I started this before 1Password even had a "Notes" field.
Wow, I was thinking of leaving KeepassXC for 1password but that is very much a deal-breaker. The UI isn't as pretty or well-thought, of course, but at the very least there aren't as many limitations
Unfortunately for me it was the kind of a thing that I didn't notice until I'd actually paid for a license and started using it. Then I tried to put my ssh public and private keys in there, and hit the wall.
It's such an obvious feature that would be so easy for them to implement, it made me feel like it must be possible and super-obvious to most people, but I was just too dumb to figure out how to do it.
(No, pressing shift-return in a single line text field doesn't work. And pasting multi-line text into a text field replaces newlines by spaces, thank you.)
> 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.
I think this is a bad idea for users. I don't think SSH keys are things you should share across machines in a password manager. If you have two devices, then you should have two keys (though this is the subject of some debate; see [0]). Using the 1Password SSH agent encourages people to have "one" SSH key across devices, which means that any leaks will disproportionately impact them.
It's unfortunate, because there is some real innovation around the per-application usage permissions:
> 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.
If an organization wishes to solve the SSH pubkey distribution problem (the main reason one would copy a private key across machines), then they should use SSH certificate authorities like [1]. In fact, I think that would be a far more interesting 1Password product—HashiCorp Vault could use some competition for this kind of use-case.
> I don't think SSH keys are things you should share across machines in a password manager.
While I agree with the first half of your statement (don't share SSH keys), I cannot agree with the second (don't put SSH keys in a password manager).
For my home use of 1Password, I absolutely want to keep backups of my SSH keys in 1Password. Because, in general, there's exactly 1 SSH key which can get into my cloud instances, and I've had enough laptops die suddenly that I'm not willing to risk getting locked out by not having a backup.
You could say "well, just have a second device with backup keys" but again for home use, why would I buy another laptop just for that? Or maybe just "well keep an offline backup of your keys". Sure. In 1Password. Where I keep pretty much all of my sensitive credentials and info.
> Using the 1Password SSH agent encourages people to have "one" SSH key across devices, which means that any leaks will disproportionately impact them.
Eh. IMO, people who are inclined to use 1 key across machines are going to do it, no matter the process. I doubt this feature is going to make that any worse. But I guess we shall see.
I'll concede that it's not nearly as crazy to share keys across devices for home use or low-risk things. I must admit I was speaking mostly from an enterprise perspective.
I could see this eventually being built into 1Password's Secrets Automation product which can sync to each user's 1Password client. It allows the use of Vault for a backend so now that SSH Keys in 1Password are a thing it wouldn't be out of the realm of possibility to have Vault generate short-lived per-user SSH certificates that are automatically rotated into the user's 1Password vault.
I don't get the hate on Electron. Is it often bloated? Yes, sure. Has it allowed some of these excellent third party apps to make the move to Linux? Absolutely. I've been utterly surprised and excited by how much better 1Password has gotten over the last two years on Linux. We're seeing real parity with the OSX side of the house. Would I love native apps? Again, sure. But I really don't care. It runs pretty fast on my machine and has never really gotten in the way.
Also, they have a nice CLI. I'm sure getting some of these features there is only a matter of time.
I think a lot of the hate (myself included) is coming from the fact that we already had a really good native macOS app. Feels like something is being taken away. I do understand where you are coming from with Linux. It's better than what you had, no doubt. But that doesn't feel like the case to us macOS users.
EDIT: I just tried the latest beta, and I'm happy to say that scrolling the list is now much faster! On the other hand, the blurry fonts, the lack of overscroll, the non-native dropdown menus, the inability to view your vault with the Preferences window open, and the lag when resizing the window are all still there. This does not fill me with hope that the final released version is going to be any better.
I stopped my subscription to LastPass and bought a 1Password subscription because LastPass discontinued their native macOS app and went with an electron wrapper. But the new LastPass client was slow, glitchy, and broke OS integration (It lost a lot of features. I tried to report some of that, and their support team ignored me). The 1Password experience already seems to have more robust features than my experience with LastPass, so I am happy with the switch. I really hope they can preserve all that through the transition, or that they maintain the native client!
From my own experience with Electron apps and 1Password beta a few months ago, putting resource usage aside (even if we should not): OS-native spell checking is missing. Lack of OS standard shortcuts. Everything is a single window. UX performance: lots of things has just a little bit longer.
We added spellcheck and text transformations options recently. Our team contributed a few patches to Electron to enable better macOS integration. For example: https://github.com/electron/electron/pull/32024
I have filed a couple of issues on the community board, but there are two things which are dealbreakers to me (most of the rest of the issues — including the attachment data leak — have been resolved).
1. I despise the binding of ⌘- and ⌘+ to zoom, and even more ⌘0 to zoom reset. I know that those are standard Electron things, but there’s absolutely no reason to make them priority bindings for 1Password.
Beyond the zoom binding, I find the default size too big, so I am running at two zooms down by default. Every time I go for the ⌘0 (all "displayed vaults" in 1Password 7), my zoom resets because of this nonsense. What would make more sense is to: (a) remove those bindings; (b) let one of the collections or accounts be marked as a _default_ collection or vault and bind the display of the default to ⌘0; (c) offer zoom sizes either in the view menu or preferences; and maybe (d) offer the zoom-in zoom-out functionality only in the menu.
2. I absolutely cannot deal with the fact that preferences, collection editing, and a few other things are pseudo-modals that block the use of every other part of the 1Password 8 UI. It’s the #1 thing that calls 1Password 8 out as an Electron app, and it makes me so not ever want to touch these things, which makes them far less useful on a day-to-day basis. If you are unwilling to fix the fact that these things are garbage, at least enable multi-tab capabilities (I would love to see a tabbed 1Password interface). That allows VS Code to be less immediately annoying.
These are in order of annoyance, not priority. I consider the pseudo-modal issue to be more important because it makes the new features that you and Dave speak of unpleasant to configure. Fix these, and I’m back to recommending 1Password 8 wholeheartedly. I’m even missing 1Password mini less and appreciating the replacement a bit more (it’s still not _quite_ as good, IMO, but it’s getting there).
2. It might look silly but we actually had an internal debate about making the preference for floating preference window. I personally do not mind the single window approach because it makes things easier for the non-experienced users. I watched my mother-in-law losing the preferences window when she tried to configure 1Password 7. I know there are certain articles claiming that all Mac apps must have a floating Preferences window but there are quite a few counter-examples as well. Anyway, that preference might still happen.
1. I certainly relate to the pain about muscle memory when it comes to the keyboard shortcuts. At the same time, having an option to easily adjust the zoom settings for an app is such a great feature. I used 1Password on a 13" laptop and on Pro Display HDR and I love the ability to change the zoom factor. I now wish I could do this in every app. Perhaps a solution could be to make all keyboard shortcuts customizable?
The preferences is small enough that I don’t care about that as much. It’s symptom as much as anything else.
The pseudo-modal for collection management is painful.
I never want to open that pseudo-modal _again_ because it’s so awful. It’s narrow, it doesn’t let me look at the vaults while I’m working through what should be in a collection, etc.
This is a problem because it’s a major feature and someone who has used 1Password from the days when it was 1Passwd and you ran the Switcher’s blog…that’s bad news for the success of the feature. Never mind that this is the only way to get to the previous behaviour of "all vaults" meaning "all vaults that have been selected to show in all vaults" and that so that you’re not constantly getting shown things that you don’t want to see by default because the collection you have the old "all useful vaults" is on ⌘5 instead of ⌘1 or (better yet ⌘0).
On the zoom:
Keep the zoom, if you must. But for the love of Jobs, don’t bind it to ⌘-, ⌘0, and ⌘=. ⌘0 should be _either_ "show preferred collection or account" or "show main window" (leaving ⌘1 for "show preferred collection or account"). Seriously, that binding is the absolute #1 thing that I hate about the Slack app, and there are _legions_ of things to hate about that. Leave the zoom options in the View menu, because your mother-in-law, if she wants to zoom in isn’t going to remember ⌘= to zoom in. She’ll look in the menus.
1Password 8 is _much_ better than it was when I started using it in July. But these two things actively make me _angry_ about using it because: (1) the pseudo-modal, especially for collection management, makes me not want to use something that looks much better than previous mechanisms, and (2) the zoom gets in the way. I’m using 1Password on a single monitor (14" MBP, previously 13" MBP) and I want to set my zoom _once_ and never think about it again, especially if I hit ⌘0 (thinking "show main window" or "show preferred collection or account") but it resets my zoom. Having the zoom bound is a papercut that happens to me multiple times a week because it makes no sense in anything except a web browser.
Not looking for a fight here, but it seems like there is a disconnect between 1Password/AgileBits praising version 8 while also trying to bury the fact that it is an Electron app. It seems like you are proud of what you are building (and that's awesome), but the Releases page for beta [1] doesn't contain the word Electron.
Electron is effectively a UI and code framework, much like SwiftUI or just Swift with AppKit; I don't see why either would need to be a marketing point or referenced in the changelog. 1Password 7[0] doesn't say what it's made in either.
This is a specious argument imo. The beta does mention that some part of it is written in Rust, why exclude Swift/Objective-C to JavaScript if you're in the business of talking up implementation changes?
Why jump to "trying to bury" if you're not looking for a fight?
There are many reasons for not specifying what framework an app is built in, the most obvious of which is that the general public both has no clue what Electron is nor a desire to find out.
Just because something isn't listed doesn't mean it's "buried". Like the other commenter said, you don't routinely see users of other frameworks and languages put it front and center, why should that expectation change with Electron?
That's some good news (though it looks like you linked to another github issue), but my real-world experience unfortunately stands in stark contrast to your claims. I don't know who to trust, my senses or your words. Previous version is noticeably snappier still.
Will you add support for increased contrast again? (it was removed in v8, and was one of the many regressions that made me effectively give up on 1Password)
I was fully prepared to say 'memory usage' as a kneejerk to Electron. But I decided to open System Monitor real quick and it turns out my 1Password 7 instance is using 201MB itself. Another ~30MB if the helpers are included. My machine has been on for about a week and I invoke 1Password a lot throughout the day + have about 500 entries.
How much memory is yours consuming (assuming you're using 8)?
I tried 8 on Windows. I went back to 7 after a week.
* Search is just plain broken. This was the number one reason i scrapped it.
* Managing multiple vaults (i have over a dozen) is unusable.
* The UI is terrible, it takes way more space to show less information than 7.
* The browser integration (FF) seemed to work poorly.
Basically, once 1Password stops supporting 7, they will have lost me and anyone I can influence as a customer.
While I fully agree with your issues, and have experienced them too, (although comparing v8 on Linux to v7 on Mac – I don't use 1Password on Windows), those are just UI/integration issues. I don't think they're because of electron, but rather because the remake of the UI is poor.
FWIW, my main gripe is having to unlock each vault separately, as opposed to a single unlock as used to be the case on Mac / iPhone.
That one part yes, but if you can build most of your application cross-platform and only do certain things with "native" solutions you might get better bang for the buck. Discord and VS Code comes to mind.
Rust is hardly a "desktop-native" language. I expect it will have to jump through all sorts of hoops to interface with the Obj-C underpinnings of MacOS desktop libraries.
Regardless, even if the backend were pure Obj-C, the point is still that now you have a UI stack and a backend stack, instead of a single desktop-native stack, and you have to manage their communications. But I guess the money they save by not managing desktop-specific codebases eventually adds up...
Besides that it's bloated. I really don't want to have my passwords and keys managed by something that's built on a software supply chain, which is so prone to malicious attempts (npm packages). There are way too many deep dependencies and mini packages out there.
Memory is a precious resource. Every additional Electron app that’s running increases the likelihood that your system will have to swap, and then it will feel like a a turtle in a tarpit. Also, there’s some concern that continuous swapping prematurely ages SSDs, reducing the overall lifetime of laptops. The modern trend is to solder storage chips directly to the main board, making them difficult to replace.
> Also, there’s some concern that continuous swapping prematurely ages SSDs, reducing the overall lifetime of laptops. The modern trend is to solder storage chips directly to the main board, making them difficult to replace.
You have to thrash a full drive QUITE hard to cause any significant wear, all modern drives take care of themselves and the filesystems report which blocks are unused to let the SSD take care of itself.
Surely it's a concern in a server environment and some other "spacebar heating" workflow but in reality it doesn't happen.
Just because you haven't personally experienced this problem doesn't mean that many others have not. The experience of others is just as valuable as your personal experience, and to denigrate the experiences of others demonstrates a lack of empathy and understanding. Not everyone has an SSD, and not everyone has more than 8GB memory in their laptops. Many laptop manufacturers (including Apple) continue to sell lower-memory systems in droves; and there is a widely-installed base of older computers dating 5 years and even longer.
My point is that, in 2022, the overwhelming majority of people do have the necessary resources required to run Electron apps on their laptops and desktops.
My view is backed up by the fact that people do exactly this, with great success. The complaint about memory is not reflective of the typical user experience.
The fact that multiple people here are telling you that they have experienced RAM shortages and swapping due to excessive consumption speaks for itself.
The fact that you need me to "show data" that Moore's Law exists is, in and of itself, hostile, but on top of that this comment pretty solidly demonstrates that my intuition is correct.
You are the one who came in here and disputed my claim (and those of others as well) without a single shred of evidence. You still refuse to substantiate your disagreement.
Nobody is disputing Moore's Law (and this is the first time you've brought it up!). The dispute is around whether people still experience slowdowns and other bad experiences as a result of excessive memory consumption relative to resources, despite Moore's Law. I and several other people have told you right here that they have, and you refuse to acknowledge our collective experience largely because you personally haven't shared this experience.
My ego isn't bruised. But I and others reasonably expect significantly more than a "drive-by" non-substantive negation of a claim that comes directly from personal and professional experience (i.e., gaslighting) -- especially on Hacker News, where the audience is supposed to be largely composed of mathematicians, scientists, and others who possess better-than-average ability to think deeply, logically, and in a nuanced fashion.
You are wrong when you say, "Memory is a precious resource." No "precious resource" doubles every two years. You can either accept that objective fact, or you can continue to try and weasel your way around it, but the fact will remain.
First, average primary system memory in a typical laptop does not double every two years. Growth of average installed memory has been linear, not exponential (see, e.g., https://techtalk.pcmatic.com/research-charts-memory/). Second, even if it did grow, software can consume memory faster than it can be provisioned; there's no law that prevents software developers from writing software that utilizes an arbitrary amount of memory. Put differently, adding more memory does not necessarily ensure the software will not consume it, in the same way that adding more freeway lanes is not a guarantee that gridlock will not ensue, or that moving from an apartment into a mansion is not a guarantee that it won't get filled with stuff.
Aaand now you've gone on to dispute Moore's Law, as if the specificity of the "two years" part was at all critical or even important to our conversation.
Also, that link you provided seriously undercuts your own argument, you do realize that right? It very clearly shows how over 90%+ of computers have 4 GB or more of memory installed, which is plenty to run multiple Electron apps.
I encourage you to read my argument from the top again. I speak in terms of probabilities, not absolutes. I don't disagree that many people might not notice performance degradation when running multiple Electron apps. However, it is an incontrovertible fact that (all other things being equal) an Electron app will consume more memory than a native app will; and some people will experience swapping and reduced performance when running Electron apps where they might not experience that if they were solely running native apps instead. Also, it's important to keep in mind that people often run a healthy mix of apps at once--both native and Electron--and they'd have the ability to run more of them without risking swapping if they ran fewer Electron apps (again, all other things being equal). The closer you get to exhaustion, the more economy of consumption really matters.
I just can't see how this is that controversial a claim.
What you have here is not a controversial claim. It's also not what you've been arguing until this moment, but for whatever reason you've softened your position substantially, now to the point of (IMO) banality.
What's controversial (because it's false) is the claim that, "Memory is a precious resource." That is not a true statement.
We call memory a "precious resource" because it is often a fixed quantity in a given computer, and often the most expensive component after the display unit. Many laptops these days do not offer upgradeable memory, and even when they do, they often have very few slots in which to add it. So for many people, an upgrade involves an entire unit replacement at significant cost. I think most people understand this, so again, I don't see how it's particularly controversial.
Anyone with a system that is running full of Electron apps knows how awful it adds up and how slow they are. Sure just 1 app makes hardly a difference. But I have 16GB of RAM and it gets awfully slow very fast with all that electron mess.
As someone who has to occasionally unstick stuck systems by way of `echo 3 > /proc/sys/vm/drop_caches` because memory management in the real world doesn't work the way the people who write condescending sites like linuxatemyram.com say it does:
What’s funny about this comment is how detached from reality it is.
If you round, approximately zero users of Electron apps know how to do what you’re talking about, and yet they continue to successfully use Electron apps across a variety of platforms.
The fact that you have to finely manage your system’s memory is a you thing, not an Electron thing. The two are entirely orthogonal.
Memory is not a precious resource, no matter how much you want to live in a world where your obsessive compulsion to manage it is reasonable.
Was it really necessary to have the rude and condescending attitude? While it served the point of illustrating the toxic behavior I took issue with of those who claim memory management is Fine(tm), I don't think it was warranted here.
I only care about managing my memory because the consequences of running out of free memory are severe. Linux as shipped by mainstream distros is quite happy to start filling swap (with attendant kswapd CPU usage) when there's multiple gigabytes of pointless inode/dentry cache to evict.
Both of these are problems that simply don't exist on Windows and MacOS. Windows because it doesn't pretend half of my system RAM is useful cache, MacOS because it does compression out of the box and doesn't appear to be so aggressive.
On each and every point your view is only true in very isolated and niche situations, while simultaneously begging the question that you’ve run out of memory in the first place.
Linux is not good for desktop environments for exactly the reasons you outline here (and many more). It’s not Electron’s fault you’ve used the wrong tool for your desktop OS.
It's very antisocial to tell people they're using the wrong tools. In today's world, it's becoming no longer sustainable to respond to wasted resources by asking the world to purchase more resources (resulting in even more waste in the long term) to accommodate it. Conservation is becoming increasingly important.
Is it antisocial to tell someone they're being antisocial?
And you're using the words "wasted" wrong, assuming you're referring to the memory footprint of Electron. Electron uses memory to solve a compatibility problem, that's not wasted at all.
One person's benefit is another person's waste. If you think there's not room for vehement disagreement around how best to use space, go watch an episode of Hoarders.
Please elaborate to those of us who have actually experienced the “swap swamp” within the last year, in the 2020s, and who have enough systems knowledge to properly instrument this stuff. Are you gaslighting us?
Because the idea of shipping a goddamn browser for each and every little GUI app is revolting and disturbing. What other crazy decisions have these people made?!
I seriously don't understand making blanket statements like this
All this fearmongering made me properly look at and note the memory usage of the native windows app and then the electron app after I upgraded. The new app uses a whopping 50MB more when the desktop app is open and uses 10MB less when it's not
People keep ranting and raving about this with no context and zero research. I'm sick of this especially on HN
It's not about the memory use. It's about the insane complexity.
An old grandma is looking for a little city car to take her to the neighborhood store. Solution: Use an Airbus A380. The fact that the engineers have made the plane weigh only 50 times as much as the city car is great, but it doesn't really change the fact that it's a crazy approach.
I don't have strong feelings about Electron, but 50MB more memory for the same functionality does seem like a lot. If every app I have open on my machine suddenly used 50MB more memory, it would be a noticeable hit.
But it is not the same functionality at all. In terms of privacy and security, the older versions do not come close. And we reworked many pain points in 1Password 7 — better lock screen, improved sidebar, new watchtower, item editing, (in)security questions, fully encrypted item icons, item location bar, tag autocompletion, special handling of the scenario where 1Password becomes locked in the middle of the editing session — and I am not even listing 10% of all the improvements here.
Note that that's 50MB more when the 1Password window is open. When it's running in the background it actively uses less memory than it did before. And that effectively means 99% of the time it's running faster than it did
Qt and GTK apps don't usually spawn 5 processes, 300-400 MB of RAM, and take 100+ MB of disk space (because they always ship an entire copy of Electron) just to show a small window.
They solve the task at hand (cross-platform GUIs), plus some auxiliary tasks like cross-platform FS access etc etc. That's much cleaner and more principled than "screw it, let's ship a browser".
It doesn't integrate with OS. Like events happen differently, stuff like this. Especially for macOS.
But again, if one uses some crap from IntelliJ and Slack, this fits right in.
In terms of performance it works better than 1Password 7. Noticeably better, on both mac and windows. On windows tablet it was barely usable before now it's rock solid.
It feels a lot more appropriate to judge a piece of software based on user-facing attributes rather than technical implementation details. 1Password has a great track record of producing good software. That says a lot more than what technology they use.
Is it? The Reddit comment mentions that most of the code is written in Rust — I assume business logic, encryption, etc — and the UI is in electron via React.
So this certainly seems quite a bit different from plain electron apps.
I'm quite excited about this as a potential way to avoid the problems that once a key is added to an agent any process can then use it. It looks like this prompts for permission for each process that wants to use the key, but then doesn't prompt again.[1] I've tried using various tools for this but they've always been too clunky. YubiKeys work well with their requirement to be physically touched, except you continuously have to press them when using git commands (multiple times if fetching many remotes).
I haven't been able to see anything about how this handles agent forwarding over SSH. Does anyone know?
And yet we still can't use the keyboard to navigate to the `Generate Password` button like we could in every version of 1Password before the current one.
I work at 1Password. Could you tell me a little more about this? I tested this in the latest version of 1Password 8 and when I'm creating or editing a password, I see a "Generate Password" button pop up beneath the password field. I can access it by either pressing the down arrow or tab. Does this not work on your end?
macOS, 1Password 7, try this: Hit Cmd+Alt+\ and try to tab to the Generate Password button in the top right of that window that pops up. This was possible in earlier 1Password, isn't now. Tabbing moves you between the left pane list of suggestions etc. and the right pane. If there's something in the right pane, you can arrow through them, there's no way to get to the Generate Password button without taking your hands off the keyboard.
Additionally, now when I do generate a password, it saves that password in my shared vault for all the world to see instead of defaulting to a private vault where only I can see it. It doesn't appear to be possible to tell it where to save that password until it becomes a login, but by that point 1Password has already leaked the password I just generated. That seems like a really terrible default, and the only way I've found around this so far is to try to remember to open the main app, go into my shared vault and delete the password that I never wanted saved in there in the first place.
1Password 8 is not the current version.
On 1Password 7 on macOS, when the browser extension offers a "Generated Password" there is no way to configure how it is generated. You have to open the main app to create a new password.
Since krypto.co use case of SSH key handling fell to the wayside, I recently switched my keys over to Secretive[0], which stores keys in your Mac’s Secure Enclave or YubiKey and the case of the former, uses Touch ID to authorize use of your key.
It’s very simple and works very well. Better than krypt.co did for me, actually — krypt.co would occasionally randomly break, but Secretive has been rock solid. Every time something tries to use your key you get a Touch ID prompt and a notification indicating what triggered it.
This 1Password feature looks nice, but I’m switching away when version 7 stops working. AgileBits just isn’t taking 1Password in a direction that’s appealing for me… they’re clearly more interested in corporate users than individuals, and in the pursuit of a one-size-fits-all-platforms UI they’re losing the attention to detail and polish that used to be a major selling point.
Krypt pretty much works all the time for me, with the main reason I still use it being that WSL can't use the host OS's ssh-agent for logging in without aliasing ssh to ssh.exe. That and the Windows ssh agent itself can't use native Windows Hello APIs[0] to have an experience similar to secretive on Mac where the keys never leave the device and are protected by the secure processor in the device.
I’ve been treating SSH keys in the same way I would a password. Each service gets a new key generated for it.
From doing some reading though it sounds like I might be wasting my time. Apparently it’s fine to have one key for an individual machine and to use that for everything.
What’s everyone else’s take on that? Are you reusing a single key or generating each time?
IMO, an ssh public key is not a password and shouldn't need to be treated as such. The public key portion is public. When you generate an ssh key pair, its like making both a lock and a key, then giving the lock to a server and saying "use this lock on my door". This lock can only be opened with your key, and can only be picked when your encryption algo of choice (ed25519 for me) gets obsoleted.
Sprinkle in a passphrase and now you have good MFA: something you know (the passphrase) and something you have (the private key).
Personally, I don't see a problem with re-using a key pair across multiple servers. I like to do one key pair per client device. This lets you manage server access per device. You can single out and remove just the key from a lost or compromised device without affecting the others.
OTOH, one key pair for all devices fails at this, plus you also have to worry about protecting the private key during distribution to multiple devices. A private key is best left on the client that generated it. Of course, once you hit enterprise, all this goes out the window. As they will probably have systems in place and compliance rules to follow.
I use a handful of keys. Thing is, your secret is never shared with the server. Just the public key bits. Passwords are stored (hashed) on the services. Totally different threat models. With your public key the biggest risk is someone tracking what you are up to if they compromised multiple services/servers you use.
It objectively is since I never transmit the private key bits to the server. Passwords usually require the whole secret be blasted about the Internet (albeit encapsulated in TLS, usually).
Why be obtuse? Are you talking about compromising the client machine? In which case, you’ve already lost all your keys, and you’re relying on their passphrases being set.
I'm saying private keys are not more secure by default. If your development machine is compromised (which is really easy to do, BTW) they'll steal your keys and probably will have root on your servers and access to your github accounts.
As an attacker, maybe true depending on your target. As a user I have had my passwords compromised many times. My SSH keys never have and I don’t know of any prominent evidence this happens much at all. I have been doing reversing, netsec, and appsec for 15 years now, so my memory goes back a ways. Plus, for example, my main system a Linux desktop. You can and should password protect your SSH keys, which further eliminates a number of key compromise scenarios.
I'd love to, but I keep keys on my Yubikey - which only supports 1 auth key. Even using U2F for SSH keeps the same restrictions. And using a different yubikey for various services isn't ideal either.
I have considered keeping encrypted keys in my password manager per-service, and decrypt+add them to my SSH agent when they're used to offer almost the same guarantees.
> Even using U2F for SSH keeps the same restrictions
Er, what? The SSH keys are being generated the same way keys for web sites are under FIDO, which is to say they're random - your physical device has no idea how many keys you have, it couldn't mandate that there's only one key if it tried. It only knows how to tell if these are keys it made (otherwise presumably a different FIDO authenticator made them) and if so use them to sign you in once somebody touches the contact.
I treat them as identities. Each identity gets it's own key and each identity may have access to numerous accounts. It's bad opsec to share keys between identities.
A mix. Typically I'll use one key per machine and add those keys in the places they need to be. This is good as you're reasonably well protected if that machine gets lost or stolen. The nature of public key cryptography means there's no risk associated with handing over your public key to many different places.
However sometimes it's practical to use the same (private) key in multiple places. I do this for access to low-risk stuff like ssh access to my raspberry pis. I wouldn't ever move a private key around for anything remotely dangerous though.
There is a slight risk - if someone has your public key they can setup a MITM server and pretend to be the one you’re expecting - and watch what you’re doing, or redirect test to production or similar.
It’s really very minor and ssh itself should warn that the servers fingerprint changed.
Public keys are identity, so, a remote server can (and a famous one does: https://github.com/FiloSottile/whoami.filippo.io) tell you if e.g. you connect to it while offering to prove your identity with keys github knows about, because github provides a list of those keys. That's the extent of the interesting consequences of knowing your public keys.
You can't realistically MITM SSH because you will have a session mismatch. You may be able to convince a naive visitor (coming to some.machine.example with no prior contact, and not using either certificates, or secure DNS protected credentials to verify the identity of the machine) that you're some.machine.example but you can't successfully splice this to a connection with the real some.machine.example if they use public key login.
The reason is, during connection you persuaded the client that you are some.machine.example, but to do that you needed to make up keys since you don't know the real keys for some.machine.example. However the real some.machine.example does know its keys and they're different. The credentials the victim client gives you only work for your keys, they won't work for the real some.machine.example keys, and the client has no reason to present you with credentials that would work for the real some.machine.example, so you can't authenticate to the real some.machine.example as them.
Well, there is a non-negligible chance that the client has agent forwarding turned on, in which case the MiTM box could splice the connection to the real some.machine.example.
This shouldn't be possible for any server you've previously connected to. Each machine should have a unique "host key" and OpenSSH prints a very loud message and refuses to connect if it ever changes.
I use use a security key to login to personal ssh services, which uses a single key. The key requires a physical touch in order to log in to devices though.
If something more robust is needed, ssh certs and principals can be used.
default SSH key is the same one for GitHub (since they leak users’ pubkeys anyway), and private repos (eg. hosted GitLab instances) get their own keys. not really sure if it buys any privacy though.
Uh, "leak" is a strong word. They are PUBLIC keys, to think of them as anything other than public is your mental block. If you share your public key with someone, expect them to publish it publicly.
Try thinking of SSH pub keys as identities or usernames and you are more on the right track.
I tend to have 1 pubkey per thing I care about, so 1 per github account, 1 per gitlab account, 1 for work, etc.
Ahh, this is such a nice improvement over literally anything i've used for agent key management on Windows or Linux, and easily competes with using the Keychain integration available on OSX; It sucks that I can't really use the functionality due to the v8 requirement, and am once again in the position of paying for something where I don't get to actually use new and useful features due to really aggressive ( if not outright anti-user ) product direction.
For some context on my bitterness: v6 stopped working with chrome based browsers a few years ago due to an issue with browser signatures, and the official guidance was to ( pay to ) upgrade to v7 rather than fixing the app, and so the software I had paid for was no longer usable in the way that it was when I purchased a license for it, effectively being downgraded through no fault of the end user ; Similarly, the Windows variant of 1pw has... kind of always just been a bad experience compared to the mac version, and while the controversial Electron-based unification for v8 promised to bring the experience in line with the Mac app ( not requiring purchase of another license type this time because I'd since bitten the bullet and paid for a subscription so I could actually use v7 ), it also required migration to the hosted vault system, as support for local vaults was completely dropped in the same version.
I would feel a lot more comfortable using this otherwise legitimately fantastic functionality if it didn't also require me to migrate from a local vault to the hosted version. I already didn't want my passwords hosted online; I definitely don't want my ssh agent and its private keys to be bound to said hosted service, and nothing has yet come out of 1Password's survey for self hosting the vault server in order to maintain a vault that works with 1PW 8 locally.
It's an unfortunate hill to die on, I realize; I just want to maintain control of my own stuff, using a tool that is actually nice to use ( 1Password is and has always been miles ahead of everything else in terms of the day to day user experience, otherwise I'd be able to justify looking at alternatives )
I’m not sure your critique of v6 to v7 migration is fair. Im sure v6 continued to work fine on that old version of chrome. But it seems perfectly reasonable for developers to be compensated for writing new code to work with new versions with new requirements.
I also feel I should be realistic about the incentive structure. I want 1password to continually work on security, additional features, and quality of life stuff. That requires steady income.
As to your local vault concerns. I think you have a really valid point.
> I’m not sure your critique of v6 to v7 migration is fair. Im sure v6 continued to work fine on that old version of chrome. But it seems perfectly reasonable for developers to be compensated for writing new code to work with new versions with new requirements.
I don't disagree that they should be compensated for new versions, however, I think we have a difference of opinion on what qualifies as a patch; I'm not intrinsically against upgrading license types ( though I don't like the move to subscriptions-only ), but I also expect the software I've already paid for to be updated when a major selling point feature ( browser integration ) breaks, especially if it's only the previous version ( in spirit or in practice ).
To be honest, though, I don't really expect they'll have a similar situation in the future now that they're actively maintaining all platform versions ( and with a unified core! ), so I'm being bitter over the past and letting it seep into how I feel about v8, local vaults, and control of my data.
I've been a huge fan of 1Password for almost ten years now, recommending it to friends and family, but like some of the comments mentioned it feels like the product is trying to move upmarket while dropping support for core features.
I've bought their license a couple times as the versions are updated, but they no longer support licenses and only monthly subscriptions. Fine.. I'm happy to pay that to get a great product, but as I was installing it on my new laptop they prompted me to move from my self-managed cloud sync to their hosted password management saying the cloud-sync will no longer be supported. I simply don't want to use the hosted solution, I'm not comfortable with the trust implied.
I imagine they're trying to cut down on the features that allowed someone to use it without paying a membership, but then why not just include cloud-sync in your paid features? Why remove a such a core feature that allows users to use your security product much more trustlessly?
I definitely understand the aversion to trusting 1password's cloud service, but it's worth noting that their security model is such that it requires minimal/zero trust of the server.
Your vault is only ever decrypted on the client side, and the 1password service only ever stores/syncs the encrypted vault. This is why if you lose access to your secret key, your vault can never be decrypted, even by 1password - your secret key is only ever stored on your local device and never by 1password, not even a hash of it.
1password has a great white-paper on their security model if you're interested, and it's verified by 3rd party auditors.
> I definitely understand the aversion to trusting 1password's cloud service, but it's worth noting that their security model is such that it requires minimal/zero trust of the server.
It just requires absolute blind trust on their client apps...
> Your vault is only ever decrypted on the client side
Which is a closed source blob, so, again, requires absolute blind trust.
Yup completely valid. In the context of the original post I was replying to, trust of the closed source client code was always required and that hasn't changed, so it didn't feel relevant to mention. I agree with you that there is significant merit in choosing an open source solution for passwords/secrets management.
Oh I get that, and agree! But despite that it still feels like a honeypot, centralizing every user's most important security info in one cloud service (read: honeypot). At least with Dropbox/iCloud sync you're relying on the same e2e encrypted setup but in a less centralized service (for example, if there's some bug in the e2e encryption someone would need to take advantage of that AND iCloud's encryption and target users using the combination).
I have used 1pass for years. I think I bought my lifetime license sometime in 2014? I loved it and even advocated for our 2000+ company to adopt it back in 2018.
I would say in the past 2-3 years it has slowly become an absolute nightmare. I do not recommend it to anyone anymore. They have somehow screwed up the very basic functionality of filling in passwords on any browser I try. They continue to shift features around, break existing workflows, and even the basic tasks I rely on dozens of times a day seems to change with any significant release.
1Password got famous for building a great core product. It managed my logins I stored myself and autofilled them wherever I needed. It was clean and simple. Now they are so focused on growth and Product features like this that they have completely lost their way. As of this week I can no longer right click on a webpage and work with 1pass to find something. If the webpage attached to the original 'save login' prompt is not the one you are on - the auto popup underneath the login field has nothing to show and I cannot manually find and enter it. I have to go to the Desktop app, search, find, and copy. My team regularly wastes minutes on this each day.
Our company reevaluates platforms every couple years, in the next 12-24 months I will strongly advocate we find an alternative.
This is weird, I legitimately have none of these problems. I use Firefox, and the extension story has gotten a bit more odd in the last couple years*, but I don’t feel it’s any less reliable. The way 1p handles 2FA is really slick in my opinion, auto-filling the code after a login screen and even hitting return for me most of the time. Honestly the only rough edge I hit is when browsers try to force their own password management, and end up fighting with 1p for password generation, saving login details, etc.
* to expand on this, the model used to be a desktop app where the magic happened, plus a thin browser extension that hooked into the app. Now, there seems to be a lot more happening in the browser extension, which seems to talk to the cloud service and not directly to the desktop app. (Totally possible this is completely wrong, just my WAG)
It's not as strong as storing them in an entirely separate device (although hardware keys are even better).. however I suspect most people would have their 2fa generator in the same place as 1password (eg. Google Authenticator on the same phone).
It still provides improved security in case of things like server-side credential breaches.
Honestly I find one of the biggest missteps for me is that they started injecting UI into the web page itself.
I'm sure it reqires less work from the locally installed app (and lets them do away with it altogether, even), but it creates issues - it obscures UI elements in the page with a hard to dismiss overlay (no obvious clickable way to do it) that fits below webpage UI elements when it's heuristics identify it as an appropriate field.
edit: plus I regularly find that when I try to fill form fields in Safari and Firefox that selecting the appropriate login and hitting autofill does absolutely nothing.
The biggest issue for me isn't anything that's really 1password's fault but rather web application developers not detecting that a username/password field has been filled because 1password did it.
Developers need to stop disabling the form buttons trying to be clever detecting if fields are dirty.
> 1Password got famous for building a great core product. It managed my logins I stored myself and autofilled them wherever I needed. It was clean and simple. Now they are so focused on growth and Product features like this that they have completely lost their way.
The issue is, the "core product" has been Sherlocked - i.e. is now an included feature on many operating systems and browsers. Apple's iCloud password manager is available on all Apple platforms plus on Windows. Android/Chrome and Windows are improving their in-built password managers as well.
So 1Password, as a business, has to pivot to selling to businesses, which is where they expect most of their revenue to come from. This has resulted in individual customers being sidelined, so perhaps you should switch to one of the free inbuilt alternatives.
> They have somehow screwed up the very basic functionality of filling in passwords on any browser I try
What browser/sites are you having issues with? I've only been using 1Password since the Lastpass changes last year or 2 (I forget) but havent run into a site I can't autofil. I actually found it works in places Lastpass used to let me down such as CapitalOne
Chrome for work, Firefox for personal. Both macOS and Windows 10. I am in contact with 1pass on Twitter, followed their recommendation to turn off the legacy extensions Desktop App Required and it is still broken.
What's changing? It's been filling passwords for me just fine in browsers for years, if anything it's gotten better about it. The problems you cite with it not finding the right login happen with other managers too and they aren't as good about it.
> They continue to shift features around, break existing workflows, and even the basic tasks I rely on dozens of times a day seems to change with any significant release.
That shouldn't be a matter of opinion, yet it doesn't match my experience at all. 1Password 7's UI and workflow did not undergo a dramatic change in the past 2-3 years. Not even once. The UI and controls looks and feels the same as ever as it did back in 2018. I'm sure the periodic updates brought new features here and there, but none of those are even remotely close to being a disruptive change.
> If the webpage attached to the original 'save login' prompt is not the one you are on - the auto popup underneath the login field has nothing to show
That's a legitimate security measure. It's making sure that it's autofilling for the right domain. If you want working autofill, you just need to make sure that your password is associated with the right domain.
> I have to go to the Desktop app, search, find, and copy. My team regularly wastes minutes on this each day.
You only need to make an edit once to associate your password with the right domain. But if you can't be bothered, searching and copying the password is a "Cmd + \" away. It takes less than a second.
It's not a security measure because the original comment spoke about how they couldn't even search for the login inside of the autofill icon. I've had that issue too and it's very frustrating. Yes, it makes sense not to show it by default, but to disable any sort of search functionality inside of their new autofill UI is annoying.
Edit: This was not an issue before 1-2 years ago when they pushed massive feature updates. It used to be Ctrl+\ or Cmd+\ to autofill and boom, the login was filled. But NOW they have decided to drop a "1Password X" browser extension that throws itself into every single login item on the web and constantly harasses the user any time they use keyboard shortcuts to navigate. Typing an email address and see your Firefox/Chrome/Safari autofill show up with a dropdown of emails to choose? You can't even use the arrow to go down and choose one; 1Password X will rear its ugly head the minute you hit the arrow down, and it'll either prompt you to autofill something or save what you just typed into 1P.
I have used 1Password since way before the cloud version became the default. I loved the product... and I still do! I moved to the cloud version and the experience has been really slick.
I actually think the product is well thought-out and designed. There are some website where it refuses to work, but these are in the minority, and I blame the websites for breaking 1Password, not 1Password.
Also "a nightmare" -> this feels like an unnecessary hyperbole
I'm just as frustrated, but given how convoluted and complicated web site authentication has become, I've blamed the web sites, not 1Password. They can't possibly be expected to handle every scenario that every major internet site comes up with, and festoons with trackers and ads and javascript malfeasance and second-factor redirects. I guess if you're right, and 1Password is, in fact, to blame for this mess, then you'll find a great alternative. I just hope you post it back here when you do.
That's a great point and something I was very okay with because I could still navigate 1pass to the necessary fields. Google broke the automatic user/pw/login flow years ago but being able to still manually right-click on the necessary account for each stage of the login was easy. This is no longer possible. The blank suggestions they shove underneath every available field breaks my ability to click something that the browser itself might have stored and never has what I need. I am back to copying and pasting from the app itself.
> the webpage attached to the original 'save login' prompt is not the one you are on - the auto popup underneath the login field has nothing to show and I cannot manually find and enter it
Is it the same URL as what was saved in the login? If not, then this is intended behaviour to stop phishing attacks and has saved my butt several times. If the autofill doesn't work, either the website has changed the base URL, I've misconfigured it, or it is a phishing site
> I have to go to the Desktop app, search, find, and copy
Use the browser extension?
I'm not sure what issues you're having. Personally not only has the product improved every year, trying other password managers makes me realise what a hard problem autofilling is and how little I have to think about it with 1P. The new desktop app has some issues though and some missing features though it's pretty snappy
To both your points - a great example is right here on HN. If I right click and go to 1pass, I no longer can open any mini window. I instead am given the option of Lock, Save Login, Help, or Hide on this page. Completely breaks my 5+ years of muscle memory to right click on a field and find what I need.
Now if I open the browser extension in the top right, my Favorites are not my favorites...they're the favorites of my team and one of my shared vaults. My Suggestions tab is empty. And even better, when I search "ycombinator" or "hacker" or "hn" nothing comes up. "No results found in All Vaults" and if I click search everywhere I get "No results found"
Now when I go over to the Desktop app, I search any one of the above and I immediately find my credentials for HN. It's stupid simple just like it used to be in the browser.
That is interesting. When I read your initial comment, I was completely bewildered because the software keeps getting better and more reliable and the new browser extension saves me lots of time. It wouldn't have occurred to me to use that right-click menu for anything, though, and I can see how it might have done something useful in the past for you. Different experiences that happen to share a product name!
Hmm yeah I'm really not sure what the issue is here. Maybe try contacting support on their forums if you've not already. I never really used the right click menu and never needed to so far since the suggestions have always worked so maybe there's some other problem you're facing
> If the webpage attached to the original 'save login' prompt is not the one you are on - the auto popup underneath the login field has nothing to show and I cannot manually find and enter it. I have to go to the Desktop app, search, find, and copy. My team regularly wastes minutes on this each day.
This saves users from choosing their “Google” login to use with “G00gle” - why not take the minute or two to update the password entry once with the correct or additional hostnames/websites and be done with it rather than wasting time every time one logs in (as well as encouraging bad security hygene)?
> I have to go to the Desktop app, search, find, and copy
Agreed, the Chrome browser extension and the Safari inline menu are garbage.
Fortunately the classic extension is still available and still works great for me, as well as Safari with the inline menu option disabled.
Same for the iOS extension, garbage. But luckily the classic password autofill on iOS still does work great.
I use the Firefox extension on desktop and have no issues. But the iOS one, I have to agree with you, is pretty garbage. It only works half the time for me. It doesn't prompt when I'm in a username field consistently, and sometimes doesn't fill the password on the first time, forcing me to hit it again or copy paste. I find myself more often having to physically navigate to the app, type in my username, and copy paste my password.
If you are using the classic autofill don't you have to maintain your password in keychain as well as 1Password?
Your reliability issues differ greatly from my experience using 1Password over…what…10 years? If anything, I’d say that the new generation of browser extension improved reliability. The UI injection only irks me for puritan reasons, but i reality seldom have issues with it.
Not to say that you’re “wrong”, but since we are sharing experiences…
SSH keys authenticate you. They are an identity. You probably don't need more than one or two identities (maybe personal and work). You can just get a couple of YubiKeys and configure the OpenPGP applet, or the PIV applet, with an authentication key/certificate and use that for SSH. Take the token with you and you've got some pretty strong authentication.
More modern SSH servers will let you use U2F security keys in the same way, which are cheaper than the full YubiKey.
I've learned recently that YubiKey has really good documentation for how to set up their tokens to achieve different goals, it would be worth reading their docs if you're considering getting a hardware token for your keys.
private key never leaves the device it is on; public key is .. well public so not something to store in a password manager. If the device is replaced, you create a new ssh key pair or restore your old one from a backup. In case your device is stolen/lost, you revoke access by removing the public key wherever you used it. This too is something a password manager can't do for you. If you are in a cloud environment, you let it manage keys for you. E.g. we don't provision any keys to GCP vms and instead login via a gcloud command that provisions temporary ssh credentials.
In short, I see no need for using a password manager for managing ssh keys. The public key is not something that needs protecting. The private key is something that you should not share between multiple devices or generally pass around.
But of course being able to paste your public key from some tool is nice if that is a regular thing in your life. And if you switch between multiple key pairs, it's probably nice to have something more user friendly than very fiddly command line tools. I guess the latter is what 1password is trying to solve here.
Look into SSH certificates if you control the server, it's much better than littering public keys everywhere: https://smallstep.com/blog/use-ssh-certificates/ Hashicorp's Vault provides a CA for SSH keys along with all kinds of other secrets and such, it's very commonly used in the industry.
I don't know is that's "correct" bit what I use is KeePass with the KeeAgent plugin, which acts as an SSH agent.
The keystore is stored on a nextcloud instance which allows to share the key easily between multiple hosts. It works flawlessly with git, ssh, also Windows tools like Putty will pick it up.
hmmm.... this could make me move from LastPass to 1Password... after krypt.co got bought by Akamai and discontinued work on their developer stuff, i have been looking for a better way of managing SSH keys... this might be it...
I use both, almost daily (paid versions) since ~2015ish. IMHO, 1password is way better than lastpass. That being said, lately 1password has shifted some of their focus towards more enterprise features (secrets etc.) so I don't know for how long my opinion will remain valid :)
If you're considering a migration anyway, I recommend you give KeePassXC a try before paying for 1Password. It also serves as an SSH agent. I haven't upgraded 1Password since they became a subscription model, so I'm not sure how it stands now, but KeePassXC was an upgrade for me. The browser integration is more configurable and I have fewer instances of not being able to use the auto-sign in with certain sites. Strongbox on iOS works beautifully with KeePass, and found it to be just as good as the 1Password iOS app too.
I would second this. Keepass also has an ssh key agent plug-in which works great. I’d say it’s even better than the putty key agent since you are notified when keys are used.
It looks like 2fa is not required for 1password, and also that even if you did enable 2fa you can only use TOTP. Both TOTP and passwords are vulnerable to phishing as there's no cryptographic protocol going on there, you are just typing in the numbers from your phone.
This seems like an excellent way to ensure that you reduce the security of your SSH login to either having a single-factor (password) or at best single-factor + TOTP, where you previously had a phishing-resistant cryptographic protocol.
Is this really an improvement for security, or is it just a usability improvement (i.e. sync of keys) intended to work around policies trying to improve security (i.e. required use of keys)?
(The other option is I skimmed the docs badly and maybe I've misunderstood something, it's possible.)
1p has some native support for hardware keys (https://support.1password.com/security-key/), but you can always use Yubico Authenticator for any applications that force you to use TOTP.
I see. They didn't mention it on the two factor authentication page I was reading because they've split the security key and TOTP documentation and not made it obvious (enough for me to see it while skimming) how to find the former from the latter.
1Password is different than other password managers in that it bakes in a form of 2FA via it's secret key. However, it's not quite the same as normal 2FA like TOTP since it doesn't change - but, it's also never transmitted over the wire like normal 2FA. We found it's good enough for our needs to not require 2FA on top of it.
Whenever I hear "oh but this 2FA is vulnerable to phishing" then why did security people annoy everybody and pushed for it before considering this factor?
I'm happy to use only a password for some sensitive things, because I can remember it.
Of course security is a spectrum and 2fa does help for a lot of stuff. Especially against websites that don't know how to hash your passwords properly (usually the ones from where passwords leak the most).
I was going to comment something similar - I think the messaging around this needs to be more clear. It feels like I’ve been seeing serious security folk push the unqualified use of password managers for years now. Better hope granny never needs to use SSH.
I literally just enabled this 1 hour ago, for unrelated reasons.
However, for those reading along, initially the 1Password web interface for my account only offered the choice of setting up a TOTP authenticator. I completed that, and still saw no option for enabling a FIDO/YubiKey device. I then went into the 2FA settings for my account, toggled the option for YubiKey support off and then on again, and returned to the 2FA settings page. Only then did I see the option to enable a YubiKey.
I was then able to add my YubiKey and I can confirm that it's working with my 1Password account as a 2FA source.
How does it work with with `~/.ssh/config`? Mainly, say I have keys in the vault for many machines, if they all get added to the 1password ssh-agent sock, won't you get "Too Many Auth failures", unless there is a way to pair the key to a `Host`? Maybe `~/.ssh/config` can pair keys to a `Host` by fingerprint instead of file?
This is 1Password 8 dependent, so unfortunately I doubt I'll ever use it.
The 1Password 7 app on macOS is a beautiful native app. It "fits" in macOS, it follows macOS design paradigms.
1Password 8 does not. It is a weird self-designed UI toolkit that is well inside the uncanny valley scenario - it is a UI design that feels like it is trying to approximate all of the major platform desktop UIs without committing to actually feeling like any given platform - so it feels wrong everywhere. Honestly it would be better if it was totally different to any of the main platforms instead of vaguely approximating them. I don't care what devtools or toolkits they use to achieve what they do, I care about the end UI feel, and it's just awkward on all platforms to me.
Additionally, 1Password 8 removes the single most used feature for me - 1Password Mini - and replaces it with Quick Access. Quick Access is much more awkward to use, especially with a mouse. Everything with Quick Access involves more UI interactions than it was before. The reasoning for this is that it "feels weird" to implement parts of the app twice - but for me 1Password Mini is essentially a browser extension equivalent for every other app on your system. Quick Access is an awful replacement for that.
I really prefer 1Password 7 on macOS to 1Password 8, and I honestly prefer it on Windows too. The replacement of native apps with something that really feels like a web page in a window - with issues like context menus being stuck inside the window, or web-page style modals - is just not what I expected, and it's not what I want. Yes, it lets AgileBits bring updates to platforms more quickly because it's essentially the same backend & UI on every platform. However, as an individual user I don't need more from my password manager than 1P7 already does.
Sadly, it seems the target for AgileBits (especially with the influx of VC cash) from the outside at least is just growth and the big payouts that come from enterprise deals - individual user usecases don't matter any more. Just look at how much of a production they made out of restoring categories as an option to the sidebar. And their core featureset - form filling - is less reliable than ever for me.
I feel that there's absolutely a hole in the market here for a password manager product aimed at individuals or small families that works on at least macOS, Windows, iOS and Android - and feels native on each platform.
edit: oh, and I utterly abhor the 1Password PR style - trying to make things seem weirdly casual on serious topics, but especially the misdirection/redirection approach they always take to critiques or support queries. Just look at their support forums for any thread on purchasing standalone licenses - they always drive the discussion into "isn't our online product amazing?". Critique of features in 1P8 always becomes "but for me it's amazing" in some way. It's frustrating as hell to engage with as they never seem to actually accept criticism in any way without trying to redirect it to something somehow positive.
My public ssh keys go quite a few places. I hope this can help me keep track of where I’ve uploaded my pubkey, since then revoking the pubkey is much more efficient. Or even do it for me, automagically.
A simple wrapper around pass might do the trick. Someone just needs to implement an agent that does this (tho I'm sure someone out there is working on it).
I stopped using SSH keys to authenticate against GitHub years ago and switched to HTTPS authentication. It's super convenient to set up with the GitHub CLI: https://cli.github.com/manual/
Is there any advantage of using SSH keys to authenticate against GitHub?
I just wish they would implement the ability to disable 1Password for certain domains or even just local host (talking about the browser extension here). There is a menu option in the right click menu but it only works for a short duration and isn’t configurable ahead of time.
I've been using 1Password for years now, the auto-fill always works. I don't use their command line stuff much, and I have some read some legitimate criticisms about how they communicate secrets on unix-like systems. Apart from that, I'm not sure I understand the dissatisfaction in the comments. Can someone enumerate what's wrong with 1Password? Are tools like BitWarden any better?
I think the majority of it is down to the pre-SaaS customers of the product. 1Password used to have a life time license and would work without any need for 1Password servers. You could backup your vaults anyway you wanted and the various clients would work with a variety of methods for syncing etc.
A lot of long term 1Password users bought this and still use it, but the company no longer really do much to support it having pivoted to completely focus on their subscription offering. Many of their long time customers, many of which are HN users, feel they're getting shafted by the lack of updates etc to those older offerings. From what I understand a lot of the older clients and plugins that worked with the local versions don't get updated anymore. However, I'm only a customer of their subscription offering so someone else might be able to elaborate more.
Ah, that makes sense honestly. I bought their lifetime license and I'm a subscription user. Kinda sounds like the right thing to do is refund the lifetime license holders if they've changed architecture and direction that drastically.
That would probably be the consumer friendly approach, or at least some kind of life time discount on the subscription platform. At the same time, a perpetual license is typically for the version you buy and that's it (old Adobe or MS Office approach) so I can see the argument for "you got it, and can still use it".
As someone who moved from LastPass to 1Password (after they aged off the lifetime license) though I'm happy and given their growth I'd imagine most of their customers are happy enough with it.
The point behind all ssh-agents is to prevent any application with access to ~ being able to read your ssh key and exfiltrate it somewhere, or simply using it to drop malware on hosts listed in your ~/.bash_history. If it's in an agent and that agent requires user interaction before it performs SSH logins, you'll be made aware of the malicious activity.
It appears you need to have Beta 8.6 to use this. I was on Beta 8.5 on macOS, and autoupdate did not find Beta 8.6. After installing 8.6 manually, the instructions worked.
I've stopped using 1Password everywhere I can due to their product "focus", and am working my way through a set of alternatives (currently using Secrets on the Mac and looking at the KeePass ecosystem, which keeps improving monthly):
Edit: It's been fun watching this get upvoted and downvoted in successive waves - for those who are curious, I suggest you check previous posts on 1Password and see if you can spot patterns in their advocates, since they were publicly called out on this a few times already (especially on Twitter).
I started using it back when because it just worked and I could keep my passwords synced between devices (windows, iOS and Mac) via Dropbox. Before that I used KeePass, but its Linux and Android clients were terrible.
I still have 1password 4 on Windows PC and (apparently) version 7 on Mac; they still work together, but I'm afraid at some point they will decide to drop support for dropbox and force you to use their subscription.
I'll stop paying for Dropbox and using 1password on that date.
(does Syncthing work on iOS devices? I'm not sure yet how to keep my passwords synced across devices)
Frankly I'd rather pay for 1Password sync that have Dropbox installed on my machines anymore with all the low-level hackery and product shenanigans they've pulled as the internal pressure to "innovate" and move up market has taken hold.
I'm also worried about 1Password in the long-term with this recent VC investment which likely will create the same kind of pressures, but for now they still have the best product in the space by far and I'm in no hurry to switch to an inferior product in order to save $3/month.
That's reasonable if you don't already pay for any cloud synchronized storage solution.
But many of us already pay for cloud file syncing across our devices and 1Password's previous solution worked just fine. Having it removed so they can charge their SaaS fees feels like a blatant worsening of the product.
"Blatant worsening" is overstating the case a bit IMHO.
I understand how you could object to the pricing model. I understand if 1Password sync works worse than whatever file sync you have (in my experience it's been better than Dropbox but YMMV).
However I don't think a unified data sync that all your apps plug into is some kind of unassailable product high ground. The tradeoffs for this are numerous and not always good, starting with the basic limitation that you now have a single type of sync semantics that operates at file granularity and can not optimize for the domain. Personally I don't see the huge value of having an encrypted binary blob syncing through my one-true-sync-solution—what am I gonna do with that file outside of 1Password anyway? To take some other examples I am perfectly happy to let Apple sync my Contacts and Google sync my calendar and email, and I don't object to paying for those things if they bring me significant value. It's not like I have 100 SaaS subscriptions, but 10-20 sure, and I'm happy to pay a fraction of what I pay to heat my house or streaming subscriptions in order to support solid development and maintenance of a handful of critical apps and services I use.
To be fair I'm not familiar with the dropbox+1pass combo solution you're referring to, but I imagine that the people using that solution are in the minority and that by focusing on one unified solution and not spending time supporting an old one probably provides net positive experiences across their product.
I kind of agree that if it works and it's in place just leave it be, but if it needs maintenance time, support time, and even development time as the product evolves then I can see the "business folks" pushing for the removal of those features so the team can focus on what more people are using.
The same, but with syncthing, I don't really see the utility of giving 1password or any company my ssh passwords or my passwords, like they're there for anyone to attack
Secretive doesn’t work if you have existing keys that you want to use from an agent, and it can’t act as a regular agent. It _also_ does not work for Git signing via SSH key, if I remember correctly.
If _those_ issues could be fixed, I’d probably use Secretive. Unfortunately, it broke almost all of my workflows when I installed it and it appears that the choice to use Secretive is all-or-nothing.
I agree. They disabled 1Password for Firefox on iOS and force users to use safari with 1Password extension. Before you could access it through share menu and get forms filled out, but they removed that feature. Reached out to support regarding that and their answer was just to use safari.
I use iOS, Firefox and 1Password to fill out passwords regularly. I just logged out of HN and back in on my iPhone just to test. Is there certain versions that this affected?
There is no extension to use 1Password with FF on iOS. iOS recognizes 1Password as part of the normal password system on the device. I, and others in this thread, have no problem doing so.
Did you mistype $2.99? Because it's $2.99 for one person. The $19.99 is for ten team members using the business product. A family of 5 gets it for $5 per month.
yes, sorry my bad. It is $2.99. By default pricing page goes to "Team & Business" tab. I need to select "Personal & Family" for the price I was looking for my use case. Thanks!
And here I am, logging into Linux boxes without entering passwords nor SSH keys thanks to the magic known as Kerberos.
Open up my corporate laptop and login with my smart card and username/pass combo, then I can just log into any Linux machine I have authorization (group permissions) to. Been doing it this way for over a decade at this rate.
It's like all of these password manager tools were created by people who've never seen nor used these existing solutions.
Lol. Kerberos? Smart cards!? What if I have less than a full team of full time employees able to be put aside to implement a solution? I, as a developer, could integrate 1Password’s solution in my org in an afternoon. Enterprise tooling isn’t for everybody. That approach is what gave us the needless proliferation of Kubernetes.
>What if I have less than a full team of full time employees able to be put aside to implement a solution?
This used to be something a middling UNIX sysadmin could configure and manage. You can also pay for someone to help you implement/manage a solution for this. Though I admit it may be overkill.
> It's like all of these password manager tools were created by people who've never seen nor used these existing solutions.
Maybe, but it sounds like your comment was written from a place where you've never had to actually implement one of those existing solutions.
Kerberos is great. It's also a holy terror to implement properly, especially cross-platform, and especially if you need to federate identity.
I've been down that path. While there are trade-offs with any decision, I wholly understand why so many organizations are going to solutions like Okta/Auth0 + Duo + password managers vs the "tried and true" methods of a directory server + Kerberos + SAML federation through Shibboleth
SCIM combined with modern cloud SSO makes life much easier than trying to support Kerberos.
Genuinely curious, where do you store your passwords and sensitive info like SSH keys?
I hear a lot of "cloud password managers are bad!" but I rarely see someone follow up with a better approach. Even better to them.
I've been using a password manager for years and I've always thought I was making a good decision but then I see all these comments and I wonder if I'm missing something.
I don't store them anywhere. I don't need to remember my passwords, they're the results of functions based on logical deduction and observation within the context of the "thing" I need the password for.
And my passwords are all, without exception, beyond 10 characters.
You're not missing anything—some people just like to grumble. I've never seen anyone come up with a reasonable alternative that isn't "rely on your own faulty memory."
Okay, so you're an asshole. Let's set this straight.
I don't store my passwords anywhere. I don't need to remember my passwords, they're the results of functions based on logical deduction and observation within the context of the "thing" I need the password for.
And my passwords are all, without exception, beyond 10 characters.
That's still a password manager. GP was asking what alternatives to the entire class of applications exist that provide equivalent security for unique passwords and keys
Information security is nearly always about trade-offs and this is no exception.
What you give:
- a single point of failure (one complex password you memorize that locally unlocks a DB of credentials that is stored encrypted in the cloud).
What you get:
- all passwords are unique and complex (assuming you use a password generator, which all these tools have built-in)
- the convenience of having all your passwords ready for use on any of your devices
- the convenience of auto-fill
- the convenience of being able to share logins e.g. a spouse or across your organization.
- the convenience of being able to also store, share, and auto-fill secrets besides logins (identities, credit cards, free-text notes).
Been using a password manager for 15+ years and I have never suffered fallout from the single-point of failure tradeoff, only benefits from the power and convenience I got as a result.
My SSH key and passphrase are the holy of holies security wise. It's such a simple, mature, battle tested, open solution. Why would I put that in a proprietary opaque solution that has had multiple recent serious vulnerabilities?
And why would I replace the openssh agent with 1password agent?
They don't even offer additional functionality over the open tools. "Autofill public keys in your browser for Git and other cloud platforms" - really? cat and copy - paste is now too hard?
(the above logic is why I don't make any serious money)
EDIT: Never mind. I misread and thought he was talking about password managers in general, not specifically for public keys.
> They don't even offer additional functionality over the open tools. "Autofill public keys in your browser for Git and other cloud platforms" - really? cat and copy - paste is now too hard?
In the case of browsers cat and copy/paste is often more risky than having code such as a password manager fill the fields. Password managers are less likely to be fooled by sites using tricks with their names to pose as other sites.
If you are sufficiently careful to be sure you will not be tricked by phishing attempts then cat and copy/paste should be fine.
> Why would I put that in a proprietary opaque solution that has had multiple recent serious vulnerabilities?
Can you share some info on those serious vulnerabilities?
> They don't even offer additional functionality over the open tools. "Autofill public keys in your browser for Git and other cloud platforms" - really? cat and copy - paste is now too hard?
So they don't offer any additional functionality except for the functionality that you don't think is worth it?
I have no idea why you're getting downvoted. I don't use 1password for anything and I don't recommend anyone use it for anything.
I will never use a 3rd party service to manage my passwords or key phrases. And why in God's name are people generating SSH keys in the browser?
The thought of using it for SSH or GitHub just sounds insane to me. And as you say it doesn't even really offer any benefit over cutting and pasting from the CLI.
They're being downvoted for making unsubstantiated claims about security vulnerabilities, and for not understanding the benefits of avoiding copy+pasting.
> And as you say it doesn't even really offer any benefit over cutting and pasting from the CLI.
It saves you from the fact that every application on your system, and some browser extensions can read your clipboard silently with no way for you to know. It saves you from phishing attacks from gіthub.com (note the i is a cyrillic i), it saves you from misconfigured permissions on your ssh folder, and from any "nosey" pip/npm install scripts that you might run on your development machine. It also means you don't lose your ssh keys in the case of data failure.
The items in its database let you define custom fields for them, but there is no literal multi line text field. There's a "File" type, but you can't simply define fields with multi-line text values. However, every item has exactly one built-in "notes" field, but that's actually styled markdown text. And you only get one. And its name is always "notes".
It would obviously be extremely useful to be able to define an arbitrary number of arbitrarily labeled multi line text fields that are not interpreted as markdown text.
It boggles my mind that 1Password doesn't support this. What were they thinking??? It makes it a real pain in the butt to store ssh keys and certificates and a lot of other types of information in 1Password.
A single markdown "notes" field just doesn't cut it. It's not as if it's technically challenging or a security risk. It already has a "notes" field, so just turn off the "rich text" feature and allow me to make my own! I would have thought it was a pretty obvious and often requested feature, but as far as I can tell, it's impossible!