Say you're building a feature for a password manager to import passwords from firefox. You'd want the the firefox decryption functions to be available as library.
Or say you're building a tool to extract data from broken hard drives, partially recovered filesystems, etc. Again, you'd want to have this available as a library so you can import the functions you need and use them in your own tooling.
Normally you'd expect this package to primarily export a lib with a "cli" subfolder that provides a sample CLI tool that imports the lib.
The fact that this tool requires libusb which is solely needed for the useless list usb devices functionality is extremely sketchy. It makes using this tool legitimately harder and only helps attackers.
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...
Interesting, does this work on the latest releases? If so you might want to let this fellow know to adjust their threat model accordingly :)
E.g. on Windows, any program can access the entirety of the credential store for the current user.
One interesting thing I noticed is that Chrome and Firefox can also seamlessly see and use Passkeys I stored in Safari even if normally they don't read the passwords from there.
Using each passkey however still requires a fingerprint every time.
And of course, the external tool can have plenty of exploitable leaks unrelated to whether or not it’s integrated to some browser.
If the goal is to have better security, no method of using password alone will bring significant improvement to an authentication system, no matter how great the password manager it’s used with.
Which is why my password manager has zero integration directly with the browser, or anything else for that matter. There is a tiny little bit of extra legwork caused by this⁰, but IMO it is a good compromise between convenience and easily available attack surface.
----
[0] and it might be susceptible to attacks that manage to listen to the OS message queue & clipboard where a browser integrated method would not be, but once something is that far into your system there isn't much that is going to help you except maybe an orbital nuke.
The ideal amount of integration is actually non-zero. Manually copy-pasting passwords makes you susceptible to URL phishing, unless you also consistently copy from the browser URL bar into your password manager.
Given it can automatically insert passwords for a site, something in the browser can access passwords.
You can set a "primary password" for firefox's password manager, meaning that you first have to enter a password before you can access the stored passwords. That should provide equivalent security to using KeepassXC.
Wow. I've been using Firefox for 18+ years and I've never knew about this feature! Thanks!
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.
You're posture is assuming that if it doesn't matter to you, then it doesn't matter at all, and that simply is not true.
I'd love to see someone "hack" his book, it would be quite the impressive hack.
I have five passwords in my Firefox manager. (More if I include the ones which are no longer valid, like a few ftp passwords, and passwords to routers I no longer use.)
I think I'm safe.
I avoid online services which require identity as much as I can, because yes, any data builds up. Which means, yes, I buy things in stores, not online, I use cash, not credit/debit/e-cash, and I don't use apps.
If you do use online services, apps, etc., then it sure feels like you are assuming that information leak doesn't matter to you, so it doesn't matter at all.
Everything I post is with the knowledge it will be public, analyzed, regurgitated, and held against me in a court of law.
Hah. Don't bother us with your mumbo-jumbo, we're doing computer security here.
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?
which are in some cases better than your passwords (already passed 2FA, etc)
Another option is to delete your Mozilla account and recreate it, if you're not using it for anything other than Firefox Sync.
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.
If you set a master password, firefox uses that master password instead as input to PBKDF2.
But honestly I’d stay away from PBDKF2 at this stage. If you look at OWASP they recommend 600k rounds. That number is getting bigger and bigger all the time (10k rounds used to be enough over a decade ago)
https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
I would use Argon or scrypt (which is basically PBKDF2 in a loop with some weird mixes) instead.
What's wrong with it ? /s
Much better to just talk to others than use Google.
I've been experimenting with Kagi for those reasons (amongst others) and finding it works well. Far from ideal for all as it isn't free after 100 queries, but it seems to be a workable solution to the problem for me for now.
and Google and quora are in cahoots, right?
I actually read up on it quite a bit afterwards.
Feels very unwarranted to just assume laziness into a simple thank you for information spreading.