Jump to content
Phishing Emails & YouTube Messages - Fake Giveaway Read more... ×
Search In
  • More options...
Find results that contain...
Find results in...
rcmaehl

Password Downloads - Instagram leaks user passwords in plaintext

Recommended Posts

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".
Link to post
Share on other sites
13 hours ago, Tech Enthusiast said:

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.

Not really using url queries is a nice way to add functionality to a get request, for example at work I have routes that will change what data you get back based on queries. E.g sending ?completed=true will 9nly return items marked as completed.

 

Using it to move sensitive is super irresponsible.


                     ¸„»°'´¸„»°'´ Vorticalbox `'°«„¸`'°«„¸
`'°«„¸¸„»°'´¸„»°'´`'°«„¸Scientia Potentia est  ¸„»°'´`'°«„¸`'°«„¸¸„»°'´

Link to post
Share on other sites
18 hours ago, 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. 😉

That's what hashing of passwords is for. They store a hash of your selected password and when you enter it during login, it hashes the password and compares the hash to a stored hash. If they match, you've entered a correct password and you gain access. If you enter wrong password, hashes won't match and you won't be allowed to login. You can't decode a password from a hash so even if someone steals hashed passwords, they are of no use to them because you can't convert them back into a password. It's a one way thing (similar to how you can't reconstruct back a file from a MD5 or SHA-512 hash for example). I've simplified it here, but that's how it works in an essence. Storing passwords in plain text is literally the worst possible practice and someone like Facebook or their parent companies should be crucified for using such method. Hashed password is a fingerprint of your selected password, it's not actually your password. If it makes sense to you guys.

Link to post
Share on other sites
7 hours ago, vorticalbox said:

Not really using url queries is a nice way to add functionality to a get request, for example at work I have routes that will change what data you get back based on queries. E.g sending ?completed=true will 9nly return items marked as completed.

 

Using it to move sensitive is super irresponsible.

Well, exactly. 

Unless you explicitly want the user to see what he does, or for queries like you suggested, it is silly.

 

And, more importantly:

It has to be coded on purpose. That is the point here. This is nothing that is happening as a "glitch", by accident, like they try to make it sound. 

It happened because they wanted to do it that way, for whatever reason.

Link to post
Share on other sites
2 hours ago, RejZoR said:

You can't decode a password from a hash so even if someone steals hashed passwords, they are of no use to them because you can't convert them back into a password. It's a one way thing

Sorry, but that is definitely untrue.

If you know the used algorithm, you can easily reverse the PW.

Hell, you can brute force it even if you don't know the algorithm at all. MD5 hashes for example take milliseconds to brute force a bad PW and only minutes to brute force good PWs.

Once you get into the 15+ length with upper, lower, numbers and specials you can be "relatively" save, but I would not call it unreverseable. That is basically why MD5 hashes are a clear sign of needing a better educated security coder.

 

However, this would not allow a company to send you your PW. Not gonna claim that. No company would brute force their own server for that. 😉

But it can be done and is actually pretty easy. You can just google PW hash brute force and will find plenty of tools that just need the hashes entered and your GPU will start to heat up to 90+ degree a second later.

Link to post
Share on other sites

@Tech Enthusiast

You've skipped the part where I said I oversimplified the explanation. But in an essence, that's what password hashing is there for. I'm not gonna dive into salting of hashes and stuff because it's over the top for most people here...

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×