> Anyone (criminal or otherwise) should know never to store passwords in their browser and to always log out of sensitive sessions.
I'm not aware of any meaningful differences between using the browser's password vault vs. using a local password manager's vault. They get targeted the same and are not meaningfully different in their workings. Most you could bring up is browser data syncing, which there are other reasons to turn off anyhow if you don't trust the corporations.
I don't know where is this even coming from though, the article doesn't address anything like this prior to the quoted bit.
Kind of fair on the sensitive sessions thing, but only just kind of. If a system is sensitive, it should have a short keepalive in the first place. Blaming the user is not an effective security strategy, much like how saying "skill issue" is not an effective mitigation strategy for memory mgmt vulnerabilities of C code.
Wild article though. I hope the guy turns over a better leaf.
> I'm not aware of any meaningful differences between using the browser's password vault vs. using a local password manager's vault.
Both are better than using the same password, or overly simple passwords, on multiple accounts, and other human flaws. Beyond that there are some subtleties in the threat models, so the two options have a couple of slightly different risks.
If your browser is hacked, passwords stored in it could be unsafe. While the browser makers take great efforts to properly segregate the functions to reduce the risk, there have been cases where malicious code has been able to circumvent those efforts through bugs to gain access. There is also the issue of local attacks: if someone manages to unlock your workstation (or you accidentally leave it unlocked) your browser may helpfully fill in passwords where an external vault would not (or course if you left that unlocked too, this difference is moot).
Likewise the external password manager often means credentials being carried over the clipboard, and if not that then the OS message queue. Both of these can potentially be intercepted by any malicious running code that has managed to get into your current session, or you could simply cock-up and paste them into the wrong place (or perhaps have the password manager send them to the wrong place due to confusion over which window will get input focus when the password manager starts sending messages).
Personally I go with the external app and refuse to store passwords in the browser, in part because I like having to actively switch to it, unlock it, etc, because the possibility of more automated features (even if they are optional) makes me feel less safe. But there are safety arguments both ways, and for most people the distinction is not important: in both cases if malicious persons or code are that close to your credentials, in either storage location, you are probably rather screwed anyway!
>They get targeted the same and are not meaningfully different in their workings
I disagree. The Attack surface of a browser is huge compared to a local application. Browser password manager hacks only needs to exploit the browser itself (access password feature/addon) while the other needs to exploit the browser + OS +/ password manager (escape browser and access the application).
Browser sandbox escapes have historically been a lot more difficulty, rare and expensive compared to in browser exploits. A local password manager is also not always unlocked and running unlike the browser one.
Regardless, in the real world the most likely way to hack both is malware run on the device.
Yeah I found that bit strange too. Browser-stored (and -generated) passwords would be a step up from reusing your password on 82 sites! Most browsers support "master passwords" or system keyrings so the passwords are encrypted at rest (though you may have to manually enable master passwords. If it's sync they're talking about, I haven't heard of Firefox Sync ever being hacked, but there was a big breach of LastPass. Of course neither is good enough without 2FA these days.
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?
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.)
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.
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.
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?
> And now for the grand finale, all of this was done from a mobile phone, via RDP.
This is amazing if true. Just typing a few sentences on this little phone keyboard is very frustrating to me. Zoomers really are the phone native generation.
> Anyone (criminal or otherwise) should know never to store passwords in their browser and to always log out of sensitive sessions.
I'm not aware of any meaningful differences between using the browser's password vault vs. using a local password manager's vault. They get targeted the same and are not meaningfully different in their workings. Most you could bring up is browser data syncing, which there are other reasons to turn off anyhow if you don't trust the corporations.
I don't know where is this even coming from though, the article doesn't address anything like this prior to the quoted bit.
Kind of fair on the sensitive sessions thing, but only just kind of. If a system is sensitive, it should have a short keepalive in the first place. Blaming the user is not an effective security strategy, much like how saying "skill issue" is not an effective mitigation strategy for memory mgmt vulnerabilities of C code.
Wild article though. I hope the guy turns over a better leaf.
> I'm not aware of any meaningful differences between using the browser's password vault vs. using a local password manager's vault.
Both are better than using the same password, or overly simple passwords, on multiple accounts, and other human flaws. Beyond that there are some subtleties in the threat models, so the two options have a couple of slightly different risks.
If your browser is hacked, passwords stored in it could be unsafe. While the browser makers take great efforts to properly segregate the functions to reduce the risk, there have been cases where malicious code has been able to circumvent those efforts through bugs to gain access. There is also the issue of local attacks: if someone manages to unlock your workstation (or you accidentally leave it unlocked) your browser may helpfully fill in passwords where an external vault would not (or course if you left that unlocked too, this difference is moot).
Likewise the external password manager often means credentials being carried over the clipboard, and if not that then the OS message queue. Both of these can potentially be intercepted by any malicious running code that has managed to get into your current session, or you could simply cock-up and paste them into the wrong place (or perhaps have the password manager send them to the wrong place due to confusion over which window will get input focus when the password manager starts sending messages).
Personally I go with the external app and refuse to store passwords in the browser, in part because I like having to actively switch to it, unlock it, etc, because the possibility of more automated features (even if they are optional) makes me feel less safe. But there are safety arguments both ways, and for most people the distinction is not important: in both cases if malicious persons or code are that close to your credentials, in either storage location, you are probably rather screwed anyway!
>They get targeted the same and are not meaningfully different in their workings
I disagree. The Attack surface of a browser is huge compared to a local application. Browser password manager hacks only needs to exploit the browser itself (access password feature/addon) while the other needs to exploit the browser + OS +/ password manager (escape browser and access the application).
Browser sandbox escapes have historically been a lot more difficulty, rare and expensive compared to in browser exploits. A local password manager is also not always unlocked and running unlike the browser one.
Regardless, in the real world the most likely way to hack both is malware run on the device.
Yeah I found that bit strange too. Browser-stored (and -generated) passwords would be a step up from reusing your password on 82 sites! Most browsers support "master passwords" or system keyrings so the passwords are encrypted at rest (though you may have to manually enable master passwords. If it's sync they're talking about, I haven't heard of Firefox Sync ever being hacked, but there was a big breach of LastPass. Of course neither is good enough without 2FA these days.
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.
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?
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.)
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.
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.
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.
Well written article. Enjoyable and informative, even for a non sec worker
This author didn't do a very good job of hiding Arthur Skorik's name.
Artur, of course, in Ukraine “Artur” is spelled without “h”.
I would have guessed something like Sl<vowel>vnik rather than Skorik, too, but the author was nice enough to include "Skorik" a few paragraphs below.
> And now for the grand finale, all of this was done from a mobile phone, via RDP.
This is amazing if true. Just typing a few sentences on this little phone keyboard is very frustrating to me. Zoomers really are the phone native generation.