3 ms·

In one scenario, a browser exploit means your passwords are likely bust. In the other, your password manager can still be safu even if your browser is bust. T

by 3np 2y ago

In one scenario, a browser exploit means your passwords are likely bust. In the other, your password manager can still be safu even if your browser is bust. Things are less likely to leak if they are further separated. Letting your browser manage your passwords will never be as secure as alternatives can be.

perching_aix 2y ago
Aren't they process isolated? Surely if an exploit can go as far as to gain access to the browser pw mgr, they can do basically anything userspace, including execute payloads against all the other pw mgrs on the system?
- AstralStorm 2y ago
  There is a class of exploits that can read the browser UI without breaking into the OS, but that wouldn't usually get you the password from the manager itself, but on use. And the session cookies. Session cookie exfil is the more common, so it's a good idea to log-in on demand especially to secure critical sites, and preferably wipe those cookies too. And use separate profiles or browsers. Normally at that point the browser is sufficiently compromised it would be able to capture passwords put into it, so it doesn't matter which password manager is used with it. Unless you clicked one of those phishing grabber links exploiting poor security settings of a site or outright entered the password. This is actually easier to fall prey to with an external manager as it's easier to fool as to which domain is being accessed. I'd like to hear of that exploit that doesn't also void all other managers. Maybe if you had the browser in a VM and the exploit was not persistent... (Browser sandboxes were notoriously weak. They're getting better though.)
- 3np 2y ago
  How big of a difference it makes obviously depends on your OS and how you run your browser. I guess your choices are 1. Educate yourself on the nitty-gritty and make an educated decision 2. Reason from first principles and apply general best-practices 3. Trust your vendors fully unless provided proof of vulnerability I suggest 1 and 2. > Surely if an exploit can go as far as to gain access to the browser pw mgr, they can do basically anything userspace, including execute payloads against all the other pw mgrs on the system? If that is true for you, I really suggest hardening your system.
  - perching_aix 2y ago
    You basically didn't say anything. Vague suggestions that I'm uneducated on the "nitty-gritty" (compared to you?), that I'm not reasoning based on "first principles" and am not applying "general best practices", and that my system in particular should be "hardened", despite working like ~every other, are not productive, nor insightful.
    - 3np 2y ago
      You expected a productive, meaningful and actionable response to the question "Aren't they process isolated?" without even hinting at which OS and browser you're considering? Vague question, vague answer.
      - perching_aix 2y ago
        Yes I did. Or alternatively, no reply at all. > vague answer You mean vague and condescending "answer".

by 3np 2y ago

perching_aix 2y ago

Aren't they process isolated? Surely if an exploit can go as far as to gain access to the browser pw mgr, they can do basically anything userspace, including execute payloads against all the other pw mgrs on the system?

AstralStorm 2y ago
There is a class of exploits that can read the browser UI without breaking into the OS, but that wouldn't usually get you the password from the manager itself, but on use. And the session cookies. Session cookie exfil is the more common, so it's a good idea to log-in on demand especially to secure critical sites, and preferably wipe those cookies too. And use separate profiles or browsers. Normally at that point the browser is sufficiently compromised it would be able to capture passwords put into it, so it doesn't matter which password manager is used with it. Unless you clicked one of those phishing grabber links exploiting poor security settings of a site or outright entered the password. This is actually easier to fall prey to with an external manager as it's easier to fool as to which domain is being accessed. I'd like to hear of that exploit that doesn't also void all other managers. Maybe if you had the browser in a VM and the exploit was not persistent... (Browser sandboxes were notoriously weak. They're getting better though.)
3np 2y ago
How big of a difference it makes obviously depends on your OS and how you run your browser. I guess your choices are 1. Educate yourself on the nitty-gritty and make an educated decision 2. Reason from first principles and apply general best-practices 3. Trust your vendors fully unless provided proof of vulnerability I suggest 1 and 2. > Surely if an exploit can go as far as to gain access to the browser pw mgr, they can do basically anything userspace, including execute payloads against all the other pw mgrs on the system? If that is true for you, I really suggest hardening your system.
- perching_aix 2y ago
  You basically didn't say anything. Vague suggestions that I'm uneducated on the "nitty-gritty" (compared to you?), that I'm not reasoning based on "first principles" and am not applying "general best practices", and that my system in particular should be "hardened", despite working like ~every other, are not productive, nor insightful.
  - 3np 2y ago
    You expected a productive, meaningful and actionable response to the question "Aren't they process isolated?" without even hinting at which OS and browser you're considering? Vague question, vague answer.
    - perching_aix 2y ago
      Yes I did. Or alternatively, no reply at all. > vague answer You mean vague and condescending "answer".