I see lots of articles suggesting not storing passwords in the browser, and it made perfect sense to me, if I can access this data easily, an attacker probably can too.

But then I found out about cookie hijacking, and it seems to me that if your browser is compromised you are already susceptible to this attack that seems much worse (because it can even bypass MFA, since the user is already authenticated).

Stealing passwords stored in the browser would still be dangerous because an attacker could try these passwords in other services, but if I'm already using different passwords for each service, and MFA whenever possible, is the extra security from not storing passwords in browser really worth the convenience loss?

  • 1
    I think your question really is, "how much of a threat is cookie hijacking?"
    – schroeder
    Commented Nov 22, 2023 at 14:53
  • 1
  • 2
    This is what's actually happening with the Youtube hacks: kaspersky.com/blog/youtubers-takeovers/48375
    – schroeder
    Commented Nov 22, 2023 at 15:02
  • 1
    As you can see from the other links, there is usually more going on to protect a session. So, 1. it's not a universal problem, and 2. you can't compare the threats and risks between the potential for cookie passing on a vulnerable site and storing all passwords in the browser's local storage.
    – schroeder
    Commented Nov 22, 2023 at 15:05
  • 1
    @LvB I wasn't meaning "Local Storage" <sup>TM</sup> but "stored locally"
    – schroeder
    Commented Nov 22, 2023 at 15:19

1 Answer 1


Hmm, lets see. is having a token that is only valid for 'x' time as much of a threat as having the keys to make new tokens....

aside from the answer 178663... why stealing cookie isn't enough lets look into what exactly is the difference between these 2 type of tokens.

  • Session token:
    • has limited lifetime
    • can be locked to a connection / IP / Device.
    • is given after authentication & authorization.
  • User name & Password (called: Credentials)
    • is valid until changed at the source of truth.
    • can not be (easily) locked to connection /IP /Device.
    • can be used to get (new) Session tokens
    • Can typically be used in parallel with the original owner without notice.
    • is often shared on multiple places. (password sharing problem...)

in conclusion, while both a token and a credential can be used to do requests in the users name. only 1 has real re-use capability. There are also a myriad of methods to enhance the security of session tokens and limit there abusive use (something Google still hasn't perfected for there high value targets like Youtubers).

another thing is that you can lock sessions to devices and connections... and even make them have short lifetime. which would make the window of effective use small.

in short, storing passwords in your browser is better than nothing, but still a bad idea.. the session tokens stored in browsers are much less an issue, if security measures are properly employed by the application builder.

You must log in to answer this question.

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