Despite the security updates, using Edge Wallet is still very risky, says user

[Gandalf_The_Grey]

Later in 2023, Microsoft allowed Edge users to easily set up their Edge Wallet, a tool where credit cards, passwords, and other financial devices can be stored. It’s also available as a PWA, and that makes it easier to set it up in the Edge browser.

As per Edge’s updates, its Wallet is also getting security updates, and Microsoft makes sure users won’t be at risk when storing their sensitive information there.

However, despite the regular updates, some users still believe Edge Wallet is quite risky, and while it is a comfortable solution, users might be at risk of losing their credentials to hackers.

This Reddit user, for instance, has an alternative to Edge Wallet: the Microsoft Autofill extension. Released 2 years ago, the extension has become one of the most popular of its kind, and it can be used on all Chromium-based browsers, including Google Chrome, and Microsoft Edge.

What’s the difference between them? Well, the user says the extension is more secure than Edge Wallet because it requires more steps when authenticating, and Microsoft Autofill also doesn’t store sensitive data in plain text, something that Edge Wallet does.

However, if you don’t prefer either of the native Microsoft password managers, there are always third-party password managers that you can try. For instance, you could choose one of these password managers that are also capable of emergency access.

If your device is used by the whole family, these password managers specifically developed for this situation can also be of use.

However, if you don’t agree with the security of the Edge Wallet, and you don’t mind the extra steps, you could stay with Microsoft Autofill, as well. You know what they say, better safe than sorry.

Despite the security updates, using Edge Wallet is still very risky, says user

According to users, Edge Wallet has a faulty security, but there are options around, including Microsoft Autofill, for those who want extra security.

windowsreport.com

 

[oldschool]

Nothing in that incredibly short article as to how Edge's Wallet is insecure other than "some users still believe ...".

You can't believe crap like this. Click bait.

 

[Greygeek]

The type of encryption and the number of bits + number of iterations all factor into the security of a password vault. And I would never use a browser's password storage feature as it fragments my password storage across browsers and devices. I don't want to be locked into one browser and one device - that's not my world.

 

[Andy Ful]

Nowadays, any popular browser's built-in password management cannot be considered safe enough (only moderately safe). The attackers often use Malware-as-a-Service that is sufficiently sophisticated to exploit the vulnerabilities in the browser's built-in password management. Here is an example of such vulnerability:
https://www.velonexit.com/2018/01/browser-vulnerability-that-allows-theft-of-saved-passwords/

More about the browser's built-in password management:
https://www.itprotoday.com/edge-computing/edge-password-manager-may-make-it-safe-to-store-passwords
https://www.kaspersky.com/blog/how-to-store-passwords-securely/48784/
https://www.malwarebytes.com/blog/n...allow-your-browser-to-remember-your-passwords
https://www.cloaked.com/post/is-google-password-manager-safe
https://questsys.com/cto-blog/How-Safe-Are-Password-Managers/

Interesting article about browser built-in and browser extension password managers:

Password Managers.

To bypass browser-based password management, the attacker must mainly infect the system or exploit the web browser. So, for average users, the browser's built-in password management is still better than using weak passwords.

Password managers can also increase the protection against phishing (with some possible flaws), for example:

Auto-F(a)illing Password Managers

Auto-F(a)illing Password Managers refers to a potential security concern with auto-filling inputs. Mitigate the risks and enhance your digital security.

jscrambler.com

Post updated.

 

[Andy Ful]

Nice tips for beginners:

Information archivée dans le Web | Information Archived on the Web

publications.gc.ca

 

[nickstar1]

They needs to work better in keeping extensions up to date that’s for sure they are always behind behind.

 

[Digmor Crusher]

Nice tips for beginners:

View attachment 283796

Information archivée dans le Web | Information Archived on the Web

publications.gc.ca

I use a password manger, its needed for the 80+ sites I need passwords for, however, I do not use it to store any banking/credit card sites. If they want my log in for Malware Tips they can have at it, if I start posting in Swahili one day you will know what happened.

 

[TairikuOkami]

Nice tips for beginners:

Well, banks also use MFA, so even if hacker gets my password, the login still has to be verified from a trusted device.
I myself do not trust the check for reused passwords, you leak your password online to check, if it has been leaked?!

Either way I stopped using Edge Wallet after it removed my passwords from all devices at will. And I was afraid of hackers from stealing my passwords. Edge did a great job by itself.

 

[Andy Ful]

Interesting article about password security in web browsers (from the year 2024):

Passwords Are Meant to Be Secret: A Practical Secure Password Entry Channel for Web Browsers

2.2.Browser-Based Password Exfiltration​

Examining the literature, we identify three avenues by which passwords can be exfiltrated from the browser. This does not include threats outside of the browser such as phishing (Akerlof and Shiller, 2015), man-in-the-middle network attacks (O’Neill et al., 2016), or compromised execution environments (Fahl et al., 2013; Bakry and Mysk, 2020). While each threat has extensive related work, a high-level understanding of them (as held by most readers) is sufficient to understand the remainder of this paper. As such, we omit discussing them in this section for brevity.

2.2.1.Web Trackers​

Web trackers are scripts used to track users across different websites, primarily to more effectively serving advertisements. Trackers collect various information and interactions of the user without the user even knowing about it. Senol et al. (Senol et al., 2022) analyzed form submissions on 100,000 popular websites, investigating whether web trackers on those pages would exfiltrate user passwords. They find that at least 2–3% of those pages include web trackers that exfiltrate passwords. While the motivations for this exfiltration are largely unknown, in many cases, it likely represents an honest-but-curious attacker model—i.e., web trackers are simply grabbing whatever information they can and are not targeting passwords specifically. Regardless, as shown by Dambra et al. (Dambra et al., 2022), users encounter these web trackers frequently, indicating a need to protect user passwords against these honest-but-curious trackers.

2.2.2.Malicious Client-Side Scripts​

Malicious scripts running within a web page can steal user passwords by extracting them from the document object model (DOM) after they have been typed into a form by the user or autofilled by a password manager. There are several sources of malicious client-side scripts.
The most common source of malicious client-side scripts is cross-site Scripting (XSS) attacks. In these attacks, an adversary coerces a website to include attacker-controlled scripts in a web page’s DOM, whether by tricking users into clicking a link with the malicious script (reflected XSS attack) or uploading the malicious script to the website (stored XSS attack). While defenses for XSS attacks are well known, the OWASP foundation consistently ranks them in its top 10 web application security risks (xss, 2022), and hundreds of XSS attacks have been reported in January of 2024 alone (CVEdetails, 2024).
Another common source of malicious client-side scripts are websites that use third-party libraries, with such libraries being ubiquitous (Lemos, 2021). While libraries produced by an adversary are transparently dangerous, more concerning are supply chain attacks (Ohm et al., 2020; Duan et al., 2020). In these attacks, an adversary will compromise an otherwise benevolent software library; then, when websites relying on this library are updated, they will also become compromised. These attacks are already somewhat common (Ohm et al., 2020; Duan et al., 2020), with WhiteSource (whi, 2022) identifying 1300 malicious JavaScript libraries in 2021.
While supply chain attacks are a problem for client-side and server-side libraries, in this paper we are primarily concerned with client-side supply chain attacks. Web client-side supply chain attacks are especially concerning as it is a common practice to load libraries from external sources.2 If a website adopts this practice, the website will be immediately compromised as soon as the library is compromised, without needing to wait for the website to explicitly update to the compromised version of the library.

2.2.3.Malicious Browser Extensions​

The final avenue for password theft is malicious browser extensions. Browser extensions have two avenues for exfiltrating user passwords. First, they can inject client-side scripts into web pages, stealing passwords in the same way as other malicious client-side scripts. Alternatively, they can inspect the body of outgoing web requests, stealing passwords found in those bodies.
There are many instances of malicious browser extensions used by millions of users on official Chrome/Firefox extension stores. In 2020, 500 Chrome browser extensions were discovered secretly uploading private browsing data to attacker-controlled servers and redirecting victims to malware-laced websites (OSITCOM, 2021). Also, Awake has identified 111 malicious Chrome extensions that take screenshots, read the clipboard, harvest password tokens stored in cookies or parameters, grab user keystrokes (like passwords), etc. (Awake Security, 2022). These extensions have been downloaded over 32 million times. Finally, in 2021, Cato’s analysis of network data showed that 87 out of 551 unique Chrome extensions used on customer networks were malicious (Cato Networks, 2022).
In addition to inherently malicious extensions, extensions can also be compromised through supply chain attacks.

In our threat model, we are concerned with the following adversaries:

1. Honest-but-curious entities (e.g., web trackers (Senol et al., 2022)). This entity can read the contents of any DOM element, including the password after it has been entered into the web page. Unlike the other adversaries, as an honest party, this adversary will not circumvent defensive measures designed to protect the password.
2. DOM attacker. This adversary has full control of the web page’s DOM, able to read and modify the DOM at will. They can steal the password if it is ever included in the web page’s DOM. They can also attempt to trick password managers into autofilling passwords outside the legitimate login page (Silver et al., 2014; Stock and Johns, 2014; Oesch and Ruoti, 2020). However, this adversary’s capabilities are limited by security primitives built into the browser—they cannot violate the same origin policy (cannot directly access the password manager’s data) and do not have access to web requests or responses that the attacker did not generate.
3. Extension attacker. This attacker can read the headers and body of all web requests and responses, allowing them to steal any passwords in web request bodies (as visible through the webRequest API). While a malicious extension can also inject a client-side script, this capability is already covered by the DOM attacker, so when talking about the extension attacker, we are focused on their ability to read web requests and responses.
4. Man-in-the-middle (MitM) attacker. This is a network attacker who sits between the user’s device and the server. They can eavesdrop and modify network traffic as it is transmitted between the two. As we evaluate the security of password entry defenses, we consider two variants of this adversary: one that cannot break TLS-encrypted communication and one that can (e.g., an attacker who leverages a substitute certificate attack (O’Neill et al., 2016)).
5. Phisher. This adversary has full control of the web page visited by the user and the server where the password will be sent, being able to steal the password if it is entered into the web page or transmitted to the server. While this attacker must convince a user to visit the phishing web page, we assume this is feasible (Akerlof and Shiller, 2015). For simplicity, we combine compromised websites with phishers as the two attackers have the same capabilities.

In addition to these adversaries, we are also concerned with a supply chain attacker. This attacker compromises a library used by a server, a client-side web page, or a browser extension. At this point, the attacker has the same capabilities as a phisher, DOM attacker, and MitM attacker, respectively. Thus, we don’t evaluate this adversary separately from those adversaries. However, we mention them here to emphasize the feasibility of the other adversaries, as supply chain attacks can put users’ passwords at risk, even if the user exercises extreme caution (e.g., vetting all links, disabling client-side scripts, or vetting all extensions).
In our threat model, we intentionally consider a wide range of adversaries to better evaluate the design space for password autofill defenses. However, we consider several threats as out of scope. First, we consider compromised browsers and operating systems as out of scope. If these items are compromised, there is no need to steal credentials during the autofill process, as they can simply be stolen from memory after the password manager decrypts them.
Second, we do not consider session hijacking attacks. Poor cookie hygiene (e.g., failing to use HTTPOnly cookies) can allow session theft by any of our identified adversaries. However, existing defenses can prevent this attack for any adversary, up to and including a malicious extension (through token-bound cookies (Popov et al., 2018)).
Even if we exclude malicious extensions that can exfiltrate session cookies (using the cookie permission), there are still 11,452 extensions that can inject client-side scripts, 3,568 that can read requests’ bodies, and 1,294 that can read web requests’ bodies, but not inject client-side scripts. This indicates that even with this carveout there are a substantial number of extensions that satisfy our threat model.
Finally, we note that while malicious extensions may appear similar to a compromised browser, this is far from the case. First, most extensions have limited permissions, limiting the damage they can do when compromised. Second, even after granting a malicious extension every possible permission, it is still sandboxed by the same origin policy, meaning it cannot steal data stored by other extensions (i.e., the password manager). For these reasons, we believe it is reasonable to consider malicious extensions in scope but compromised browsers out of scope.

 

[Andy Ful]

Commercial password managers had some flaws too (published in the year 2020):

https://eprints.whiterose.ac.uk/158056/8/Revisiting_Security_Vulnerabilities_in_Commercial_Password_Managers_2.pdf

6 Conclusions This work has analysed and reported on vulnerabilities in commercial password managers through two distinct avenues: testing previously disclosed vulnera bilities and developing exploits for newly discovered vulnerabilities. Many of the previously reported vulnerabilities have been found to persist in popular password managers. Furthermore, four new vulnerabilities were found through extensive testing and responsibly disclosed to the corresponding vendors. Some were fixed immediately while others were deemed low priority. In our correspondence with password manager vendors we saw both positive and negative sides to how they deal with vulnerability disclosure. On the positive side, vendors appear to be quite responsive and issues deemed high priority or easily rectifiable are fixed promptly. On the negative side, issues assessed as low priority appear to be considered non-issues and rather too easily dismissed. We acknowledge that some issues, e.g. the clipboard vulnerability, do not have an easy fix and vendors faced with a choice between leaving a low priority issue and applying a fix that has side effects may choose the former. Apossible future direction would be developing rigorous security models and canonical security tests for password managers. The newly discovered vulnera bilities is this work were all user interface related vulnerabilities, as in they were discovered by testing the applications under typical operation scenarios. Such functionality tests along with further analyses focusing on architecture and pro cesses may serve as a basis for standard tests.

 

[Digmor Crusher]

Commercial password managers had some flaws too (published in the year 2020):

https://eprints.whiterose.ac.uk/158056/8/Revisiting_Security_Vulnerabilities_in_Commercial_Password_Managers_2.pdf

Interesting. Someone needs to do some current testing on a larger number of password managers. It would sure open some people's eyes.

 

[Gangelo]

Interesting article about password security in web browsers (from the year 2024):

Passwords Are Meant to Be Secret: A Practical Secure Password Entry Channel for Web Browsers

Andy, with all due respect, I believe that phishing alone is the number one online threat.

All the scenarios listed in the article you posted are extremely rare and highly unlikely to happen in real world.
If your browser / extensions and OS are up to date, and you use some kind of web protection and ad / tracker blocking and still get infected by these things, you must be extremely unlucky and have hit the jackpot (in the wrong way)..

 

[Andy Ful]

Andy, with all due respect, I believe that phishing alone is the number one online threat.

Yes, the ability to prevent credential phishing is one of the reasons for using password managers. This works in most cases but with some flaws. The flaw can be a problem because "phishing alone is the number one online thread."

All the scenarios listed in the article you posted are extremely rare and highly unlikely to happen in real world

Why do you think so? Are there more prevalent scenarios prevented by password managers?

1. Honest-but-curious entities (e.g., web trackers (Senol et al., 2022)). This entity can read the contents of any DOM element, including the password after it has been entered into the web page. Unlike the other adversaries, as an honest party, this adversary will not circumvent defensive measures designed to protect the password.
2. DOM attacker. This adversary has full control of the web page’s DOM, able to read and modify the DOM at will. They can steal the password if it is ever included in the web page’s DOM. They can also attempt to trick password managers into autofilling passwords outside the legitimate login page (Silver et al., 2014; Stock and Johns, 2014; Oesch and Ruoti, 2020). However, this adversary’s capabilities are limited by security primitives built into the browser—they cannot violate the same origin policy (cannot directly access the password manager’s data) and do not have access to web requests or responses that the attacker did not generate.
3. Extension attacker. This attacker can read the headers and body of all web requests and responses, allowing them to steal any passwords in web request bodies (as visible through the webRequest API). While a malicious extension can also inject a client-side script, this capability is already covered by the DOM attacker, so when talking about the extension attacker, we are focused on their ability to read web requests and responses.
4. Man-in-the-middle (MitM) attacker. This is a network attacker who sits between the user’s device and the server. They can eavesdrop and modify network traffic as it is transmitted between the two. As we evaluate the security of password entry defenses, we consider two variants of this adversary: one that cannot break TLS-encrypted communication and one that can (e.g., an attacker who leverages a substitute certificate attack (O’Neill et al., 2016)).
5. Phisher. This adversary has full control of the web page visited by the user and the server where the password will be sent, being able to steal the password if it is entered into the web page or transmitted to the server. While this attacker must convince a user to visit the phishing web page, we assume this is feasible (Akerlof and Shiller, 2015). For simplicity, we combine compromised websites with phishers as the two attackers have the same capabilities.

None of the above scenarios is extremely rare in the wild. Of course, you are right that it does not mean frequent password-stealing for the particular user. Many people in the world will be never attacked via those (or other possible) scenarios and are safe without using any password manager. But for most people (who use many online passwords), password managers can be an advantage.


Let's look again at the tips provided by the Canadian government that promote using password managers:

It is not an accident that we can see the tip:
Do not store passwords for sensitive accounts (e.g. banking, email)

 

[Andy Ful]

If your browser / extensions and OS are up to date, and you use some kind of web protection and ad / tracker blocking and still get infected by these things, you must be extremely unlucky and have hit the jackpot (in the wrong way)..

Good point.
Is a password manager required (except for convenience) with such a protection?
Is it possible that most MT members who use password managers do it mainly for convenience and not for security?

 

[oldschool]

Here's how Tavis Ormandy (of Project Zero) argues against password managers. Enjoy!

Introduction​

I’ve spent a lot of time trying to understand the attack surface of popular password managers. I think I’ve spent more time analyzing them than practically anybody else, and I think that qualifies me to have an opinion!

First, let’s get a few things out of the way. For some reason, few subjects can get heated faster than passwords. Maybe politics and religion, but that’s about it. It’s okay if you don’t like my opinion.

Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.

Okay, let’s begin.

If you just want some advice on what to use, skip to the conclusion.

Problems​

Conceptually, what could be simpler than a password manager? It’s just a trivial key-value store. In fact, the simplest implementations are usually great. Good examples of simple and safe password managers are keepass and keepassx, or even pass if you’re a nerd.

Things start to go wrong when you want integration with other applications, or when you want data synchronized by an untrusted intermediary. There are safe ways to achieve this, but the allure of recurring subscription fees has attracted businesses to this space with varying degrees of competence. I’m generally skeptical of these online subscription password managers, and that’s going to be the focus of the rest of this article.

Bad Advice​

I often say that “use a password manager” is bad advice. That’s because it’s difficult to tell the difference between a competent implementation and a naive one. The tech press can review usability and onboarding experience, but can’t realistically evaluate any security claims, so how do you propose users tell the difference? For that reason, I think “use a password manager” is so vague that it’s dangerous.

A good analogy is telling someone with a headache to pop any pills they find in the medicine cabinet. Maybe they’ll get lucky and find an aspirin, or maybe they won’t and you’ll be making a call to poison control.

Advice on this topic needs to be specific. It’s better to recommend implementations that are well designed, rather than general product categories. This position is surprisingly contentious, many people argue any password manager is acceptable and that I’m sowing fear by actually evaluating vendor claims. I remain unconvinced.

Attack Surface​

My primary area of interest is how remote attackers can interact with your password manager.

I’m not interested in things like testing how resistant encrypted blobs are to offline cracking. This might be a valid concern for some, but in most cases if an attacker is in a position to access or tamper with encrypted state, then you were in trouble whether you used a password manager or not.

There are two common issues I run into, the first is that trusted user interface elements are injected into potentially hostile websites. The second is that different components ipc over web-accessible channels (e.g. WebSockets, postMessage, etc.) without adequate mutual authentication.

Lets discuss user interface elements first.

Hostile Environments​

Most online password managers use content scripts, javascript that is inserted into every website you visit. It’s really easy to write content scripts, but really tough to make them tamper resistant. That’s kind of a problem, because they’re going to be hosted in hostile environments.

A good example of the kind of subtle ways this can go wrong is a bug like this. How isolated worlds interact is complicated enough, but password managers make matters even worse by blurring the distinction between user interface and content.

Chrome vs Content​

There are two primary components that make up your browser interface, the chrome (confusingly, the term has nothing to do with Google Chrome) and the content area. The chrome contains things like the address bar, tabs and back button. These components can be trusted, and websites can’t interfere with them. Conversely, anything inside the content area can be controlled by the website and therefore it can’t be trusted.

Most password managers blur this distinction by drawing their UI in the content area. There is just no way to do this safely, and it’s trivial to make demos that show why.

Frames​

Okay, but it’s not unusual to have different parts of the content area with different privileges, that’s basically how iframes work. That doesn’t make it safe though, and you’re probably familiar with X-Frame-Options, it’s a way for websites to opt-out of being framed. Most security conscious websites will do exactly that, because it’s just too easy for attackers to trick you into interacting with frames in unintended ways.

These are sometimes called redress attacks or clickjacking (groan, I hate that term). There’s a thorough analysis of the attack in the Browser Security Handbook.

If redress attacks are problematic enough to make everyone disable framing, should the software tasked with protecting your passwords also opt-out? That was a trick question, they can’t!

A Brief Illustration​

As I’m writing this, I happened to see a commercial for a new password manager called Nordpass. Let’s use it as a testcase and take a look. All online password managers work in a similar way, this isn’t specific to any one implementation.

Note: I’m deliberately trying to avoid finding specific vulnerabilities so that I don’t have to start the tedious formal disclosure process. This is just a general illustration of weaknesses inherent in these designs.

After installing the extension I immediately see that it uses content scripts to add interface elements to login forms.

In general, websites can interact with that UI, and quick testing confirms that is true here. It looks like I can style those elements too, that means trivial redress is possible.

This problem is pervasive among online password managers, you can never be sure if you’re interacting with a website or your password manager. Let’s make a quick demo.

Here is a quick example, you can try it out yourself if you have Nordpass installed, please excuse my terrible design skills.

This is a fundamental and unfixable problem with designs like this.

I’ve found many real, exploitable vulnerabilities in the way these UI elements work. Trivial ones like this, or this. Sometimes interaction isn’t even necessary.

Interprocess Communication​

We’ve already established that one component of online password managers must be injected into potentially hostile environments. How can those components communicate with other components?

One naive solution would be to just use XHR or WebSockets to a local HTTP endpoint. This sounds appealing to developers, they’re the native way to communicate on the web. The problem with this solution is it’s very difficult to differentiate between your content script, and a hostile script running on the same page but a different world.

Essentially every implementation I’ve looked at has got this wrong, resulting in critical game-over vulnerabilities. Some worst offenders are bugs like this, this.

Vendors come up with all kind of hacky solutions to this, often involving inherently racy background scripts that try to verify a tabs origin.

Sandboxes​

Another gripe I have with online password managers is that they render browser sandboxes less effective. Modern browsers use a sandbox architecture to isolate components that can go wrong.

The problem is that online password managers effectively inject privileged components into these sandboxed processes with extensions. The purpose of sandboxing is to isolate potentially compromised components from each other, but if you stuff all your most valuable secrets inside the sandbox - then what’s the point?

I worry that people don’t understand the tradeoff they’re making here.

Vendor Claims​

Despite what your vendor says, if their network is compromised, the attacker can read your passwords. Here are some selected marketing claims from password manager vendors:

• “No one apart from you, not even [us], has access to your passwords.”
• “[We keep] your information private, secure and hidden (even from us).”
• “Your data is secured in a way that only you can view and manage it. [Our] employees can’t”
• etc, etc.

These claims are all nonsense. An attacker (or malicious insider) in control of the vendor’s network can change the code that is served to your browser, and that code can obviously access your passwords. This isn’t farfetched, altering the content of websites (i.e. defacement) is so common that it’s practically a sport.

The reality is that you have to trust your vendor to maintain their infrastructure and keep it safe. The existence of encryption (“bank grade” or not) does not alter this.

Perhaps you think this isn’t a big deal, you already trusted them when you installed their software. Fine, but these claims are front and center in all marketing, so vendors must believe their customers care about it. I think these claims are bending the truth to assuage legitimate concerns.

More Claims​

It’s easy to poke holes in marketing fluff, but here are some other fun ones I noticed from real password manager vendors.

• Keystroke encryption protects everything you type from being read by cybercriminals. Oh, okay.
• Many of the .NET assemblies […] are obfuscated, so even using a disassembler users are unable to view critical areas of methods/functions/classes. Well, I certainly feel safer.
• etc, etc.

Conclusion​

If you want to use an online password manager, I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.

I use Chrome, but the other major browsers like Edge or Firefox are fine too. They can isolate their trusted UI from websites, they don’t break the sandbox security model, they have world-class security teams, and they couldn’t be easier to use.

No doubt there will be many people reading this who don’t like this advice. All I can say is I’ve heard all the arguments, and stand by my conclusions.

Password Managers.

 

[Gangelo]

Good point.
Is a password manager required (except for convenience) with such a protection?
Is it possible that most MT members who use password managers do it mainly for convenience and not for security?

I never said that one should never use a password manager, I just said that these kind of attacks are highly unlikely for an everyday user with an up to date system (and a degree of common sense).
It is just my humble opinion but I believe that the built in password manager of most browsers combined with encryption / 2FA (like MS authenticator for example) is most probably enough and more convenient.

Perhaps I have grown old and tired and lean the balance of security / convenience to the latter .

 

[Gangelo]

Here's how Tavis Ormandy (of Project Zero) argues against password managers. Enjoy!

Password Managers.

The conclusion is pretty much in line with my view on this matter.

 

[Andy Ful]

Interesting:

In the world of red team operations, locations which credentials are stored are always a target as it will allow access to other applications or lateral movement. Organizations which are utilizing Microsoft Edge or Google Chrome for storage the credentials of their users are vulnerable due to the abuse of CryptUnprotectData API (T1555.003). It should be noted that reading credentials stored in browsers doesn’t require any form of elevation and it is challenging for defensive teams to detect due to the high volume of events which are generated in case of monitoring.

I did not post the link, but there are many articles about abusing the CryptUnprotectData API. Unfortunately, the attacker can steal encrypted data and decrypt it remotely to avoid detection. Some tools use SMB protocols, so disabling SMB can increase the protection. It seems that there can be an advantage when using a dedicated password manager to protect against non-targeted attacks.

 

[Divine_Barakah]

you leak your password online to check, if it has been leaked

I don't think this is the case. In 1Password for example, Watchtower checks everything locally on the device including reused passwords, weak passwords, unsecured websites, and expiring items. The list of websites and your passwords are never sent yo 1Password.

https://1password.com/watchtower-privacy/

 

[TairikuOkami]

I don't think this is the case. In 1Password for example, Watchtower checks everything locally on the device including reused passwords, weak passwords, unsecured websites, and expiring items. The list of websites and your passwords are never sent yo 1Password.

The fact that it already provides the check is bad enough, since everything is exploitable, even locally. Like when Edge translator was leaking passwords, it just took the advantage of "a feature".