No ostensible security?

[rogerrohrbach]

Because the master key is never solicited, but rather read from a file, anyone who obtains access to my shell can access all my passwords. So, this password manager is equivalent, security-wise, to keeping a file of plaintext passwords on disk, with a file access mode of 600. Yes?

[biox]

anyone who obtains access to my shell can access all my passwords.

correct, and this is an intentional decision.

if an attacker has access to your shell, they could trivially install a keylogger & acquire your password the next time you type it anyways.

bad actor having access to your shell == game over.

i wrote a whole blog post about my rationale for this here: https://j3s.sh/thought/storing-passwords-with-age.html

if you want someone with more security credibility saying this, here are two quotes from Filippo Valsorda (a cryptography expert, and the developer of age):

Passphrase-protected identity files are not necessary for most use cases, where access to the encrypted identity file implies access to the whole system. However, they can be useful if the identity file is stored remotely.

One of my unpopular opinions is that if you are not aiming for hardware-binding and trust your storage, storing passwords unencrypted is fine. An attacker that can extract arbitrary files from my laptop must have already compromised me, and an attacker that has compromised me can just keylog whatever vault password. Anyway.

back to you~

So, this password manager is equivalent, security-wise, to keeping a file of plaintext passwords on disk, with a file access mode of 600. Yes?

no. the passwords are encrypted and may be uploaded to public services i.e. dropbox or similar - the passwords are secure. this is far more secure than uploading a keypass db or similar, which can be bruteforced. your encrypted passwords cannot be bruteforced (in any meaningful way).

you really want to put a password on your identity file & ruin all semblance of your user experience, simply do this:

age-keygen | age -p > ~/.local/share/pa/identities
age-keygen -y -o ~/.local/share/pa/recipients ~/.local/share/pa/identities

[rogerrohrbach]

Thanks for the clear response.

bad actor having access to your shell == game over

I was thinking of the scenario where my computer is lost, stolen or otherwise accessed in my absence. Should someone crack my laptop password today, they would not automatically possess all my Web passwords. I'd prefer that to remain the case.

[biox]

Should someone crack my laptop password today, they would not automatically possess all my Web passwords.

you should encrypt your hard drive for this purpose, which protects you from this, and secures everything else at the same time.

[biox]

sorry i don't mean to be declarative abt security - you should do what makes sense to you, probably :3 but imo, an encrypted hard drive + pa is a "good enuf" security footprint for most people.

[rogerrohrbach]

sorry i don't mean to be declarative abt security - you should do what makes sense to you, probably :3 but imo, an encrypted hard drive + pa is a "good enuf" security footprint for most people.

No, I appreciate the perspective. But FileVault on macOS decrypts for...whoever's logged in with my laptop password 🙃. So, while no one can remove the SSD and read it, I'm still back at "if they've managed to log in to my laptop..."

[biox]

if they can bruteforce filevault, they can bruteforce your identity file 😉 unless you set a very long passphrase on it, which would make using it almost unbearable 😢

[rogerrohrbach]

Fair point (I've an easily-typed, though reasonably strong, passphrase). Though I'm also hoping for some security-through-obscurity—it's unlikely a laptop thief will know about this password manager.

[biox]

fair! well, best of luck either way 😸 thx for the convo

[clydeconfigs]

you really want to put a password on your identity file & ruin all semblance of your user experience

have you considered adding a -p feature to pa, to use age -p and, when using pa, ask for the password and then store it in ram, so that it can remember it, etc.? it hurts to me too, to make such a minimalistic program bigger, but it's pretty useful if you are not using a encrypted disk

i calculate this feature could take around just 5 lines of code, so it's not that big of an addition though, only philosophically

[arcxio]

i calculate this feature could take around just 5 lines of code

I'm intrigued. I imagine we would need to have a daemon process to manage this stuff, which would blow up the complexity far beyond 5 LOC, but maybe I'm missing something. I'd say feel free to send a PR if you have a simple suggestion in mind.

[clydeconfigs]

(1) the idea is just store a prompted password

read -s password

into /tmp or /run/user/$(id -u)

echo -n $password > /run/user/$(id -u)/pa_pw

and then just access to it everytime you want to decrypt the age key

this, obviously, after a thing like age-keygen | age -p > ~/.local/share/pa/identities.age is done by deafult or optional

i don't know if age let's you input a password by reading a file. big issue if not (means the code should have huge structural change)

(2) relevant: another way of doing it is (which i like better), when booting pa, decrypting and mounting the decrypted $PA_DIR into /run/user/$(id -u) and reading it from there, so code of pa remains untouched because it points to variables like "$identities_file" which may be changed implementing this

consider the 2 ideas separately (and the second one is better impo)

i have no intention of contributing to pa since i have my own version of a password manager, so i find it boring to repeat my own project adding unnecessary features (to some) to something i won't use

the philosophical aspect of encrypting the database is not worth debating. it may give soooome security at some extent even if you have an encrypted disk, but whatever, i don't know

[arcxio]

one problem is that we can't have encrypted keys as an *.age file in $basedir because of this line for backwards compatibility that would move it into the password store. I suggested getting rid of it to @biox but still haven't got a response... we can store it with another filename or in a different location but both of those would be weird hacks.

[clydeconfigs]

i don't understand why that's an issue. the keys are already encrypted as .age, in my proposition, you just encrypt the main key in ~/.local/share/pa/identities

to do this you may encrypt the passwords folder, and just mount it when first using pa, for example like:

# "decrypt" would be any encrypting program, like scrypt(1), 
# which *must* allow to decrypt files using a password file
open_db() {
    ENCRYPTED_PA_DIR=~/.local/share/pa/encrypted.db
    decrypt $ENCRYPTED_PA_DIR -o /run/user/$(id -u)/decrypted_folder
    ln -s /run/user/$(id -u)/decrypted_folder $BASE_DIR 
}

[rogerrohrbach]

It took me a while to remember that I'd opened an issue here, hence the notifications I've been receiving of this discussion. I'm going to unsubscribe now, but: it seems rather unproductive for someone who's explicitly stated they neither use nor will contribute to this project to keep harping on how to improve it. 🫤 I'd say @arcxio is a fount of patience...

[clydeconfigs]

k then, sorry for making your day(s?) impossible to continue due to this insufferable notifications of unproductive content @rogerrohrbach