8

Whenever I go to the Netflix main page in Firefox, I'm automatically logged in.

However, when I open up Firefox's list of saved passwords, I notice that Netflix is not among the sites Firefox is keeping passwords for (Options -> Security -> Saved Passwords)

How does Netflix know the password if Firefox isn't storing it, and where is it being stored?

Jawa
  • 3,619
  • 13
  • 31
  • 36
Raven Dreamer
  • 2,331
  • 4
  • 21
  • 24
  • 21
    I fail to see what part of this scenario makes you think they know your password. Basically all you've said is "I just got a Chromecast." and "Firefox hasn't saved my Netflix password." What is it about those two facts that makes you believe Netflix has your password? I'm guessing this misunderstanding has arisen from something other than what you've listed in your current question. Perhaps you could edit to explain what that "something" is? – Ajedi32 Dec 26 '14 at 22:02
  • 1
    @Ajedi32 Honestly, I just had a mental misfire, and assumed that because I am logged in whenever I open Netflix, it was firefox doing the logging-in. Totally forgot that cookies were a thing. – Raven Dreamer Dec 27 '14 at 00:47
  • 4
    So in fact the Chromecast is completely irrelevant. – David Z Dec 27 '14 at 04:55
  • @DavidZ Unless someone had information on how to use it through Firefox... yes. – Raven Dreamer Dec 27 '14 at 15:39
  • @RavenDreamer That would be a different question; so irrelevant regardless. – OJFord Dec 27 '14 at 21:31

4 Answers4

31

To answer your first question, Netflix doesn't know your password.

What Netflix and every other competent website out there does is hash your password using a one-way hashing scheme (MD5, SHA-1, SHA-2, etc.).

What this does is essentially create a unique fixed-length hexadecimal fingerprint that identifies the string of text that is your password. For instance, here's what my-secure-password looks like after being hashed using MD5:

MD5 hashing

They store this hash in their internal database and every time you log into Netflix, the password you supply during the login process is hashed once again using the same scheme and is matched against the copy of the hashed password stored in their database.

If they match, they know that you've entered the correct password and you're granted access. If they don't, you're not authenticated. This is why when you click on some variation of the Forgot password link they don't send you your old password but rather ask you to choose a new one. It's because they don't know what your password is either.

So how are you logged in if Firefox did not store the password for Netflix?

The answer to that is session cookies. When you logged into Netflix (maybe a while ago), you may have chosen to remember your session.
remember me?

If you did, Firefox stores a small tidbit of information on your computer that uniquely identifies you whenever you visit Netflix. These 'cookies' as they are called generally persist for a short period time until the session is active and then expire. Some however may last weeks or longer. Delete that cookie and Netflix won't remember you.

Netflix cookies

Regarding your second question, if Firefox didn't 'remember' the password, it isn't stored anywhere. What's stored is the cookie. Firefox stores them in its Profiles folder in the file cookies.sqlite which is a SQLite database file.

Lastly, if you opted to log in through your Facebook account, you wouldn't need a password and so Firefox wouldn't store one.

login using Facebook

However, a cookie would still be created to identify your session.

Vinayak
  • 10,625
  • 10
  • 54
  • 89
  • 2
    MD5 is not really "one-way" anymore. Tools like Google and several other huge databases that precomputed all the combinations can easily let you get your original string back. Password checking is actually a pretty complex process these days. – Derek 朕會功夫 Dec 26 '14 at 22:13
  • 23
    MD5 **is** one-way because it's a hash function. Saying that it isn't would imply that you could somehow obtain the original data from an MD5 hash through a cryptographic process. You can't. The tools you mention can 'reverse' the hash only because they've invested significant computer power to brute-force all sorts of password combinations to arrive at the original password string. This doesn't mean MD5 is reversible. Hashing is different from encryption where you can decrypt the data if you have the key. Also with hashing, no matter how long the input, the output is always fixed-length. – Vinayak Dec 26 '14 at 22:26
  • 2
    So, if I were to generate a MD5 hash of a very large data set (say, a 15 Kilobyte plain text file - which is just text, so you could think of it as an extremely long password) I'd still end up with a hash that is 32 bytes long. I don't think any computer in the world is capable of 'reversing' that hash to re-create the original plaintext file. – Vinayak Dec 26 '14 at 22:30
  • It's obvious that hashing is not supposed to be reversible, however the point is that an old or bad design can be easily reversed like decrypting an encoded string, that's why companies won't use MD5 for password checking but only for file checking. – Derek 朕會功夫 Dec 26 '14 at 22:31
  • @Derek朕會功夫 I agree. MD5 is not secure enough to be used to store user passwords because it's fairly less time consuming to compute MD5 hashes than it is to say, compute SHA-2 hashes, which is probably why attacking MD5 hashes is still viable. It's not good enough to store weak passwords like **`password`** but then again, SHA-2 wouldn't help much either if users use dictionary words in their passwords. – Vinayak Dec 26 '14 at 22:35
  • 16
    @Derek朕會功夫 MD5 is cryptographically "broken", but this is about **collisions**, not pre-images (which matter for passwords). MD5 is also bad for passwords, but this is because it is **fast**, so you can brute-force many passwords in a short time (and this is the same for more state-of-the-art hash functions like SHA-2 and SHA-3). See http://crypto.stackexchange.com/a/28/58. – Paŭlo Ebermann Dec 26 '14 at 23:09
  • 9
    I have to downvote just for the MD5 example, however good the rest of the answer may be. This is just not something you want to read in 2014 (soon to be 2015). It was never a good idea to use raw MD5 (even with a salt) to store passwords, and most people realized that over the course of the last 10 years. -1 – Thomas Dec 27 '14 at 00:06
  • 8
    @Thomas I'm sorry you feel that way but my answer was never supposed to be a guide to choosing the best hashing scheme. SuperUser isn't StackOverflow and like it or not, MD5 still is a cryptographic hash function so I don't see what's wrong with explaining what a hash is with the example of MD5. – Vinayak Dec 27 '14 at 01:28
  • 4
    You guys are using two different definitions of the term "one-way". There's the [mathematical definition](http://mathworld.wolfram.com/Many-to-One.html) which simply means "not injective," and then there's the [computer science definition](http://en.wikipedia.org/wiki/One-way_function) which means "cryptographically secure." When discussing cryptographic hash functions we always use the second definition, so the statement "MD5 is no longer one-way" is correct. – BlueRaja - Danny Pflughoeft Dec 27 '14 at 06:43
  • @Thomas Using a salt and one single invocation of MD5 is a lot more secure than the method commonly used before the MD5 approach was introduced. And in fact to this day using a single invocation of MD5 with a salt is still secure for those users who use good passwords. Stronger algorithms are entirely for the benefit of those users who cannot chose good passwords. That said, nobody designing a new system today should rely on anything weaker than SHA2. – kasperd Dec 27 '14 at 16:10
  • 7
    @kasperd "And in fact to this day using a single invocation of MD5 with a salt is still secure for those users who use good passwords." No. Please do not spread misinformation. A single invocation of MD5 is completely inadequate. – Ayrx Dec 27 '14 at 16:47
  • 3
    @TerryChia Here is a salted hash of my password. And knowing the strength of it, I am not the slightest bit worried about having the salted hash publicly known `$1$6kXWoBde$ycaVUKClUGuqnugceZVn..`. In fact I am so confident I'll even show you an unsalted MD5 of the same password. `888adeb452573003f3ea87f2b9f817ca`. I can assure you nobody is going to figure out what that password is. MD5 is adequate for a password of the strength I am using. Weaker passwords not so much, but I don't pick weak passwords. – kasperd Dec 27 '14 at 23:45
  • @kasperd *Most people* don't have strong 20+ character passwords and use the same password in several different places, which is why we need those slow password hashing functions in the general case. If everyone had a strong password and never reused the same one on any two sites you could even argue you don't need a salt at all. But that's not the case in the real world, so almost any real life system is going to have to cater to that majority of users who "cannot choose good passwords". Therefore the use of debating MD5+salt password hashing systems is questionable (or an academic exercise). – Thomas Dec 29 '14 at 03:43
  • @kasperd: Collisions can be generated [on-demand for MD5](http://www.crypto-hash.fr/modules/wfdownloads/singlefile.php?cid=13&lid=14), making it completely insecure. Note that this is not the same vulnerability as "finding out your password". Your argument is a [straw man](http://en.wikipedia.org/wiki/Straw_man); please stop spreading misinformation. – BlueRaja - Danny Pflughoeft Dec 29 '14 at 04:06
  • @BlueRaja I am not the one spreading misinformation. Claiming that it was never a good idea to use MD5 for password hashing is just plain wrong. The standard algorithm for hashing passwords with MD5 was published before the first vulnerability in MD5. Additionally that algorithm was significantly stronger than the algorithms it replaced. We have better algorithms today, so no new system should use MD5. But it is a fact that MD5 based password hashing has not yet been broken. – kasperd Dec 29 '14 at 07:20
  • 1
    This argument is non-constructive. The question was not about hashing. If you want to improve the answer, do so - arguing about whether or not the example is appropriate is pointless. I would recommend researching what Netflix is using (if it's publicly known) first though, since that would be most relevant to the actual question. – zeel Jan 09 '15 at 19:55
10

Netflix – like most other websites – doesn't care about your password during normal browsing. Instead, when you log in, Netflix has the browser store a 'cookie' with the login session ID. The browser sends it back every time it requests a new page. (Likewise, the password storage in Firefox is not used during normal browsing, but only for auto-filling the password field in login pages.)

The session cookies are usually generated randomly and don't have any relation to your login or password – only Netflix itself can link it to your account.

To see them, right-click the page, select "View Page Info", and under "Security" click "View Cookies".

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
5

There's nothing wrong with Netflix. Just like almost all websites that you can log on, it stores a cookie on your PC which among other things, stores an encrypted data representing your password.

Haven't you seen the same behavior on Google, Facebook, Yahoo, Windows Live and whatever account you may think of?

Some web services may use cookies that are valid only for a short period of time or only in the current session (for example Yahoo and Facebook unless you select a Remember me on this computer option). But apparently Netflix uses cookies that are valid for a longer period of time which keeps you logged on unless you delete your browser history - especially cookies.

Now, you may be asking what's the use of password store in the browser. That's very simple. If you log out from Netflix (or whatever else) the cookie gets deleted. If you want to log back in you'll have to enter both the account username and the password. If you have saved your password in the browser, it will autocomplete that field when you type the username.

Cornelius
  • 2,754
  • 1
  • 16
  • 26
  • 10
    Clarification – cookies don't contain any data representing passwords. Rather, they contain random data that identifies a *session* associated with your account. The sessions are stored on the server. – ntoskrnl Dec 26 '14 at 19:37
0

Did you check your cookies? Your password, or an encrypted copy of your password, might be there.

hymie
  • 1,256
  • 11
  • 18
  • 5
    That would be a terribly insecure design. Common practice is to use a session cookie which is not related to the password in any way. – kasperd Dec 27 '14 at 16:12
  • It doesn't really matter exactly specificially what he finds there. He should check his cookies. – hymie Dec 27 '14 at 23:25