Password Downloads - Instagram leaks user passwords in plaintext

[rcmaehl]

Source:
Sophos
 

Summary:

Instagrams' new GDPR tool for downloading your data leaked user passwords in plain text. "Only a handful of users affected"

 

Quotes/Excerpts:

Quote

Instagram released the long-anticipated download your data tool. The feature gave users the ability to download images, posts and comments. Unfortunately, Instagram turned the task of downloading your data into an exercise in exposing people’s passwords in plain text. Thankfully, the bug in the “download your data” tool only affected a handful of users, it said. It means that anybody who used the tool on a public computer – say, in a library – had their password exposed in the URL: an unfortunate gift to any shoulder surfers who may have been around. Facebook didn’t say whether anybody’s Instagram account was compromised because of the error. This never would have happened if Instagram was doing encryption right. For the Facebook-owned Instagram to be able to trip up and post plaintext passwords in URLs, that means that somewhere inside of Instagram, users’ passwords are bouncing around in plain text. 

 

My Thoughts:

Ironic. A tool meant to comply with GDPR has ended up being a GDPR violation in itself. Facebook is seemingly making a large amount of security mistakes, perhaps it's time for some regulatory oversight?

[ARikozuM]

[Tech Enthusiast]

I am unsure if not using any encryption at all, ... or using the browser bar to pass around data is the worse offense.

Seriously, both are inexcusable.

[HarryNyquist]

A privacy and security violation by a Facebook property, who would have guessed. I don't care if it was a glitch or not a glitch, passwords should be IRRETRIEVABLE, PERIOD.

 

ONE WAY ENCRYPTION

 

GRAAAAAH

[Syntaxvgm]

3 minutes ago, HarryNyquist said:

A privacy and security violation by a Facebook property, who would have guessed. I don't care if it was a glitch or not a glitch, passwords should be IRRETRIEVABLE, PERIOD.

 

ONE WAY ENCRYPTION

 

GRAAAAAH

Hash, salt, and pepper. 

[rcmaehl]

2 minutes ago, Syntaxvgm said:

Hash, salt, and pepper. 

Soup, salad, breadsticks

[Tech Enthusiast]

5 minutes ago, HarryNyquist said:

I don't care if it was a glitch or not a glitch

It can't be a glitch.

ANY variable (like a password) somehow has to make its way to the address bar. It does not magically jump up there, without someone explicitly writing code that does exactly that.

 

So one coder explicitly wrote code that used the address bar as a way to transport variables from place A to B. That in itself is silly.

Then this coder, or worse: another one, ... decided it was a great idea to use this "data transfer" method to pass along a password.

And then we get to the third issue: Someone also decided it was a good idea to not encode said password, which it should have been, even if it would not have ended up in the freaking address bar due to a 1990 way of passing data around.

[Coaxialgamer]

WHY is Instagram EVEN STORING these passwords AT ALL?

[Tech Enthusiast]

Just now, Coaxialgamer said:

WHY is Instagram EVEN STORING these passwords AT ALL?

Well, it has to be stored somewhere, you know... in order to be checked against for the use case of a user wanting to log in.

There is many bad things happening here, but storing the password is not one of them.

[Coaxialgamer]

Just now, Tech Enthusiast said:

Well, it has to be stored somewhere, you know... in order to be checked against for the use case of a user wanting to log in.

There is many bad things happening here, but storing the password is not one of them.

They don't need to store passwords , and never should have. No secure site ever stores these , let alone in plain text.

 

[Tech Enthusiast]

Just now, Coaxialgamer said:

They don't need to store passwords , and never should have. No secure site ever stores these , let alone in plain text.

 

So, how do these sites check if you entered the correct password, if they don't have it stored? (I agree on the plain text thing, as mentioned before)

[Coaxialgamer]

Just now, Tech Enthusiast said:

So, how do these sites check if you entered the correct password, if they don't have it stored? (I agree on the plain text thing, as mentioned before)

Why do you think sites usually make you set a new password when you forget your existing one , instead of just sending it you ? It's precisely because they can't.

Websites only stores the hashes of user passwords , which are salted for good measure (a random string is added in to the input so that identical passwords don't have matching hashes). When a user enters a password, the input is hashes and checked against the stored info. If it matches , the password is correct (that's a property of hashing algorithms: two identical inputs produce the same hash). 

Not only should Instagram not have had these plain text passwords in their database , they shouldn't even have the KEYS for decrypting them.

[HarryNyquist]

4 minutes ago, Tech Enthusiast said:

So, how do these sites check if you entered the correct password, if they don't have it stored? (I agree on the plain text thing, as mentioned before)

At the absolute minimum, the plaintext password is taken, and its hash value is computed. The hash function produces the same output for any input, say, 'hunter2' passed through the MD5 hash function would become 6a0f0731d84afa4082031e3a72354991.

 

This hash is what gets stored. Storing something like that MD5 hash alone is very insecure, because MD5 has such a small space that rainbow tables, giant tables of hash values & corresponding plaintext, can be easily consulted to "decrypt" the password.

 

To prevent this vulnerability (or mitigate it), the plaintext password gets salted with another value. A common (and bad) practice is to use the username as a salt, so instead of hashing just 'hunter2', the plaintext to be hashed becomes 'stupid_redditor:hunter2' or something. That adds complexity and makes it more difficult to crack.

 

The best kind of hash is one that uses a random salt, and has modifiable parameters for hashing (such as multiple hash iterations) that will exponentially increase the complexity of the hash and the difficulty of both brute-force cracking and rainbow table cracks (say, the bcrypt hashing function).

 

 

[Guest]

Quote

It means that anybody who used the tool on a public computer – say, in a library – had their password exposed in the URL: an unfortunate gift to any shoulder surfers who may have been around. Facebook didn’t say whether anybody’s Instagram account was compromised because of the error. 

I would call this compromised. 

[Speed Weed]

Dam, we are still not using encryption technology in 2018?

[Mira Yurizaki]

6 minutes ago, Speed Weed said:

Dam, we are still not using encryption technology in 2018?

While this would be better than plaintext, using encryption to store passwords is much weaker than something like cryptographic hashing with salt.

 

So basically, unless the website is using hash and salt to store your passwords, you shouldn't consider it all that secure.

 

[Speed Weed]

Just now, M.Yurizaki said:

While this would be better than plaintext, using encryption to store passwords is much weaker than something like cryptographic hashing with salt.

  

So basically, unless the website is using hash and salt to store your passwords, you shouldn't consider it all that secure.

 

Encryption make it more difficult to crack than a plain text. This is 2018, and we should have no excuse to not use encryption technology while hackers are already using them to encrypted our files with ransomware. 

[imreloadin]

58 minutes ago, Syntaxvgm said:

Hash, salt, and pepper. 

Who knew that encryption and my hash-browns would go hand in hand so nicely

[ClassicalBlueTooth]

Is there a way to know if you have been affected by this?

 

Edit: They have sent out notifications to affected users.

Edited November 20, 2018 by ClassicalBlueTooth
Dumb question

[Mira Yurizaki]

3 minutes ago, Speed Weed said:

Encryption make it more difficult to crack than a plain text. This is 2018, and we should have no excuse to not use encryption technology while hackers are already using them to encrypted our files with ransomware. 

Well sure, that's why I said encryption is better than plain text. But it's still much weaker than hashing + salt. The problem with encryption is:

• You need a key to encrypt something and the database has to be able to know what that key is. This basically means storing a "master password" in plaintext somewhere on the server itself.
• Encryption spits out the same thing every time. Given how popular dumb passwords are like "password" and "123456", an attacker could gain control of a lot of accounts.
• Encryption methods produce a varying amount of data for a given input. AES-128 for example, spits out 16 bytes for up to every 16 bytes you spit into it. This provides clues to an attacker how long the password is.

Hashing + salt is much better because it has none of those flaws.

[Speed Weed]

2 minutes ago, M.Yurizaki said:

Well sure, that's why I said encryption is better than plain text. But it's still much weaker than hashing + salt. The problem with encryption is:

• You need a key to encrypt something and the database has to be able to know what that key is. This basically means storing a "master password" in plaintext somewhere on the server itself.
•  Encryption spits out the same thing every time. Given how popular dumb passwords are like "password" and "123456", an attacker could gain control of a lot of accounts.
•  Encryption methods produce a varying amount of data for a given input. AES-128 for example, spits out 16 bytes for up to every 16 bytes you spit into it. This provides clues to an attacker how long the password is.

Hashing + salt is much better because it has none of those flaws.

Very interesting. Do you mind to explain the pros and cons of hashing + salt and how is it more benefit than encryption? 

[Mira Yurizaki]

1 minute ago, Speed Weed said:

Very interesting. Do you mind to explain the pros and cons of hashing + salt and how is it more benefit than encryption? 

Pros:

• No key is needed.
• The output is theoretically different every time for a given input.
• The output is the same size regardless of input, so you can't tell how big the input originally was.

Cons:

• Since hashing is theoretically irreversible, if you change the hashing algorithm, everyone has to update their passwords.
  • This is contrast with encryption, if you want to change the encryption method, you just decrypt the passwords and encrypt using the new method.
• Some hashing algorithms can be computationally expensive.
  • This actually is a pro in some regard, as this discourages brute-force attacks.

 

On a side note, it's possible that if the website gives you a plaintext password, it may be using encryption because it can still give you your password in plaintext.

[Tech Enthusiast]

1 hour ago, Coaxialgamer said:

When a user enters a password, the input is hashes and checked against the stored info. If it matches , the password is correct

And that is exactly what i said.

The password is stored. It has to be stored to be checked against. 

I never said anything about plain text apart from plain text being sucky as hell. How a PW is stored does not change the fact that it is stored. It can be hased, salted, and a cherry could be placed on top, it is still stored.

Returning the PW to the user was never in question, however to be quite frank here: If you can encrypt a PW, you can decrypt it as well. It just sounds better if you claim you can not. I am unaware of any method to encrypt something that can't be reveresed with exactly the same steps in reverse.

 

That however, does not change the fact that these idiots used unencryped PWs and even put them up for grabs in the address bar.

[kuhnertdm]

Having trouble putting 2 and 2 together here... This leak does not necessarily confirm that passwords were stored on the server in plaintext, only that plaintext passwords were sent to the server. The Sophos article says that Facebook/Instagram said that passwords were stored in plaintext in the user notice they sent out, but I can't confirm that in the original article, which is locked behind a paywall. Can anyone confirm or deny that Facebook/Instagram actually said this? It's very possible that either of these sources is making a false conclusion here, either due to incompetence or wanting to get a bigger headline.

 

EDIT: Never mind, this source has specific text from the notice in it, which specifies that plaintext passwords were stored on the server. It seem that this was a direct result of the way they were doing this particular feature, though, and not the way that they were typically storing passwords for login purposes. That explains why it's connected to the leak.

Edited November 20, 2018 by kuhnerdm

[kuhnertdm]

Also, lots of misinformation in this thread:

 

• This does not necessarily mean that they were storing passwords in plaintext for login purposes, only that they were doing that for this particular feature. Still a vulnerability with equal risk, but at least the people developing the core product had better sense.
• Hashing with a salt is a form of encryption. It's not "encryption vs hash/salt". The real dichotomy is "one-way encryption vs two-way encryption"
• Using a salt does NOT make a bad hashing algorithm better! Using a salt basically tacks something unique to every user onto their password before the hash. That salt is just as visible as the hash itself. Suppose my password is "hunter2", and my salt is "12345". The result of hashing "hunter2|12345" in MD5 is still likely to be easily decryptable. In fact, it's exactly as decryptable as if my password were literally "hunter2|12345", and a salt were not used. The way to make your password storage more secure is to use a better algorithm, like bcrypt.
• If you are using two-way encryption for your password storage, then you must be storing keys somewhere on your machine. This gives you the exact same risk as if you were storing plaintext passwords on your machine. Again, this relates to the false comparison of "hashing vs encryption." If you're saying that "encryption" here is equivalent to "two-way encryption", then the comparison becomes "safe vs no protection whatsoever".