The additional features this tool brings (port enumeration, list usb devices, system info), makes me thing the tool was not designed for good/ethical reasons, but to ease the life of infostealers that are usually distributed via Discord.
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.
There are a large number of similar projects out there.
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:
Is it even safe to use browser-integrated password managers? I think they're so much easier to use than external solutions such as KeepassXC, but if it's so easy to decrypt their databases...
Chrome uses it too. However the CDP protocol allows any local app to control the browser so you can use that to open the browser in windowless mode, examine the list of passwords at chrome://passwords, then open a bunch of tabs to all of those sites and extract the passwords from the HTML forms they get auto-inserted into.
Why is this surprising and why do you expect the situation with external password managers to be different? If you can decrypt it other software running on your computer can too.
A password manager integrated with the browser could be compromised by a vulnerability in the browser as well exploited by something running within the browser.
What is your risk model? An attacker who can install cameras in your house to see your PIN/password? An attacker with a blunt object and the clear intent to harm you if you don't unlock your phone? Your spouse who you trust enough to loan your device to look at a cat pic?
My threat model is accidentally installing malware that reads the database of my passwords. I trust my KeepassXC database because I use a strong and long password, so even if malware can read my KeepassXC file, it won't be able to extract the passwords. I feel like Firefox is not as safe.
Every KeePass-based solution I've tried was far from ready for normal users. Because they need browser integration out of the box, and it has to be smooth. Even BitWarden is still too difficult to use.
I never found a way to lock the password manager in Firefox with its own password. They probably aren't bad, but they are also way behind on features and general usability, as compared to standalone password managers.
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?
I would love to hear any suggestions for how to remove all my stored passwords in Firefox. I used to use Firefox password manager but moved to Bitwarden. It has been surprisingly difficult to remove passwords completely as I'm using Firefox Sync, and they just get restored from one of my devices.
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…
I don't know about the particular case of TripleDES+AES but I think in a general case you can't claim that A+B encryption is always at least as strong as B alone. The A part can result in e.g. first bytes of input being the same enabling a crib-type attack.
I would mostly say that it's just slow and AES is a much more modern and faster (partly due to hardware acceleration built into modern chips) that is already built info Firefox to support TLS anyways. There are some known attacks against 3DES now, but nothing that completely breaks it yet. And, since this is just for local storage, primarily, it shouldn't be as vulnerable as using 3DES for TLS channel encryption.
Is this some AI generated rubbish or actual code that works? If this is code that works, does setting a primary password protect against this decryptor?
Readit News
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.
Dead Comment
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 :)
https://news.ycombinator.com/item?id=41912226
E.g. on Windows, any program can access the entirety of the credential store for the current user.
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?
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...
What's wrong with it ? /s