On Tue, 2024-09-24 at 19:37 +0300, Greg Minshall wrote: > ... > let's say the only vulnerability were for Alice to crack Bob's master > ... > with lesspass, Alice can now go anywhere Bob has gone and log on. \
... > ... password-store, Alice also needs to access Bob's encrypted files > > the second thing that occurs to me is that the world of > multi-dimensional random number spaces can *very seldomly* have very > bad While the idea is nice in some ways there are some drawbacks. To add a little bit to Greg's security comments. lesspass is using "pbkdf2_sha256" for hashing. This is okay, but the state of the practice changes. The current preference is now argon2id. At some point you may prefer a different hash algo to create the pass. When that happens there is currently no nice way for app to generate old and new ones. This is in my mind another drawback to the generate/dont store approach. Worse what if the code stops working for some reason like pbkdf2 becomes deprecated (you know it will eventually). I think it would be better if there it had a way to update together with a mechanism to associate each generated password with the algorithm or application version that is used. lesspass is stateless, so it has no idea which version was used for any particular website. So it could be as simple as lesspass-v2 for the next algo - but that still burdens the user with knowing which version and doesn't deal with the case that your lovely v1 password not being generated due to hash deprecation. So I think the stateless aspect needs to be removed - in which case, maybe just choose one of the standard password 'vault' apps. -- Gene
signature.asc
Description: This is a digitally signed message part
