61–70 of 209 posts
> As usual, we managed to get administrative access to the domain controller As usual? Is that the state of Windows Server security these days? I never managed a Windows-based network so I have no idea. I heard about these things back in the 2000's but I'm surprised this is "usual".
Earlier quoted context omitted.
>the attack already assumes access to the workstation of the victim I seldom can take "vulnerabilities" that require physical access seriously, because if a hostile is physically next to my computer I have more pressing concerns than some passwords.
Yes, it requires an attacker in a powerful position but it does not require physical access. Any program that runs in the user's session (without any special privileges) could have autonomously retrieved the biometric key and decrypted the vault without user interaction and without Bitwarden running.
I've always considered password vaults as a single point of failure that will compromise all of your passwords. I've had lots of intelligent, well-informed programmers argue that my concern is groundless.
Earlier quoted context omitted.
The problem is that an unsophisticated user doesn't necessarily think like that, and could come to the conclusion that it is not a big deal to leave his workstation unlocked while going to fetch a coffee, after all, well... "I have a password manager, and to have access to it, it requires unlocking". Then some colleague calls them for an ongoing meeting so they can share some insight about some question that was rais…
To this day I don’t understand how “computer repair” shops are in business. When I was a shithead 16 year old I used to work at one. I found it amusing to see what files people deleted before giving us full physical access to their machines. I definitely saw things I shouldn’t have seen. It wasn’t until I saw something illegal that I freaked out and stopped doing it. I was so paranoid that I srm’ed my entire drive an…
Earlier quoted context omitted.
>python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Yes, otherwise known as "if you run code on your computer, it can run code on your computer". If a random python program can "decrypt" the passwords, that's not encryption. And browser password management isn't about security, but convenience.
>if you run code on your computer, it can run code on your computer For the love of God will someone please just make a web browser that isn't a web browser and it's just a cross platform multimedia sandbox with a couple of APIs in it, and you can run programs written in rust or something on it, and it doesn't let the programs touch your file system unless it has explicit permission? That would solve 99% of the appli…
You cannot make a turing complete language that JIT compiles into machine code and verify it as "safe". Machine code is not safe, so anything that lets you generate arbitrary machine code cannot be proven to be safe. If you take away the arbitrary machine code generation from javascript, it's too slow to run the modern web.
Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few d…
"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…
I've always considered password vaults as a single point of failure that will compromise all of your passwords. I've had lots of intelligent, well-informed programmers argue that my concern is groundless.
I memorise good passwords for a handful of my most critical stuff (and have MFA). They don't go in my password manager.
If my password manager gets compromised then I probably could lose some cash, maybe get embarrassed by being impersonated on social media - it could get very inconvenient but not catastrophic.
Earlier quoted context omitted.
Full unrestricted disk access for all users and code isn’t the only way an OS can be designed.
AppData is specifically where apps store data, and there are and were plenty of legitimate examples where you want some code to access data from an app in there. The entire point is that it is not meant to be a secure location, was never meant to be a secure location, has no intended security features etc. If you store your passwords in a text file on the desktop, that is also insecure but you would be wrong to say N…
Earlier quoted context omitted.
>python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Yes, otherwise known as "if you run code on your computer, it can run code on your computer". If a random python program can "decrypt" the passwords, that's not encryption. And browser password management isn't about security, but convenience.
I tell myself and other people if you have it saved in your browser are you okay if bad people know that password. Also it makes it easy for people in authority to get to that password with a simple court order.
Also for most normal people, an unencrypted note on their desktop with plaintext passwords that are DIFFERENT FOR EVERY SITE is STILL more secure than the SOP of using one strong password for everything. For that to be compromised, someone needs to be able to run code on my local machine, in which case, they can just install a keylogger, so encrypted passwords are no increase in security. I genuinely don't care if App1 on my computer can fiddle with App2's bits, because I chose to run App1 and App2, they are trusted.
Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted. I also found a post of an admin a few d…
"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "ProgramData" is where application specific data is supposed to be stored. "Program Files" is where read-only application binaries and code is supposed to be stored. It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or…
Developers (including those inside Microsoft) don't give a damn about how Microsoft intends anything to work, and AppData has become a dumping ground of software installs to end-run IT departments. A lot of malware dumps into there but good luck limiting execution from that directory hierarchy because all your business-critical end user communication apps live there now too.
The functionality of roaming users profiles (i.e. registry settings "following" you to a different computer, which gives a really slick user experience when it works) was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for).
In Windows 2000-land you could redirect AppData to a UNC path and mostly get around this behavior. That's not really "a thing" anymore because you've got apps like Microsoft Teams storing sizable databases in these locations and getting really, really cranky if network connectivity is interrupted.
Windows development betrays its legacy DOS parentage even for devs who never lived thru that era. There were no rules. There was no adult supervision. There was poor documentation of APIs so you just hacked something together that worked well-enough. Periodically Microsoft tries to start over (all the APIs w/ "2" at the end, et. al.) and the cycle repeats.