If filesystem access is a legitimate concern, you have bigger problems. Even if passwords were secured by FIDO or similar, session tokens are not.
If you compromise a computer, you can compromise web sessions. There is no mitigation for this. Shame on the author for attempting to create panic when far more productive security can be achieved elsewhere.
As usual with security discussions, one needs to start from analyzing security threats and attack vectors. Is a simple to memorize and likely multi-use password is a bigger security threat than a unique, hard to guess passwords in a file storage? It depends.
Is this a laptop without disk encryption that travels a lot and especially internationally? Sure, these semi-unencrypted passwords on disk are likely not very safe from lost laptops, customs inspections, etc. Might still be better than a common and simple password though.
Is this a laptop sitting at home most of the time with a strong disk encryption? I’ll take unsecured browser password storage with unique hard passwords any day.
This is a bad bad article, the advice is dated and the counter-arguments are well known and oft-discussed by anyone who's actually in the security community.
The author / website does seem to be offering services in the security industry, but they seem compliance-focused rather than security-focused (compliance is a component of security). So likely offering legal & administrative expertise rather than technical.
On reflection, I think this article is why I find it extremely difficult to hire qualified security experts.
The vast majority of "security experts" I find tend to be "box tickers", who can require lots of rules like this ("don't use the built in password manager"), but whose advice is worse than useless because they don't understand the actual threat models.
I know great security people exist, but in my experience I wasn't able to find them, and instead just decided to learn the most important things myself (I'm an application engineer who felt I had a good grasp of things around application security, but less so around infrastructure and corporate IT security).
Their site seems focused on CISOs which in my experience lack serious technical skills.
In fairness this is part of their job, but it is sometimes annoying when they refuse to recognise real risks and just focus on stuff that's just show. Like bitsight scores. In our case they don't reflect our actual environment at all (they don't recognise 99% of our traffic), but the CISOs love bitsight because our score is an A.
It would also be great if someone could get the author a Twitter account. I usually hate twitter but this seems like a 2000+ word article that could have been stated in a couple of tweets.
> Note – many of these dedicated password managers have browser plugins or extensions to help users save and fill passwords. These are very different and much more secure than the built-in password managers that are the subject of this article!
This is a shitty article from someone who doesn't really know what he's talking about. Here is a post from Tavis Ormandy, well-known security expert at Google Project Zero, advocating the exact opposite: https://lock.cmpxchg8b.com/passmgrs.html
Although I trust Tavis Ormandy more than this random blog post, I disagree with the idea that the password managers built into your browser are somehow superior.
I use Bitwarden and there's simply no comparison between what Firefox/Chrome offer me and what Bitwarden offers; you can't even add an extra field to the browser password manager and Google helpfully "encrypts" your data with the password they're already receiving when you're setting up their browser. You can change that, of course, but like a router's default password, if you don't have to change it, people won't. There are also other UI/UX problems (had a side move TLDs, good luck fixing that in your browser!) that browsers don't seem to care about for the sake of "simplicity".
The dangers that come with external password managers are because of a lack of good password manager APIs in browsers, forcing them to break the security model. It's easy to say "don't use them, they break some design", especially if you work for a company that designs their own browser, but there are quite tangible benefits to taking the risks, the most important of which is probably "not handing over your data to some browser giant".
Re: this article: if the attacker has access to the browser password database, they have access to cookies and the ability to monitor key strokes. You can encrypt passwords all you want but the attacker can still move laterally between services by just copying your session cookie and hitting the next vulnerable target. Credentials will come next time the user logs in. Thinking about secure passwords is important, but there's a bigger picture that needs to be accounted for.
The writer of this article mostly seems interested in ticking boxes based on how much they hammer on writing policy and enacting policy and talking to people about policy. I'm not sure who the target audience for this blog is, I would guess managers who are looking to improve their company's security?
That's bad article too. It talks about 1 bad "feature" of specific password manager extension and then dismisses every other password manager extension without verifying if they have this bad "feature" too. And this is from security expert ? Bruh
Whoever wrote this seems to have no modern security training.
> then your average employee is probably doing one of these three things: Writing passwords down on paper
> Hopefully, you have a corporate security awareness training program and have long been discouraging
Please, please encourage people to write down passwords on paper! That provides really good safety against most modern threat models, especially in a world where people are working from home.
> Even though Chrome, Firefox, and Edge browsers all store passwords in encrypted databases, by default all three products intentionally leave the associated encryption keys completely unprotected in predictable locations.
There was (is?) a long lived Chrome issue (which I can't find now). They reasonably make the point that operating system level protection is the correct way to protect this (ie, if a person can log onto your device they are assumed to be you).
Even if the user doesn't turn on a master password, having the key in a predictable place on an encrypted volume with appropriate access permissions is still far more secure than sticky notes on the monitor. Contrary to the OP link's statement, it isn't enough for the attacker to get access to the user's system, they have to get access to the user's account.
And if the organization in question isn't using Bitlocker or FileVault or some other encryption, browser password stores are way down the list of security worries.
I'm sorry, but this view is fundamentally incorrect.
You have to consider what the actual threat model is. The reality is that your primary threat model is not going to be one employee compromising another's, nor is it someone malicious physically tracking down your employees and stealing and/or physically compromising their devices.
Those threats do technically exist, but your employees have to be extraordinarily valuable to warrant the surveillance required to use physical access to compromise them/their account. It is vastly more likely that the attack vector is going to be spam/scam/phishing leading to malicious software installed on the victim's machine. Notably in regard to the post-it/notebook you claimed was the worst option, computers generally can't read post it notes attached to the monitor.
Similarly bit locker and FileVault are obviously important, but do nothing at all to stop a remote attacker, because the only threat model that they protect against is physical access to the hardware. If a remote attacker has got some malicious software installed, then by definition once it's running all the drive content is available to the attacker's software (technically SIP should limit this on macOS, but I'll assume that an attacker also compromises SIP).
But it is extremely important to understand that in none of these cases did the attacker need to get "access to the user's account" - that was simply a byproduct of their primary attack.
If your home directory is readable or writable by anyone other than you, you're compromised in a dozen more important ways, even though this is of very high importance. Your home directory's security is an axiom. It's not true, no, in the same way that there were once upon a time remote exploitable worms in major http frameworks but we don't question that a webserver doesn't allow remote-code-execution - it's the wrong layer of abstraction.
Even encrypting the browser's data store at the application level is misguided and probably pointless - Anything that can read the browser's files is going to read the encryption key just as well . Anything that can read the browser's files when running as you is probably going to pop up an identical looking "Enter Password" prompt and will have the right timing and permissions to enter it into the browser once it's been leaked. Gui frameworks are not designed to protect the user from malicious applications.
Android actually handles this much better - Applications (Rather, developers) are given their own user id, and so separation of files between apps is enforced at the OS level. Some level of this is why everyone has moved to Docker on the server, too.
This is a bunch of silly hand-wringing. I guarantee that if browsers required creating and memorizing and typing a master password all the time, users would be less secure overall. Because people simply wouldn't use the annoying password manager. Using a password manager without a master password is way more secure than not using a password manager at all.
If you are a business and you want your employees to be secure, forget about anything to do with passwords. You need hardware second factor tokens. Which I notice the article doesn't mention at all. An article about login security in 2022 that doesn't even mention hardware tokens for two factor authentication is not worth anyone's time.
The recent targeted phishing attacks against Twilio and Cloudflare made this abundantly clear. Twilio didn't use hardware tokens and was hacked. Cloudflare reported they had 3 users who entered their username and password into the phishing site, but since all of their employees use hardware keys, they weren't hacked.
Be careful what you wish for. It's happening but not in the way you're envisioning. A lot of logins now require a phone app. That's the hardware offloading, and reduces overhead of having to manage dedicated hardware. Instead, users manage it themselves and the business piggybacks off it.
> Using a password manager without a master password is way more secure than not using a password manager at all.
I disagree, diceware AND hardware security keys, is stronger, no password manager needed at all.
However I agree the article is overblown. For most people, browser based password managers are probably a vast improvement, since most will likely never educate themselves on such things or accept the solutions as personally viable. The browser is right there and even prompts them into using it.
Safari already gates password autofill on the secure element (or enclave, I can never remember the difference) when such is available, which is what you're suggesting :D
That said you're absolutely correct, making autofill harder to use would mean people wouldn't use it, and would revert to predictable and reused passwords, and if you're a business you should be using token based authentication be they dongles or phone and PC's secure elements.
I don't think there is anything wrong with storing passwords unencrypted locally assuming the machine itself has encrypted storage. Malware that retrieves passwords from password manager could get them from an unlocked password manager as well.
A lot of the criticism of this article seems to be: “If they already have access to your local file system, you already have bigger problems”
What about defence in depth?
This article is suggesting an alternative, which are password managers such as 1Password. These Password managers do not suffer from the same weak key storage as the browser’s build-in password managers.
So this article is bringing attention to a weakness in the browser’s built-in password managers, and suggesting a very viable and easy-to-adopt solution.
The problem is that the article takes on this hyperbole-laden all-or-nothing tone that does nobody any favours.
If you go along with the all-or-nothing mentality, then local file system access is pretty much game over anyway.
If you want to take the security-in-depth approach, you have to first apply it to these password managers and take an honest look at the problems they solve. And it turns out they’re amazing from a cost:benefit benefit perspective.
Put differently: go read the spectre/meltdown papers. Imagine if _those_ were written in the same tone this is. That’s the problem.
The article states that there is a big problem, but the solution it gives only incrementally improves the situation.
If passwords stored in plaintext is a problem, don’t just use slightly harder to access storage. Use SSO so there are not credentials to steal.
If the article gave a complete picture of what to do to mitigate the damage of endpoint compromise or was less alarmist in its assessment of risk, I would have liked it better.
> So this article is bringing attention to a weakness in the browser’s built-in password managers, and suggesting a very viable and easy-to-adopt solution.
Because many actual experts disagree it is a weakness
> Why the strong criticism of this article?
The advice tries to make it out like browser suppliers are doing this to lower security for some unknown reason, whereas actually their model is safer than what is recommended.
It is possible to argue against browser suppliers here, but you need to look at their arguments for doing it that way. This article doesn't do that.
These articles always assume everyone has the same threat model: you are head of the NSA's IT department, and hostile nation-states are spending billions to attack your security with everything from 1024-qubit computers to $5 pipe wrenches.
Forcing users to employ the same security tools and practices that would be appropriate for dealing with far more serious threats is just annoying, and likely to result in passive-aggressive resistance.
I remember there being a lot of buzz about security issues related to allowing Browsers storing passwords, this was more than 10 years ago, but ever since that I have just not trusted them. I reluctantly use a open source password manager, keepass, and figure it is still better than using the same password everywhere.
Why would we store password in the browser? Seriously. I want my passwords to be available wherever I need to use them, and that only happens if I somehow share the passwords between my devices. I would not trust a proprietary browser developer do store my passwords securely. Period. I have no way of seeing or knowing what is going on on their cloud servers.
There are very simple ways to sync files between systems, which are open source, and are much more unlikely to compromise your passwords. E.g. The database itself is encrypted, and the methods of sharing are so simple that it is easy to cover many of the most probable points of entry. Obviously, sharing a password database file over the internet is extremely bad, but if you feel you must, do at least manage the server where you keep the pw db yourself. Heck, I would even 7zip it with another layer of security, because I can not know for sure if Keepass' encryption is safe.
There is a lot of backlash against this article, which to be fair is kind of poorly written, but still makes a valid point. Encrypting something and writing the key on the same place is pointless.
These browsers encrypting the passwords with a key saved on the device is security theater and has to be called out.
Security is not all or nothing, most people don't have full disk encryption so their passwords are sitting there completely unencrypted, trivially retrieved from anyone with physical access.
> makes a valid point. Encrypting something and writing the key on the same place is pointless.
The backlash is due to this not being a valid point. Security best practice has long moved on from dogmatic binaries and treating humans like robots.
Encrypting something in transit and writing the key in plaintext locally, while not ideal, is far from pointless. Building perfectly secure systems that nobody will use is what's pointless.
> trivially retrieved from anyone with physical access
Pretty bold using the word "trivial" here: physical access is not the primary threat model for average password manager use.
Sure, encrypting the passwords is better, but to steal all the stored unencrypted password the attacker would need access to the users computer.
If they have that access you have bigger problems on your hand. Yes, this can lead to privilege escalation, but for the vast majority of people access to the desktop is enough for that anyway.
If you need better security, you probably already are using more advanced measures.
One thing i often do when i forget one of my passwords, is go into chrome, goto the webpage corresponding to the login of the thing in question and let it autofill, then i turn the password area to a plain text area in the HTML editor.
I've always thought this kind of bypasses most checks you get if you try to go into the password db in the browser it self.
The new Hell I'm experiencing is everyone wanting to validate my identity through my phone. Email does it, banking does it, I suspect by the end of the year Windows will probably be sending me a code before I can log in. I'm sick of it. I don't like needing to have my phone on me, I don't like the fear that if I lose my phone I'll be locked out of everything, and I really don't like being forced into this.
It feels like there's a lot of fear around passwords right now. I'm sure companies see them as a liability and are eager to move away from them as soon as possible. Are we going to have a future where each person (or identity) has a single hardware token for all logins? I don't think we're anywhere close to that yet.
SMS TOTP is indeed bad and your suspicion is well warranted.
Its a lazy way to implement 2-factor authentication and exposes the user to MITM attacks as well as a host of other nastiness.
U2F (stuff like what Google Authenticator does) is way better and less phone dependent. The only reason a team would opt for TOTP if they had the resources to implement U2F is because its a good way to get your phone number.
Edit: embarrassingly I've made an error in my use of acronyms. What I refer to as TOTP is in fact plaintext OTP sent via SMS, and what I refer to as U2F is actually app-based TOTP. Apologies!
I recently had to tell my bank, with my voice over the phone, that the make and model of my first car were the three random words 1Password generated for me. “Yes, the make and model of my first car was… a Venerated Breakfast Platoon.”
Little-to-nothing to do with liability. Your identity = $. Phone-validated users are simply higher ARPU and (somewhat less importantly) lower risk - an artefact of gating access behind harder-to-spoof touch points.
To the extent that a hardware token proffers anon/pseudonymous verification, there'll be pushback from industry. Because again, your identity = $. Expect anything that would plausibly get a revenue bump from verifying identity to force you to do so eventually. Because you know, security.
Or you could report this as a security bug on those browsers.
This vulnerability does not exist in Safari on any platform: macOS, iOS, or windows. Admittedly in the last case because it is alas dead :D
I would have assumed that on macOS Firefox and Chrome use the platform APIs that support secure storage of data, and would absolutely consider this to be a security bug if not.
Lot of critical reactions, maybe deserved. Some saying master password is not all that important. I notice that with Firefox Sync that means knowing the unlock swipe of your Android is all that's needed to view passwords in plain text via the Settings UI when you lose your phone or someone peeks in it on an unguarded moment.
I'm just not sure why they haven't built in something like Apple's face ID. I know security experts hate anything that isn't locked down with 3 forms of verification but my goal is to have security to the point that it isn't a hastle every time I want to go to a new website.
[+] [-] iueotnmunto|3 years ago|reply
If you compromise a computer, you can compromise web sessions. There is no mitigation for this. Shame on the author for attempting to create panic when far more productive security can be achieved elsewhere.
[+] [-] lsh123|3 years ago|reply
Is this a laptop without disk encryption that travels a lot and especially internationally? Sure, these semi-unencrypted passwords on disk are likely not very safe from lost laptops, customs inspections, etc. Might still be better than a common and simple password though.
Is this a laptop sitting at home most of the time with a strong disk encryption? I’ll take unsecured browser password storage with unique hard passwords any day.
Edit: formatting
[+] [-] zokier|3 years ago|reply
If yes then password storage is not the thing you should be concerned about. There is no excuse for not having FDE on laptops in 2022.
[+] [-] lucideer|3 years ago|reply
The author / website does seem to be offering services in the security industry, but they seem compliance-focused rather than security-focused (compliance is a component of security). So likely offering legal & administrative expertise rather than technical.
[+] [-] hn_throwaway_99|3 years ago|reply
The vast majority of "security experts" I find tend to be "box tickers", who can require lots of rules like this ("don't use the built in password manager"), but whose advice is worse than useless because they don't understand the actual threat models.
I know great security people exist, but in my experience I wasn't able to find them, and instead just decided to learn the most important things myself (I'm an application engineer who felt I had a good grasp of things around application security, but less so around infrastructure and corporate IT security).
[+] [-] GekkePrutser|3 years ago|reply
In fairness this is part of their job, but it is sometimes annoying when they refuse to recognise real risks and just focus on stuff that's just show. Like bitsight scores. In our case they don't reflect our actual environment at all (they don't recognise 99% of our traffic), but the CISOs love bitsight because our score is an A.
[+] [-] throwaway81523|3 years ago|reply
[+] [-] hn_throwaway_99|3 years ago|reply
This is a shitty article from someone who doesn't really know what he's talking about. Here is a post from Tavis Ormandy, well-known security expert at Google Project Zero, advocating the exact opposite: https://lock.cmpxchg8b.com/passmgrs.html
[+] [-] jeroenhd|3 years ago|reply
I use Bitwarden and there's simply no comparison between what Firefox/Chrome offer me and what Bitwarden offers; you can't even add an extra field to the browser password manager and Google helpfully "encrypts" your data with the password they're already receiving when you're setting up their browser. You can change that, of course, but like a router's default password, if you don't have to change it, people won't. There are also other UI/UX problems (had a side move TLDs, good luck fixing that in your browser!) that browsers don't seem to care about for the sake of "simplicity".
The dangers that come with external password managers are because of a lack of good password manager APIs in browsers, forcing them to break the security model. It's easy to say "don't use them, they break some design", especially if you work for a company that designs their own browser, but there are quite tangible benefits to taking the risks, the most important of which is probably "not handing over your data to some browser giant".
Re: this article: if the attacker has access to the browser password database, they have access to cookies and the ability to monitor key strokes. You can encrypt passwords all you want but the attacker can still move laterally between services by just copying your session cookie and hitting the next vulnerable target. Credentials will come next time the user logs in. Thinking about secure passwords is important, but there's a bigger picture that needs to be accounted for.
The writer of this article mostly seems interested in ticking boxes based on how much they hammer on writing policy and enacting policy and talking to people about policy. I'm not sure who the target audience for this blog is, I would guess managers who are looking to improve their company's security?
[+] [-] pieresqi|3 years ago|reply
[+] [-] pigbearpig|3 years ago|reply
No, no it is not. When an article gets something so easy to check so wrong, it's difficult to believe anything else in it.
[+] [-] nl|3 years ago|reply
> then your average employee is probably doing one of these three things: Writing passwords down on paper
> Hopefully, you have a corporate security awareness training program and have long been discouraging
Please, please encourage people to write down passwords on paper! That provides really good safety against most modern threat models, especially in a world where people are working from home.
> Even though Chrome, Firefox, and Edge browsers all store passwords in encrypted databases, by default all three products intentionally leave the associated encryption keys completely unprotected in predictable locations.
There was (is?) a long lived Chrome issue (which I can't find now). They reasonably make the point that operating system level protection is the correct way to protect this (ie, if a person can log onto your device they are assumed to be you).
[+] [-] torstenvl|3 years ago|reply
And if the organization in question isn't using Bitlocker or FileVault or some other encryption, browser password stores are way down the list of security worries.
[+] [-] olliej|3 years ago|reply
You have to consider what the actual threat model is. The reality is that your primary threat model is not going to be one employee compromising another's, nor is it someone malicious physically tracking down your employees and stealing and/or physically compromising their devices.
Those threats do technically exist, but your employees have to be extraordinarily valuable to warrant the surveillance required to use physical access to compromise them/their account. It is vastly more likely that the attack vector is going to be spam/scam/phishing leading to malicious software installed on the victim's machine. Notably in regard to the post-it/notebook you claimed was the worst option, computers generally can't read post it notes attached to the monitor.
Similarly bit locker and FileVault are obviously important, but do nothing at all to stop a remote attacker, because the only threat model that they protect against is physical access to the hardware. If a remote attacker has got some malicious software installed, then by definition once it's running all the drive content is available to the attacker's software (technically SIP should limit this on macOS, but I'll assume that an attacker also compromises SIP).
But it is extremely important to understand that in none of these cases did the attacker need to get "access to the user's account" - that was simply a byproduct of their primary attack.
[+] [-] GauntletWizard|3 years ago|reply
Even encrypting the browser's data store at the application level is misguided and probably pointless - Anything that can read the browser's files is going to read the encryption key just as well . Anything that can read the browser's files when running as you is probably going to pop up an identical looking "Enter Password" prompt and will have the right timing and permissions to enter it into the browser once it's been leaked. Gui frameworks are not designed to protect the user from malicious applications.
Android actually handles this much better - Applications (Rather, developers) are given their own user id, and so separation of files between apps is enforced at the OS level. Some level of this is why everyone has moved to Docker on the server, too.
[+] [-] modeless|3 years ago|reply
If you are a business and you want your employees to be secure, forget about anything to do with passwords. You need hardware second factor tokens. Which I notice the article doesn't mention at all. An article about login security in 2022 that doesn't even mention hardware tokens for two factor authentication is not worth anyone's time.
[+] [-] hn_throwaway_99|3 years ago|reply
The recent targeted phishing attacks against Twilio and Cloudflare made this abundantly clear. Twilio didn't use hardware tokens and was hacked. Cloudflare reported they had 3 users who entered their username and password into the phishing site, but since all of their employees use hardware keys, they weren't hacked.
[+] [-] politelemon|3 years ago|reply
Be careful what you wish for. It's happening but not in the way you're envisioning. A lot of logins now require a phone app. That's the hardware offloading, and reduces overhead of having to manage dedicated hardware. Instead, users manage it themselves and the business piggybacks off it.
[+] [-] tomxor|3 years ago|reply
I disagree, diceware AND hardware security keys, is stronger, no password manager needed at all.
However I agree the article is overblown. For most people, browser based password managers are probably a vast improvement, since most will likely never educate themselves on such things or accept the solutions as personally viable. The browser is right there and even prompts them into using it.
[+] [-] olliej|3 years ago|reply
That said you're absolutely correct, making autofill harder to use would mean people wouldn't use it, and would revert to predictable and reused passwords, and if you're a business you should be using token based authentication be they dongles or phone and PC's secure elements.
[+] [-] avree|3 years ago|reply
[+] [-] GlitchMr|3 years ago|reply
[+] [-] quickco|3 years ago|reply
What about defence in depth?
This article is suggesting an alternative, which are password managers such as 1Password. These Password managers do not suffer from the same weak key storage as the browser’s build-in password managers.
So this article is bringing attention to a weakness in the browser’s built-in password managers, and suggesting a very viable and easy-to-adopt solution.
Why the strong criticism of this article?
[+] [-] pdpi|3 years ago|reply
If you go along with the all-or-nothing mentality, then local file system access is pretty much game over anyway.
If you want to take the security-in-depth approach, you have to first apply it to these password managers and take an honest look at the problems they solve. And it turns out they’re amazing from a cost:benefit benefit perspective.
Put differently: go read the spectre/meltdown papers. Imagine if _those_ were written in the same tone this is. That’s the problem.
[+] [-] MarkSweep|3 years ago|reply
If passwords stored in plaintext is a problem, don’t just use slightly harder to access storage. Use SSO so there are not credentials to steal.
If the article gave a complete picture of what to do to mitigate the damage of endpoint compromise or was less alarmist in its assessment of risk, I would have liked it better.
[+] [-] nl|3 years ago|reply
> So this article is bringing attention to a weakness in the browser’s built-in password managers, and suggesting a very viable and easy-to-adopt solution.
Because many actual experts disagree it is a weakness
> Why the strong criticism of this article?
The advice tries to make it out like browser suppliers are doing this to lower security for some unknown reason, whereas actually their model is safer than what is recommended.
It is possible to argue against browser suppliers here, but you need to look at their arguments for doing it that way. This article doesn't do that.
[+] [-] CamperBob2|3 years ago|reply
These articles always assume everyone has the same threat model: you are head of the NSA's IT department, and hostile nation-states are spending billions to attack your security with everything from 1024-qubit computers to $5 pipe wrenches.
Forcing users to employ the same security tools and practices that would be appropriate for dealing with far more serious threats is just annoying, and likely to result in passive-aggressive resistance.
[+] [-] Double_a_92|3 years ago|reply
[+] [-] inshadows|3 years ago|reply
It is a manager-speak buzzword. What about it?
[+] [-] JacobSeated|3 years ago|reply
Why would we store password in the browser? Seriously. I want my passwords to be available wherever I need to use them, and that only happens if I somehow share the passwords between my devices. I would not trust a proprietary browser developer do store my passwords securely. Period. I have no way of seeing or knowing what is going on on their cloud servers.
There are very simple ways to sync files between systems, which are open source, and are much more unlikely to compromise your passwords. E.g. The database itself is encrypted, and the methods of sharing are so simple that it is easy to cover many of the most probable points of entry. Obviously, sharing a password database file over the internet is extremely bad, but if you feel you must, do at least manage the server where you keep the pw db yourself. Heck, I would even 7zip it with another layer of security, because I can not know for sure if Keepass' encryption is safe.
[+] [-] throwawayffffas|3 years ago|reply
These browsers encrypting the passwords with a key saved on the device is security theater and has to be called out.
Security is not all or nothing, most people don't have full disk encryption so their passwords are sitting there completely unencrypted, trivially retrieved from anyone with physical access.
[+] [-] lucideer|3 years ago|reply
The backlash is due to this not being a valid point. Security best practice has long moved on from dogmatic binaries and treating humans like robots.
Encrypting something in transit and writing the key in plaintext locally, while not ideal, is far from pointless. Building perfectly secure systems that nobody will use is what's pointless.
> trivially retrieved from anyone with physical access
Pretty bold using the word "trivial" here: physical access is not the primary threat model for average password manager use.
[+] [-] ars|3 years ago|reply
If they have that access you have bigger problems on your hand. Yes, this can lead to privilege escalation, but for the vast majority of people access to the desktop is enough for that anyway.
If you need better security, you probably already are using more advanced measures.
[+] [-] dmateos|3 years ago|reply
I've always thought this kind of bypasses most checks you get if you try to go into the password db in the browser it self.
[+] [-] aimor|3 years ago|reply
It feels like there's a lot of fear around passwords right now. I'm sure companies see them as a liability and are eager to move away from them as soon as possible. Are we going to have a future where each person (or identity) has a single hardware token for all logins? I don't think we're anywhere close to that yet.
[+] [-] plaguepilled|3 years ago|reply
Its a lazy way to implement 2-factor authentication and exposes the user to MITM attacks as well as a host of other nastiness.
U2F (stuff like what Google Authenticator does) is way better and less phone dependent. The only reason a team would opt for TOTP if they had the resources to implement U2F is because its a good way to get your phone number.
Edit: embarrassingly I've made an error in my use of acronyms. What I refer to as TOTP is in fact plaintext OTP sent via SMS, and what I refer to as U2F is actually app-based TOTP. Apologies!
[+] [-] m8s|3 years ago|reply
[+] [-] popcorncowboy|3 years ago|reply
To the extent that a hardware token proffers anon/pseudonymous verification, there'll be pushback from industry. Because again, your identity = $. Expect anything that would plausibly get a revenue bump from verifying identity to force you to do so eventually. Because you know, security.
[+] [-] wetpaws|3 years ago|reply
[+] [-] Double_a_92|3 years ago|reply
[+] [-] quickthrower2|3 years ago|reply
[+] [-] tmikaeld|3 years ago|reply
[+] [-] julienpalard|3 years ago|reply
[+] [-] olliej|3 years ago|reply
This vulnerability does not exist in Safari on any platform: macOS, iOS, or windows. Admittedly in the last case because it is alas dead :D
I would have assumed that on macOS Firefox and Chrome use the platform APIs that support secure storage of data, and would absolutely consider this to be a security bug if not.
[+] [-] rapnie|3 years ago|reply
[+] [-] stjohnswarts|3 years ago|reply