Password managers

>--s2k-mode and --s2k-count
I'm not following. These mention symmetric encryption, not asymmetric encryption.

>leaking entry names on file system
True, but you can use a tomb [0].

>RCE by using git hooks
This is a well documented *feature*- not a *vulnerability* that can be exploited to gain RCE. There are no default "RCE hooks" when you use Git. Just pay attention to whatever hooks you set. This is within your own control, much like how you configure sudo access, for instance.

>text files
Not really a security issue? You want to use a sqlite file?

>swapping editor or shell memory
How would you mitigate this? IMHO, this is just a matter proper system security. Lock your screen, install sec updates, minimise listening daemons, etc. If your editor is broken, fix the editor. This isn't pass' fault.

[0] github.com/roddhjav/pass-tomb

>I'm not following. These mention symmetric encryption, not asymmetric encryption.
asymmetric keys are encrypted with a symmetric algorithm. if the private key for your store is stored in plaintext then you may as well just vim ~/passwords/Jow Forums-pass on your box and skip the crypto entirely. secure against adversaries who only have a remote copy, still not optimal design.
>This is a well documented *feature*- not a *vulnerability* that can be exploited to gain RCE. There are no default "RCE hooks" when you use Git. Just pay attention to whatever hooks you set. This is within your own control, much like how you configure sudo access, for instance.
>store password-store on cloud storage because you have multiple computers
>attacker pwns server
>sets hook
>you sync to ~/.password-store
>hook runs
repeat after me: my password database shouldn't be able to execute code if it's tampered with, even if your workflow isn't what the author suggests.
>Not really a security issue
I didn't say it was, only that it becomes a mess easily if you have multiple attributes to your entries rather than username:password, which most of mine do.
>This isn't pass' fault.
every other password manager mlockalls its memory and you sure won't see your entire password database in plaintext sitting in your swap partition for anyone to pilfer.

Lesspass just werks.

>privkey passphrase stored in plaintext nullifies your crypto
I agree, but this is not the default setting, as I'm sure you also know.

>attacker pwns server
Again, this is a matter of proper system security. It's *your* job to secure your server - not pass'.

>Can become a mess
This is not much different from exercising proper cable management in a wiring closet. Yes, it can get messy quickly, but only if you yourself are lazy.

>password tree in clear memory
I would advise everyone to use a tomb in this case. When done using pass, just close the tomb.

>privkey passphrase stored in plaintext nullifies your crypto
>I agree, but this is not the default setting, as I'm sure you also know.
I was suggesting that the weaker KDF on the encrypted private key compromises the security of the store similarly, although not as severely, as an unencrypted local private key does hence why the sk2 options were relevant.
>Again, this is a matter of proper system security. It's *your* job to secure your server - not pass'.
true to some extent but shit happens. I can't prevent someone from popping an 0day but I can prevent them from pivoting into my system though my password manager... by using something more robustly designed than pass.
>This is not much different from exercising proper cable management in a wiring closet. Yes, it can get messy quickly, but only if you yourself are lazy.
standardisation is never a bad thing and json/yaml is easier to manipulate than essentially writing and maintaining my own serialisation standard
>I would advise everyone to use a tomb in this case. When done using pass, just close the tomb.
as far as I'm aware this isn't the default config so it's an open security issue in my opinion. you can use what you will and decide what degree of security is acceptable and what is a non issue in your use case but those are the reasons I use keepassxc rather than pass.

>Weaker KDF
Ah yes, this was your original argument. I had to read up on this. I'm not sure why GPG (still) uses their s2k options as opposed to PBKDF2 or bcrypt. But I think the amount of iterations you can set with the s2k options would still be sufficient against brute force attacks. Still makes me wonder why not replace the s2k stuff.

>Pivoting through git hooks
True to some extent. The hooks will be executed under the user that interacts with Git, right? So, unless your user is root, has passwordless sudo, or other super user privs, the attacker would not be able to escalate to root.

And in order to place hooks, they already have access to your user. Because how otherwise would they set hooks if your Git repo dir is chown'ed by you? I'd hate to think your Git repo dir is world writable.

>standardisation
I agree standardisation is a good thing, but there's nothing stopping you from consistently using JSON / YAML syntax in your entries. I think this is a non-issue.

>tomb is not by default
True indeed, and I've thought about this as well. I would like to see tombs be merged into the main pass project. As long as this is not the default config, I can somewhat understand this can be perceived as an open issue.

>I would advise everyone to use a tomb
This would make browser extensions for pass ununsable, though, wouldn't it?

I'm not a 100% sure because I don't use browser extensions, but I would imagine it works for as long as the tomb remains open

>But I think the amount of iterations you can set with the s2k options would still be sufficient against brute force attacks. Still makes me wonder why not replace the s2k stuff.
it's secure enough for the foreseeable future but I wouldn't be comfortable putting it against an adversary with serious time and resources, say somebody with a grudge and a lot of AWS/Azure credit. adding bcrypt has been proposed a few times in the gnupg mailing list but it never got anywhere. I've skimmed the message format standard and couldn't see any obvious backward incompatibilities so I can only guess nobody cares enough to draft an RFC or implement it.
>The hooks will be executed under the user that interacts with Git, right? So, unless your user is root, has passwordless sudo, or other super user privs, the attacker would not be able to escalate to root.
you don't always need root to own something, say if you just want to ptrace firefox and steal cookies, connect to X and start reading window memory, get a reverse shell running, and/or add a fake sudo/ssh into their path to capture passwords. own the user and most of the time you own everything, at least on a unix system.
>And in order to place hooks, they already have access to your user. Because how otherwise would they set hooks if your Git repo dir is chown'ed by you? I'd hate to think your Git repo dir is world writable.
if you sftp, for instance, a file to a remote server it will create the file on the remote system as the user you're authenticated as by default your file will now belong to the user on the remote system although depending on what software you're using to sync permissions can be retained. if nextcloud can read and write on your behalf when you send changes to sync then an attacker who exploits your nextcloud instance should be able to too. this largely depends on use case but proper permissions could partially mitigate this issue as long as they're not root on the remote server, yeah.

>someone with a grudge and a lot of resources
This reduces the likelihood immensely, but that's not to downplay this issue. I do hope a more secure standard will be implemented, but it's quite sad to hear former proposals have gotten us nowhere yet. A new RFC draft would be my preference as well, but I have not looked into this.

>dont need to be root to pwn something
True, but to hook into your running application means the attacker has to be able to access it first. In other words, they should already have access to your user. For example, if an attacker pops a shell as your web server (e.g. Nginx), then they won't be able to write a Git hook in your repo just yet. Nor would it be possible to interact with running applications not owned by Nginx. Not unless they pivot around first, or escalate to higher privileges.

I do like the way you think, user. But abusing Git hooks is not a viable stepping stone in itself. Not unless the Git repo directory has improper permissions set, or can be accessed through any other insecure means. Whatever the case, it wouldn't be pass' or Git's fault. It would be the user's fault.

I'm thinking I upload my .password-store to say dropbox, dropbox gets fucked because some genius webdev decided to exec("ls") somewhere in their application code with unsanitised user input, or my credentials (normies reusing passwords, anyone?) get stolen to add a git hook script file to to the remotely stored directory, I then download and use that .password-store and then the malicious git hook script gets executed on my machine when pass calls git. it's not necessarily about the actual practice of attacking a remote server, just that copying a password store directory from an untrusted remote source may contain a script that will be silently executed. that git hook script now running on my laptop can do what it wants to as my user. it's outside of the use case of pass because git clone and pass clone, as you're supposed to use, doesn't copy over hooks because that would present a security risk obviously but cp /mnt/usbstickthatileftunattended/.password-store ~/.password-store could put you in for a nasty surprise. we're kind of arguing about details here and you're pretty much right, it's just the possibility of tampering in whatever scenario that makes me uneasy. I'm a little drunk here so we may not be on the same page but in any case I've appreciated your discussion.

Yubikey or gtfo

You can store your PGP key on your Yubikey, mate.

I am aware, it also works better than password managers

>download an inconspicuously planted Git hook by a 1337 evil webdev
Like you also identify, the hook won't get copied if you do a git clone. Only when you perform a plain copy (i.e. cp), yes. Maybe don't do that then, and stick to git clone? :p

I also appreciated the discussion with a fellow hackerman, cheers. Get some sleep.

Wait, a Yubikey is no alternative to a password manager

It complements it, does it not?

Yes, but complimenting != replacing

BitWarden
It good