If you have passwords that are used outside the browser, putting them into the browsers password manager, getting them out feels a little cumbersome.
Related to the tool: Why not just click the export button in Firefox?
Choose a password manager which you like. I like having a paper book with a dumb-ass encryption scheme, because my threat model is that I am not going to worry about physical attacks, and servers will detect attempts to brute-force the dumb-ass scheme by adding delays after the first few failures.
I use Firefox's manager for my Mastodon accounts, because no one cares for my 10 followers, and the instance manager can resolve things if needed.
Hah. Don't bother us with your mumbo-jumbo, we're doing computer security here.
I implemented login credential extraction for both Chrom* and FF-based browsers in the somewhat shambolic but generally-useful `browser_cookie3` Python module last year:
https://github.com/borisbabic/browser_cookie3/compare/master...
If you glance at the code there's a single "key encryption key" in the whole SQLITE file (in the 'metadata' table). That key is decrypted using AES with the PBKDF2 derived secret.
Then each password is in turn encrypted using TripleDES. The "data encryption key" for each these records is in turn encrypted using the aforementioned "key encryption key".
My suspicion is that the TripleDES format must be really old, and when they migrated the crypto layer to use AES they just re-encrypted the top layer (the "key encryption key" later) to use AES. It's much faster (and safer) to just re-encrypt all the TripleDES keys with the new AES than go and mess with "all" the records in the database. It's inelegant and lazy but you effectively get "AES level" of security without having to do all the work, so to speak…
https://github.com/Sohimaster/Firefox-Passwords-Decryptor/bl...
In this case, the only thing encrypted with TripleDES is the password itself, so the practicality of a crib or other known plaintext attacks is debatable in my opinion.
If you use the same (or similar) password everywhere, then you have bigger worries than Firefox use of TripleDES. Password stuffing based with leaks from poorly hashed password DB (cough facebook cough) is likely the most practical attack vector in this case.
If all your passwords are like q@qrG#Z4ARYm^qjeTEMN2Kh45v^p7L# then crib like attacks are impractical.
There are other weird/debatable choices in the Firefox encryption layer:
- Why bother with CBC? Things like AES-GCM or other authenticated* encryption mode would be nicer. Not sure it's a flaw here (google the cryptographic doom principle of Moxie Marlinspike)
- Why not wrap the encryption keys with some kind of "key wrap" mode instead. There are such things as AES-KV for instance.
- Why do the weird PBDKF2 derivation here? It's not based on a password the player enters, so there's nothing to "strengthen"? Seems oddly unnecessary (or I don't understand and there's a password somewhere).
- If there's a password then PBKDF2 is really really shit compared to scrypt or even better one the variant of argon OWASP said you should use.
What's wrong with it ? /s
Much better to just talk to others than use Google.
and Google and quora are in cahoots, right?
Please delete this project and your comment.
If you want to be helpful, write native code that user can read, compile, and install, and persistently use without risk of backdoor-out-of-the blue.
I wouldn't trust this page with my passwords either, but not because of the reasons that you mention. I haven't checked, but maybe it is simple enough to read the code in its entirety and then self-host? If so, nothing wrong with that.
But you need to make it easy to run on a local computer to convince the die hards. ;)
You created something cool and it pays tribute to a loved one.
Awesome.