18

Most browsers offer to save the password after entering it on many logon pages. What types of vulnerabilities are there for such saved passwords. I'm interested in what ways malware on web pages that are accessed later might be able to retrieve the passwords (or make use of them). Are there vulnerabilities from these things (or others)?:

  • plain html
  • javascript
  • flash
  • java
  • pdf

I'm talking about vanilla password saving, not the (presumably) more-protected systems using things like master passwords as discussed in this other question.

Improve this question
3

4 Answers 4

Reset to default
7

I still think it is worth noting what that other question doesn't: the main vulnerability is that many browsers store passwords as plain text or weakly obscured. If this is the case, than anyone with momentary access to your computer can just grab the whole lot. So setting a Master Password or the equivalent is important.

Note that some browsers don't even implement encryption of passwords.

Besides that, if the browser, or the sorts of related viewer software that you list, has unpatched bugs, an attacker naturally may get access to passwords along with broader opportunities to compromise the whole system. Keep those systems patched, and be careful when browsing!

Improve this answer
4
  • Judging by the last line of the question I think that the user is aware of the limitations of plaintext storage.
    – john
    May 10, 2011 at 1:09
  • @john Yes, the original poster seems aware of it, but as I noted I just wanted it on the record for other viewers, since the page referred to also doesn't really make the case, and the title of this question is appropriately broad.
    – nealmcb
    May 10, 2011 at 2:25
  • "many browsers store passwords as plain text or weakly obscured", "some browsers don't even implement encryption of passwords": which browsers?
    – Rodrigo
    Feb 26, 2016 at 13:15
  • @Rodrigo It depends in complex ways on the combination of browser, OS, etc. See e.g. security.stackexchange.com/questions/40884/…
    – nealmcb
    Feb 27, 2016 at 20:23
6

Passwords saved in a file without protection (by a non-stored master password) are a bad idea because a vulnerability in some piece of software (be it a browser or not) could allow the attacker to upload the file. Examples (not the only ones!): CVE-2006-1729, CVE-2011-0167. Files in the browser profile are especially at risk (I can't find a reference right now but remember seeing bugs that only exposed the profile directory).

While a browser bug could, after all, give the attacker access to the in-memory password storage, file upload bugs can be more subtle (CVE-2007-3511: accidental file upload by shifting the input focus) and harder to fix without breaking useful functionality (logic error, unlike arbitrary code execution bugs which are typically simple once the bug is located).

Improve this answer
3
  • 1
    But requiring users to type in a master password is not very user-friendly and may cause users to behave insecurely. Thus, I suspect the security costs of your proposal may exceed the benefits.
    – D.W.
    May 11, 2011 at 0:51
  • 1
    @D.W. As a UX matter, ideally, the passwords should be typed into a keychain application, and the browser should always query that keychain application and never the user directly. Since only the keychain application asks for a password, the user doesn't get into the habit of typing a password at some random prompt. So I disagree that the master password approach, if done right, is user-unfriendly. I do agree that most current browsers lack the necessary OS integration.
    – Gilles 'SO- stop being evil'
    May 11, 2011 at 8:18
  • 1
    good points, thanks for the explanation. That makes sense. In addition to the fact that some browsers lack the necessarily OS integration, I suspect some OS's do not provide the support that would be needed to do this right. It's a shame.
    – D.W.
    May 11, 2011 at 8:24
6

Assuming that as you say you don't use a master password, and so the password database is stored in clear text: It depends on what kind of malware you refer to. If there is a 0day exploit (or you use an unpatched browser), which 'breaks out of', embedded in any of the things you mention, effectively causing arbitrary code execution on your host, then that malware will be able to recover the whole database (but that will be the least of your worries).

In the common case of simple javascript execution (by xss for example), the script may be able to capture the password associated with the forms of that specific page. Again, if there is a unpatched flaw in the browser which the script takes advantage of, like breaking the Same Origin Policy protections of the browser, then it might be able recover any password from the database.

Finally, if the attacker can not 'trick the browser' (as in attacking a vulnerability), he may also in the end try to 'trick the user' - think social engineering - by using some subtle way to make it so that you send the database yourself without noticing it.

Improve this answer
1

To clarify and maybe dispute what John is saying - I am not sure you need to break same origin policy to take advantage of an xss vuln in a website in order to grab saved credentials. Some JavaScript to parse the forms and send them to a third party wouldn't need to break same origin.

Improve this answer
3
  • Maybe I wasn't not clear enough: afaik, the same origin policy needs to be broken in order for the script to obtain credentials for different sites than the one the xss vulnerability is on. If it is not broken then the script can obtain credentials only for that specific site. Is your dispute on this statement?
    – john
    May 10, 2011 at 1:37
  • 1
    Yep. We are on the same page. Sorry for the misunderstanding. Though I can't wrap my head around how xss plus a broken same origin policy can lead to stolen credentials from other sites on that local machine. Have a link to further reference?
    – getahobby
    May 10, 2011 at 2:46
  • 1
    I'm afraid I don't have a link from the top of my head. The general idea is that if same origin policy does not apply, a script can run under the context of any other page or access the dom of other pages. This way it may be able to load an iframe and access form data on it - and this iframe may be gmail for example. Maybe I'm reaching though, I'd love the opinion of someone more experience in this sort of thing.
    – john
    May 10, 2011 at 3:00

You must log in to answer this question.

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