151–160 of 209 posts
Earlier quoted context omitted.
Do hardware keyloggers trigger endpoint security?
A hardware keylogger has to sit as a MitM between the keyboard and the USB port. Sufficiently paranoid endpoint security could trip when the keyboard is unplugged and then plugged back in.
Earlier quoted context omitted.
Agreed. The windows registry needs to be killed with fire. There's no appreciable difference between the registry and a directory of config files except that instead of an INI parser you have to use the much, much worse WIN32 API. Editing config files is fairly safe and user-intuitive. Sure you can break something by writing the wrong config file, but you do not risk breaking everything . But clumsy use of regedit do…
There are real integration challenges with the "simple file approach": - File locking and concurrency - Atomic writes / moves - Realtime change observations > clumsy use of regedit does have a chance of totally borking the entire system. So does a clumsy rm -rf, which shows up in stories here far more often than stories of people breaking their registry. Can you provide a recent reference to someone bricking their sy…
Interestingly, the latest versions of bitwarden for mac that are available for download from github no longer work with biometric authentication, requiring the user to download the app from the app store in order to use that functionality.
Why isn’t being signed enough for an application to store secrets only it can access in the keychain?
Earlier quoted context omitted.
>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…
The JVM did that many years ago and nobody liked it. I can't help but think wasm is just the same idea but worse.
Earlier quoted context omitted.
>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…
It's called iOS. Browsers are also NOT safe. You know what was safe? Not letting random endpoints ship you code to run. HTML was safe, though implementations at the time likely had security flaws. 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…
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…
Is there even a way to opt in to having a secret be accessible only for your process? Like, a way to maybe sign your executable and then use a windows api that then gets "oh. This process is made by the same vendor that created this secret, so it’ll be allowed access". It’s just ridiculous that the most trivial, unprivileged process can just steal any file and any secret accessible by the user it’s run as. Unless tha…
It's trivial on Unix - just make the program setgid and change the folder permissions to only allow the group. This can be nested, though that requires that the relevant program be aware of the need to walk through several levels, though often a symlink can hide that.
Note that when creating such a directory setup, `chown`ing away the user requires a privileged helper utility. But you need to make such utilities anyway so the user can delete such directories.
***
Important note - most other "solutions" only protect you from apps the opt in to security. A proper solution, like this one, protects from all processes running as user, except the process of note.
Earlier quoted context omitted.
>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…
It's called iOS. Browsers are also NOT safe. You know what was safe? Not letting random endpoints ship you code to run. HTML was safe, though implementations at the time likely had security flaws. 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…
All we want is to get rid of the possibility of an application developer including evil code.
We could have a fully interpreted language layer running on a platform that never lets application code touch the file system. How do applications do fast stuff like GUI then? You just have a package manager with libraries that can do low-level stuff but are vetted so they don't expose APIs that let application code interact with the file system. That way in order to exploit an user's computer you need to exploit a flaw in a library thousands of other programmers use instead of just importing std io.
A lot of security seems geared toward server environments where you are only dealing with code you fully trust in, like the left-pad library. If bad code broke your server, you could really just load a backup. But most of people using computers are on their personal computers, a majority of them have no backup, and they are downloading and running random programs all the time. It makes it harder for both desktop application developers and their users if there isn't a sandboxing layer in the middle. It's probably one of the factors that is killing desktop apps in first place since most users can trust a website that is an image editor but fewer would install an image editor because it can contain a cryptominer, or a ransonware, or a virus, or whatever.
Earlier quoted context omitted.
The JVM did that many years ago and nobody liked it. I can't help but think wasm is just the same idea but worse.
Outside of web applets, set-top boxes, and DVD players, JVM didn't really do much sandboxing. On the desktop or server, it did practically none.
One could always launch any java process with java -Djava.security.manager -Djava.security.policy=someURL and it would sandbox a huge number of things (see: https://docs.oracle.com/en/java/javase/17/security/permissio... )
The problem is that defining a reasonable policy for any modern app is a gargantuan pain -- as is the case with any security policy language -- so as the GP said people hated it and now it's dead https://openjdk.org/jeps/411
Earlier quoted context omitted.
Outside of web applets, set-top boxes, and DVD players, JVM didn't really do much sandboxing. On the desktop or server, it did practically none.
I think the rest of your sentence was "by default" which is the same thing the comment you're replying to said: "security gets in the way of everything" One could always launch any java process with java -Djava.security.manager -Djava.security.policy=someURL and it would sandbox a huge number of things (see: https://docs.oracle.com/en/java/javase/17/security/permissio... ) The problem is that defining a reasonable po…
You basically can't take a complex thing and write complex security rules for it and expect success & real world adoption.
The complexity of deployed identification/auth chain/secrets management/ec. is pretty terrifying; even if you can somehow understand it for one OS and hardware platform, if your service needs to support multiple OSes plus web plus multiple auth technologies plus a recovery path and everything else, dragons. This is one of the few things cryptocurrency gets right in one specific way better than most other applications…