A benefit to password managers, at least some of them, is that they can look at the URL and only use autotype/autofill when on the correct site, which can help prevent pharming since if instead of https://www.example.com/ you go to examp1e dot com it won't autofill your credentials. What I want to know, and can't find anywhere, is whether DNS hijacking or poisoning, when taking you to a different site, will show to the browser, the user, and the password manager as the site you meant to go to or the fake one. That is, if you actually type example.com, and the browser thinks you're going to example.com because it's following the malicious DNS to maliciouswebsite dot com, does it show where it thinks you are or is it somehow able to resolve the actual URL and show that? I realize this is a very unlikely possibility, but I'm curious if the password manager would try to autofill on the malicious site because instead of example.com being resolved as x.x.x.x it's resolved as y.y.y.y, but as far as the browser and password manager know it's still example.com, or if it would go to y.y.y.y but since the actual URL for that is maliciouswebsite dot com that's what would ultimately be shown.

As a secondary, related question, if a public wifi router has been compromised for DNS poisoning, how and when does this affect your device when connecting to it, i.e. poisoning your DNS cache? Does it happen immediately upon connecting, or only for each query/entry as it's made?

2 Answers 2


If DNS is compromised in your location (i.e. DNS server changed to a malicious one like in DNSChanger malware or using DNS spoofing) then it can lead to visiting the wrong sites with the right name. Password managers cannot detect this.

But, today websites are usually on HTTPS and this is especially true when passwords need to be entered. HTTPS protects against this kind of attack - see Why doesn't DNS spoofing work against HTTPS sites?.

  • If HTTPS protects against this, why did I run across recent news when searching for this about large rises in DNS hijacking and Google's use of rAndOm CAsE for DNS name server queries to protect against it? And when I read about it originally a while back, it was presented as something to be aware of when using public wifi even if you're not worrying about being monitored via a MitM due to using HTTPS. Also, in the comments on that page, Patrick refers to a DV certificate, saying an attacker can bypass the key issue. Not sure what exactly that means or if it's true.
    – vertigo
    Commented Jan 23, 2023 at 16:43
  • @vertigo: "Patrick refers to a DV certificate, saying an attacker can bypass the key issue." - This is the case if (to cite) "you control the DNS or the final IP of the website". This is about a global server side attack, you are asking about a local client side attack instead. Commented Jan 23, 2023 at 17:52
  • @vertigo: "why did I run across recent news"* - because a) not all sites are on HTTPS (and I did not claim this) and b) most media like to present a simple and scary story, instead of more difficult to understand nuanced story. Commented Jan 23, 2023 at 17:54
  • Thanks for the clarification. That news I came across was on technical news sites on which I find things to be more level-headed and fact-based rather than typical fear-mongering and hyperbole for clicks, so it seemed to indicate a widespread issue. And considering how few sites aren't HTTPS anymore, especially important ones, it seems strange Google and others are putting such an effort into securing this.
    – vertigo
    Commented Jan 23, 2023 at 21:29
  • This article is the one about the random case usage in DNS queries. I realize it's a non-local attack and so not directly relevant to the main question, but it does imply this is still an issue even with HTTPS sites. I assume that's because it's non-local, and the point is a local attack is defended against with HTTPS, and so it's not a concern of using public wifi, whereas HTTPS doesn't protect against non-local attacks, but that will be the case regardless of using a public network. Correct?
    – vertigo
    Commented Jan 23, 2023 at 21:38

[Disclosure: I work for 1Password]

The scenario you describe isn't specific to password managers. If a bogus site can successfully pass itself off as example.com then people entering passwords on that site can be tricked into giving secrets to that bogus site. But in general, it is a lot harder to fool a password manager than it is to fool a human.

As Steffen Ullrich correctly pointed out that if your system (browser in conjunction with your operating system) can't tell that the site you are talking to isn't the legitimate example.com then the password manager can't either. He correctly added that an important part of what TLS does is provide ways for the system to not be fooled by mere DNS trickery or malicious network routing. Quite simply it is really important to pay attention to browser warnings about site certifications or insecure sites.

Quite simply the specific attack you describe is no longer a thing. But it does raise some points about password managers.

Disable automatic autofill

Ideally, a password manager should require some human action before filling a site. If a password manager silently fills pages without user approval, then a site that does manage to fool the password manager could capture credentials without the user being aware of it. This threat has been known and document for decades, but many password managers only recently started to require human action. If you are using a password manager that does silent automatic autofill turn that "feature" off. (I will add that 1Password never offered automatic autofill. A human must always be in the loop before 1Password will give a password to a web page.)

Defending against HTTP downgrade

One attack that was quite popular for a time was SSLstripping. When you go to https://example.com you have the assurances provided by TLS and the Certificate Authority system that it really is run by the bona fide owners of example.com. But when you go to http://example.com (without the S of HTTS) you are subject to the kinds of attacks you describe in the question.

For many years most password managers would happily serve up passwords you had stored for https://example.com to http://example.com. That is password managers treated passwords you saved for example.com as being for example.com irrespective of whether these were HTTP or HTTPS. That was a misdesign.

Good password managers today will not do that. If you have a password saved for https://example.com they will no longer fill those passwords into http://example.com, or at least they won't do so without warning you and seeking your explicit approval to do so. Additionally, browsers (and web standards) have improved to make that kind of attack harder to go undetected.

Anyway, these sorts of threats have been known to the designers of password managers for a very long time. There are (or at least there were) differences in how aggressively password managers defend against them.

  • Thanks. I admit I use autofill because it's very convenient and I've never had an issue. I am also careful about making sure I'm on the correct site, especially for important ones. As I find it very unlikely I'd find myself in a situation where the password manager would be fooled into auto-filling when it shouldn't, and I've never had it happen in the ~15 years I've been using it (though I suppose your point is I may not have known), I haven't seen this as a big enough concern to worry about. But it's definitely something I need to look more into. Just not sure how it would be fooled.
    – vertigo
    Commented Jan 24, 2023 at 23:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .