Activity for joint_striker
-
joint_striker posted a comment on discussion Open Discussion
The answer is: yes
-
That's a bit of a contradiction since you can still replace KeePassXC with KeePass, and vice-versa, but I assume that your primary concern might be plugin support.
-
Sort of, but you still need a malicious plugin, which will eventually be catalogued as malware by security solutions, whereas the passwordless export was a matter of just changing text without running any extra code.
-
Sort of, but you still need a malicious plugin, which will eventually be catalogued as malware by security solutions, whereas the passwordless export was a matter of just chngong text without running any extra code.
-
What is funny is how you bend the parameters of your argument by constantly moving the goal post. There is an ocean of difference between a backdoor integrated in a trusted software solution, which won't need code execution, evasion nor concealment, and an actual piece of catalogued malware that will trip as many alarms as the system has. It's not just a matter of perspective, you're just in denial mode still.
-
You can. Whitelist by signature, block everything else.
-
KeeThief... what a joke
-
Changes from 2.53 to 2.53.1: When testing a KDF ('Test' button in the database settings dialog), KeePass now spawns a child process that performs the KDF computation (which allows to cancel the test more cleanly in the case of excessive parameters; security is unaffected, because dummy data is used for the test). Removed the 'Export - No Key Repeat' application policy flag; KeePass now always asks for the current master key when trying to export data. Minor other improvements.
-
It's more like a useless feature that none asked for nor uses, unless out of their minds (unsecure bullk export of credentials), which is being shilded from sensible criticism based on retrograde convictions about the practicality of security, nothing but theory. Shouldn't take long for another wizard drop another quote from the Immutable Laws of Security.
-
Also, that's not the claim.
-
This is exactly what a backdoor looks like. And the fact the developer is hiding behind plausible deniability, shows that it is very much intentional. There’s little point in hyping about how it will take thousands of years to brute force the master password, if all it takes is someone armed with Windows Notepad to bypass it. Someone being able to silently export the user’s entire password database to a plain text file when a user unlocks their password database is not a useful feature. I guarantee...
-
I dont think that the installation should modify the permissions of the install dir. As for the enforced config, it's better than nothing but still a cop-out. If ACL policy and enforced config are enough, then there this is a non-issue. The whole debate is predicated on the assumption that write privileges are sufficient/insuffiscient to prevent config.xml being used as a backdoor.
-
This goes a bit like the Windows escalation techniques, by accessing the filesystem without the OS running and replacing logon accessibility tools like utilman, osk, sethc... it took nearly 2 decades for Microsoft to acknowledge that it could mitigate the problem by implementing some basic preventive measures, through Windows Defender in that situation, while third-party security solutions did nothing - understandably so. KeePass's credentials extrafiltration by way of the config file is essentially...
-
This goes a bit like the Windows escalation techniques, by accessing the filesystem without the OS running and replacing logon accessibility tools like utilman, osk, sethc... it took nearly 2 decades for Microsoft to acknowledge that it could take basic some preventive or mitigating measures using Windows Defender, while third-party security solutions did nothing - understandably. KeePass's credentials extrafiltration by way of the config file is essentially the same as Utilman.exe. Is it a security...
-
What I meant to say is that with the config file you dont need to access the user session (which probably you don't to install add-ins either), you don't need to run any code, and you dont need to worry about evading security software.
-
KeePass vulnerability doesn't even need access to the user profile, only write access to the config file. Hardly the same thing.
-
One should be able to express an opinion without resorting to petty insults.
-
A big shout to Thomas J Howard for summing up nicely the current threat that KeePass represents to itself and most of its users. It captures perfectly my thoughts on the matter. On the other hand, props to my man Dom for having a security ideology more hardened than his own implementation of the subject matter. What a legend... In the past I tried attacks against myself and I kept getting tripped by some or other security feature in the system (noob me, I know), but now I see how the config file...
-
-
-
I never even thought about running KeePass elevated as an added layer of security, thanks for the tip - will do so from now on. That being said, I have become more focused in the security aspect of KeePass in the past 3 months. I've tried to make it as hard as possible to have it open when not required (enter master key on secure desktop, lock/quit after x minutes of user or app inactivity, also on user or session switch, etc). Thinking back to what you mentioned, you are absolutely right, if an...
-
There are some edge cases where the attachments may be more useful if open with the internal text viewer, without having to use external resources or extra steps, that's why I mentioned "Custom Fields" which was implemented to expand on the existing in-memory protection given to password fields; the difference is that it supports single line fields and not attachments, regardless of their size. Honestly, I think KeePass should offer native support for what KeeParanoia appears to offer, with due constraints...
-
Pretty cool, this was what I was looking for. I'm obviously reluctant to use it live due to the lack of extensive testing, It's a pity that these features are not natively offered within KeePass already. The few tests I made worked fine, but I have to ask, do you use your own plugin on a daily-basis? Have you come across any kind of data corruption while using it? What do you imagine to be scenarios where problems could arise? I'm not very keen on maintaining 2 databases long-term, but I might just...
-
There are some edge cases where the attachments may be more useful if open with the internal text viewer without having to use external resources or extra steps, that's why I mentioned "Custom Fields", which was implemented to expand on the existing in-memory protection given to password fields; the difference is that it supports single line fields and not attachments, regardless of their size. Honestly, I think KeePass should offer native support for what KeeParanoia appears to offer, with due constraints...
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in your linked description, the reason is performance. I wasn't aware despite having being using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact on...
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in your linked description, the reason is performance. I wasn't aware despite having being using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact on...
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in your linked description, the reason is performance. I wasn't aware despite having being using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact on...
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in the descriptions you linked, the reason is performance. I wasn't aware despite having being using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact...
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in the descriptions you linked, the reason is performance. I wasn't aware despite been using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact on performance....
-
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in the descriptions you linked, the reason is performance. I wasn't aware despite been using the app for almost a decade (although obviously didn't do a thorough enough reading).
-
Indeed, I seem to have confused this with process memory protection, and as is pointed out in the descriptions you linked, the reason is performance. I wasn't aware despite been using the app for almost a decade (although obviously didn't do a thorough enough reading). Would it be possible to have something like a "special" flag where you say "this particular attachment is sensitive, must be encrypted/decrypted on the fly"? That is, within reasonable performance parameters to limit impact on performance....
-
Sorry for necro-ing... this doesn't seem to be true for when the database is open. Is there a reason why attachments are unencrypted when the database is open? Performance maybe?
-
I was puzzled myself about the project's development. Thanks for being so open and honest about your private situation. I hope you the best.
-
May be unrelated because I don't have disk encryption, but I had a very hard time updating to 1903, was constantly getting the error 0x80070002. Using the Update Tool or the Media Creation Tool gave me a somewhat different error though: "Something Happened. We can't tell if your PC has enough space to continue installing Windows 10" After searching for reasons related to that last error (apart from not actually having enough space, which wasn't the issue), I found a thread somewhere where it was...
-
Removing the quotes from the text file does solve the problem, but as I mentioned...
-
Issue parsing file list containing quotes
1
