I want to like cli based password managers but in 95% of the cases I need the password in a browser, not my terminal. I use a clipboard manager that keeps history of things I copy & paste (I cannot live without one tbh) So I would end up having all my passwords in plain text in the history of my clipboard manager. That seems like a net loss in security to me.
Similarly I also like CLI password managers but I need to be able to use them on my phone as well as my computer. I used to use Termux and run anything I wanted, manually syncing the password files. But recently I realised Termux takes up so much of my damn phone storage… Its not worth it just to run a shell script or a small program.
Which sucks. I wish there was a lightweight way to run a small Linux environment - maybe alpine - on android without taking away my precious local storage.
I’ve written a small utility based on rbw and ydotool that just types in the credentials wherever I want. ydotool creates a virtual keyboard and my usual usecase is 1. type username 2. press TAB 3. type password. Works across all the browsers and applications.
Maybe I’m being dumb, but how does the security of this work? I get that it generates passwords and stores them in an encrypted file, but where’s the master password for the encrypted file? Wouldn’t you have to enter that every time you ran the tool?
age uses a secret key to encrypt the passwords. You can optionally symmetrically encrypt the secret key with a passphrase (in which case you’d also have to provide this when decrypting, like with gpg), but this tool doesn’t do that. The author explains the security here: https://j3s.sh/thought/storing-passwords-with-age.html - essentially, the secret key is stored in the filesystem without encryption, but if someone gains access to your filesystem like that you’ve got bigger problems. You could easily add another layer by just symmetrically encrypting the secret key with anything - age, gpg, even ssh.
By default, therefore, this is just obfuscation - but you can also share the encrypted passwords around and get them on your phone for example, where the secret keys might also be stored.
The author explains the security here: https://j3s.sh/thought/storing-passwords-with-age.html - essentially, the secret key is stored in the filesystem without encryption, but if someone gains access to your filesystem like that you’ve got bigger problems.
I ask this is all seriousness. Why are the passwords encrypted, but the key is not? It seems to me the argument for “if someone gains access to your filesystem like that you’ve got bigger problems.” would also cover the passwords if they were stored in plaintext. Why encrypt one and not the other?
I gather the idea is because then you can upload the password files to different places but then you also have to move the key there. If the answer is you’ll move the key via a secure mechanism, you could move the plaintext passwords the same.
I like the idea of a good, CLI-based password manager. This seems like a fun package for a few use cases (including moving the passwords and keeping the keys on separate media or in a separately encrypted partition that is rarely mounted), I just don’t understand that design decision, nor a defense of it based on one file on disk being somehow more or less secure than the other file on disk when they’re all in the same home folder.
I’d love to see the Yubikey idea be a reality, that’s a great idea! I don’t mean for my reply to sound too down, I do think this is a neat package and wouldn’t mind using it for lower-risk passwords such as 98% of the websites that want me to create a login just to do business. Thanks for sharing this!
well stay tuned! :D it’ll probably happen just as soon as i get my hands on one. and no worries, i didn’t take it that way, but thx for clarifying your intent :3
if someone gains access to your filesystem like that you’ve got bigger problems.
You mean like if you download and run an app, or use a package manager to install and run an executable? Those have access to your filesystem. Heck, any time you run a makefile some shellscript gets access to your filesystem.
This isn’t security, it’s a toy.
Real password-storage systems like Apple’s Keychain take very strong measures to protect secrets even from local attackers. Master keys are never stored on disk, and never even resident in address space that can be paged out.
Probably on a security module. The key never leaves the security module, and all you are allowed to do is get it to encrypt/decrypt stuff for you. Basically every computer from the last 5-ish years has them, it’s even a requirement for Windows 11.
Real password-storage systems like Apple’s Keychain take very strong measures to protect secrets even from local attackers
pa is a password manager in the spirit of pass - but by all means, use whatever suits your own threat model.
This isn’t security, it’s a toy.
implying that pa needs to meet some arbitrary bar of yours in order to not be a toy is discouraging.
is keepassx a toy? how about 1pass? they both fail the filesystem access test, since an attacker who has compromised local storage could just keylog whatever they wanted anyway.
I want to like cli based password managers but in 95% of the cases I need the password in a browser, not my terminal. I use a clipboard manager that keeps history of things I copy & paste (I cannot live without one tbh) So I would end up having all my passwords in plain text in the history of my clipboard manager. That seems like a net loss in security to me.
check out some of the plugins in
contrib. My basic workflow is:it’s very fast - only a few seconds - and the password never touches your clipboard.
here’s my bind (i use sway):
bindsym $mod+p exec --no-startup-id pa-bemenuSimilarly I also like CLI password managers but I need to be able to use them on my phone as well as my computer. I used to use Termux and run anything I wanted, manually syncing the password files. But recently I realised Termux takes up so much of my damn phone storage… Its not worth it just to run a shell script or a small program.
Which sucks. I wish there was a lightweight way to run a small Linux environment - maybe alpine - on android without taking away my precious local storage.
I’ve written a small utility based on rbw and ydotool that just types in the credentials wherever I want. ydotool creates a virtual keyboard and my usual usecase is 1. type username 2. press TAB 3. type password. Works across all the browsers and applications.
I have been using
rbwin qutebrowser for a while, and set it up so it just callsrbw get <input>and stdout goes into the focused form field.I have TOTP set up in the same way.
Oh, rbw looks great. Thanks for the pointer!
Awesome, thanks for sharing!
ageis super useful for this due to its simplicity.I’m therefore also planning to add
agesupport inprssoon!Given this is POSIX shell and that at first glance I don’t see anything tying that to Linux I wished the was a better tag for this story.
I suggested a change
linux->unix.I think that makes sense. But maybe let’s add unix, to differentiate?
I also thing either that or something like tools. Then it would even cover situations where a tool also works on Windows (and Plan 9 or something).
makes sense to me!
Maybe I’m being dumb, but how does the security of this work? I get that it generates passwords and stores them in an encrypted file, but where’s the master password for the encrypted file? Wouldn’t you have to enter that every time you ran the tool?
age uses a secret key to encrypt the passwords. You can optionally symmetrically encrypt the secret key with a passphrase (in which case you’d also have to provide this when decrypting, like with gpg), but this tool doesn’t do that. The author explains the security here: https://j3s.sh/thought/storing-passwords-with-age.html - essentially, the secret key is stored in the filesystem without encryption, but if someone gains access to your filesystem like that you’ve got bigger problems. You could easily add another layer by just symmetrically encrypting the secret key with anything - age, gpg, even ssh.
By default, therefore, this is just obfuscation - but you can also share the encrypted passwords around and get them on your phone for example, where the secret keys might also be stored.
I ask this is all seriousness. Why are the passwords encrypted, but the key is not? It seems to me the argument for “if someone gains access to your filesystem like that you’ve got bigger problems.” would also cover the passwords if they were stored in plaintext. Why encrypt one and not the other?
I gather the idea is because then you can upload the password files to different places but then you also have to move the key there. If the answer is you’ll move the key via a secure mechanism, you could move the plaintext passwords the same.
I like the idea of a good, CLI-based password manager. This seems like a fun package for a few use cases (including moving the passwords and keeping the keys on separate media or in a separately encrypted partition that is rarely mounted), I just don’t understand that design decision, nor a defense of it based on one file on disk being somehow more or less secure than the other file on disk when they’re all in the same home folder.
I get your point, ty for the message. from my pov, encrypting passwords with keys provides the following main benefits:
on a related note, i plan to explore yubikey + age pretty soon, which probably means that
PA_IDENTITY_FILEwill become configurable, or similar!I’d love to see the Yubikey idea be a reality, that’s a great idea! I don’t mean for my reply to sound too down, I do think this is a neat package and wouldn’t mind using it for lower-risk passwords such as 98% of the websites that want me to create a login just to do business. Thanks for sharing this!
well stay tuned! :D it’ll probably happen just as soon as i get my hands on one. and no worries, i didn’t take it that way, but thx for clarifying your intent :3
You mean like if you download and run an app, or use a package manager to install and run an executable? Those have access to your filesystem. Heck, any time you run a makefile some shellscript gets access to your filesystem.
This isn’t security, it’s a toy.
Real password-storage systems like Apple’s Keychain take very strong measures to protect secrets even from local attackers. Master keys are never stored on disk, and never even resident in address space that can be paged out.
Yes, it’s not much local security. Personally I do encrypt the secret key symmetrically, which is a bit better.
Where are they stored?
Probably on a security module. The key never leaves the security module, and all you are allowed to do is get it to encrypt/decrypt stuff for you. Basically every computer from the last 5-ish years has them, it’s even a requirement for Windows 11.
pa is a password manager in the spirit of pass - but by all means, use whatever suits your own threat model.
implying that pa needs to meet some arbitrary bar of yours in order to not be a toy is discouraging.
is keepassx a toy? how about 1pass? they both fail the filesystem access test, since an attacker who has compromised local storage could just keylog whatever they wanted anyway.
you feel a little mean spirited to me.
This looks interesting—thanks.
There’s also Filippo Valsorda’s passage—a fork of pass, but like pa it uses age as a back end.
Gopass also supports age https://github.com/gopasspw/gopass/blob/master/docs/backends.md#crypto-backends-crypto