Comment by riazrizvi | Hacker News Reader

Comment by riazrizvi | Hacker News Reader

Parent Full thread

Not sure if there is any merit to this article.

The author thinks passwords are not encrypted on Wattpad, because they ask you to change passwords on other sites where you have used the same password. The reason is more likely that Wattpad uses a common encryption algorithm. The hackers chance of gaining access to your other accounts using the same password is now much higher, especially if you use a relatively easy to guess string. Because using a fast computer they can run through common encryption algorithms with each guess of your password at their leisure... Once they have a match, they can login to your other sites.

Also hashing is nothing like encryption. To clarify hashing, is used to map very large data types to far smaller ones of just a few dozen (or few thousand) character strings, for the sake of speedy lookups. Hashing algorithms are not one way, you can determine the possible input values used to generate the hash. In the case of (relatively speaking) very small input data types like passwords, there is likely a 1:1 ratio of input password to hash, making it effectively a plain text password. So why would anyone use it? What evidence is there to suggest Wattpad would use an obviously ineffective method for encrypting passwords?

So the statement, "a password hash is a representation of your password that can't be reversed" and other statements about the security of hashing, is just incorrect - for passwords. I agree that hashing is statistically 1-way for large inputs like big strings or images, since then the possible inputs that match to a particular hash is very very large. It is not so for small ones, like passwords, where the data type is smaller/similar in size to the hash range.

You're confusing run-of-the-mill hash functions used e.g. for hash maps with cryptographic hash functions which have an entirely different purpose and therefore different characteristics (and conversely, using SHA256 to hash your dictionary keys would be totally overkill).

Cryptographic hash functions are one-way in the sense that (unless they are shown to be broken) it is not believed that there is a computationally tractable way of recovering the unhashed input from the hash. You can always brute force it, but even "just" for passwords, the input space is way too big for that, especially if you use a salt - unless you use a very common password, of course (even if limited to 26 letters and 8 characters that's over 200 billion different passwords).

So, most of your comment is just wrong, except for the part about how Wattpad stores passwords, which is just very likely wrong, since I can't prove it.

> (even if limited to 26 letters and 8 characters that's over 200 billion different passwords)

Of course, if you're using a fast cryptographic hash function then someone with a good GPU can throw a surprising amount of brute force at the problem. A Tesla M60, which is five years old, can do about 1.4 billion SHA-256 hashes per second; Amazon will rent you a server with one of these for $0.75/hour, and cracking a single 8-character lowercase alphabetic password should take about 2.5 minutes at most. Half that on average.

(Functions like bcrypt help with this by being designed for slowness, and newer ones like scrypt also try to use large amounts of memory with unpredictable access patterns so they're harder to accelerate with GPU/FPGA/ASIC hardware.)

This is all true, and this why we have bcrypt etc., but it was just an example for illustration.

In real-life situations, the input space is much larger still (if you account for longer passwords, case sensitivity, special characters etc.), as long as your passwords are truly unguessable. And at some point, even a very fast hashing algorithm won't be able to keep up. I don't know the exact calculations, but I would expect MD5 to still be hard to break for truly strong passwords (say, 20 random characters). The problem is more that people don't actually choose strong passwords most of the time.

> so why would anyone use it

Because once you salt it (use a different salt for each hash, which solved your collision issue) and purposely slow it down (through multiple rounds,etc) it effectively ruins precomputing the hashes because of how many permutations there are.

Of course this depends on which hashing algorithm you use. Md5? You can do millions a second. Bcrypt? You can make one hash take 100ms, that’s 10a second. They also use a random salt for each hash - so precomputed hashes will only work for that hash.

The issues you highlighted are very real for md5, but there’s a reason md5 is not recommended for passwords.

Reply on news.ycombinator.com