Best practise for encryption in a password manager I'm trying to make a password manager for Windows installed computers, and after researching the best ways to encrypt the passwords in the database (I'm new to cryptography) I think I've come up with a good way to do it, but I'm still not sure.
How the key is made when the user first opens the program:

The user inputs the master password, the password that will unlock the password database.
A random salt of 16 bytes and the master password will be put through a KDF (PBKDF2 using SHA512) to derive a key $k$.  $$k = \operatorname{PBKDF2-SHA-512}(password, salt)$$

How the database is encrypted:

Using the $k$, the database is encrypted using AES 256 bit CBC. $$ c = \operatorname{AES-CBC}(k,IV, database)$$

The $IV$ and the encrypted database $c$ are then encoded to base64 before store.


Where and how the database, salt (for the key $k$) and the $IV$ (for AES) are stored:

The salt, $IV$ and encrypted database will be dumped into a python dictionary, and written to a txt file e.g. {&quot;salt&quot;: &quot;T\x96\x829\xed\...&quot;, &quot;iv&quot;: &quot;00/JOAIsHs9XtB5acawBhA==&quot;, &quot;database&quot;: &quot;TE4nhDRTJ+JW...&quot;}

The decrypted database file is then deleted and overwritten with random encrypted data multiple times to properly wipe it.

This txt file is then encrypted with AES 256 bit CBC, the key is 32 random bytes which is then hidden somewhere on the computer (could this part be skipped?).


I would prefer if no external devices would have to be used to store the second encryption key.
Also, every time the database is decrypted, and then encrypted back again when the user is done, a new key with a different salt is produced, and a new IV for encryption is produced.
Is this how it's supposed to be done? Or am I completely wrong?
If the key is derived from the password there is no reason to store it anywhere.
The main problem in your outline is not the cryptography.
You are explicitly writing the passwords to disk. This is a really bad idea. The deletion may not happen at all, e.g powe failure. Even if it does on a modern hard drive it is really hard to overwrite data it won't actually be written to the same place and thus traces of previous data may remain.
A secure implementation will not only avoid writing to disk it would explicitly request from the OS to not swap out the sensitive memory parts. The OS may allow you to do this for only a small piece of memory. If the password DB is large decrypting the whole thing may be problematic and you should consider only decrypting the part you want but that causes a behaviour change you may or not want.
You may want an authentication if you worry about someone mangling your db.
You didn't mention IV selection, needs to be from a strong random source and replaced everytime you change anything and need to reencrypt.