over the last few weeks, i've been studying password managers as i look for something new to move to, as i've gotten bored of each one in their own way. now, i'm gonna justify that statement by showing the designs and my personal notes of a few systems that can be taken to password managers. keep in mind i am no cryptography expert, and i'm just nitpicking :3
to summarize, very briefly, bitwarden stores the user's entries and metadata all in the form of encrypted data within JSON, each entry is stored as a member of an array. in rbw, the entire store is decrypted into memory, then the entry is searched for. which to me is expensive for a simple operation, which is why i believe that if the user wants a specifc entry, each entry is iterated, decrypted, and searched for if its the correct one, and discarded otherwise; probably isn't much better than the former, but atleast it is memory efficient.
additionally, in the official android bitwarden client, the encrypted store is cached alongside the private keys (in EncryptedSharedPreferences), used once user provides identity verification using a fingerprint. for example, in an open android application or on a website, and there is a field that is autofillable, if the store is not already opened, bitwarden will ask the user to verify their identity or provide a passphrase to decrypt the store (see below). once the store is decrypted, bitwarden will find a appropiate entry that matches the application or domain and provide it as an option to autofill. for autofill data, the entry includes URIs alongside android app names.
once the user provides a passphrase into any bitwarden client, the client will decrypt the store, and keep it viewable for some time. this is particularly helpful in a browser/mobile context.
this is a very simple designed but also terribly designed method for storing secrets. every entry is encrypted as a file, and the file has no standard for how it is written, which means you can put anything in the file:
The password store does not impose any particular schema or type of organization of your data, as it is simply a flat text file, which can contain arbitrary data.
this can be a little problematic for programs that want to display a view of a entry and be able to manipulate as necessary. usually the format for an entry is something along the lines of:
password
property: value
notes...
the filename can be anything as well, but it is usually a domain name and then
the encryption suffix (example.org.gpg). this means that it can work a little
nicer than Bitwarden to query, however, for autofill, in which the entries can
often be for many different URLs and applications, it is ineffective.
additionally, each entry isn't guranteed to be decryptable by the user. pass is simply a interface for just decrypting a plain text file, and the file can be encrypted by anyone. this may sound like a feature, but isn't exactly necessary for password management; it would be different if pass were to be used organization-wide, but lets be real; they would not be using pass(1).
disclaimer: i may or may not understand himitsu too well, i'm trying my best.
himitsu has a very intriguing, but nice design. the private key, entries, and
secrets are all stored in the himitsu store directory. the private key is argon2id
hashed, with a user passphrase. entries are stored as lines (encrypted) in an
index file, in a key-value format, and a key can be a secret, in which the
value can be a UUID-generated filename, which is stored and encrypted seperately
(with the same private key). for example:
# key
argon2id:...
# index (decrypted)
proto=web host=disroot.org user=sewn password!=276bc54b-45fc-446a-bc83-9a8463cad9f9
# 276bc54b-45fc-446a-bc83-9a8463cad9f9 (decrypted)
my password
something interesting of note is that a entry can be of multiple types. it can
be used to store web credentials, ssh credentials, and realistically anything!
and even making a proto key that makes it very easy to check, unlike pass...
however, for how the interfacing actually works, a himitsu daemon is required. the himitsu daemon provides an IPC interface to the storage, and once the user provides a passphrase (using the prompter_, the index will be stored in memory, and become queryable from a himitsu client. the reason the secret is encrypted seperately, is to prevent storing it in memory, as there is a daemon running that keeps entry metadata in memory.
to read a secret, a prompter will be used to ask consent from the user. i personally believe this is because any application can establish a connection to the himitsu daemon, and i also personally believe it is completely unnecessary and can be cumbersome to have to give permission all of the time. i mean, if a rogue program wants the private key, just add a keylogger. it's pretty pointless to have a consent system.
personally, i think the way bitwarden goes about storing entries is how i'd like it.
i simutaneously like and dislike the idea of a passphrase. for one, it can provide identity verification, but on the other hand, it can easily be overcome with a keylogger, which is why im particularly fond of age encryption. since, once your files are compromised, well, its much worse isn't it :p?
currently, i'm experimenting with looking for a new password manager. i've already made an android app and a linux cli for pass(1), but within the android app, as soon as i came the need to do autofill, i realize it might be better to redesign.
i think i am going to make a middleground between himitsu and bitwarden, where all entries are going to be stored line-by-line in a single file, and secrets stored seperately, or stored within the entry line.
i've wondered about making it himitsu-compatible, for one, i really like himitsu's design, but don't like the consent system. ontop of that, i think it would be nice if they had an android app to use :D