Hacker News Reader

Comment by masterleep | Hacker News Reader

If the Linode Manager database only stores the hash, how would they know the password?

How did you find out about the illicit login?

> If the Linode Manager database only stores the hash, how would they know the password?

Hashes can be turned back into plain text, it is just computationally expensive to do so. Hashing only slows down an attack (and or increases the cost), it doesn't not mitigate one. In particular if the hashes aren't salted then a rainbow table is an extremely effective way of breaking all of the hashes concurrently.

The main method of doing so: Generate the hash for every combination of typable characters up to a given length (e.g. MD5() A-Za-z0-9 & specials up to 8x characters).

This can be mitigated using a more computationally expensive hashing routine (or increasing the work factor on a less computationally expensive one) and salts.

But given enough time OR computing power, all hashes will be broken. AWS makes breaking hashes a lot cheaper as you can bid on spare capacity and perform the operations relatively cheaply.

This only works if the input password has low entropy. You would think that people using Linode are savvy enough to be using long, randomly generated passwords.

> This only works if the input password has low entropy.

If you're generating every single possible password up to e.g. 8 characters the password's quality doesn't matter, only the length does.

A good secure password hash should be generated with a salt to slow down the process, in addition to using strong (slow) KDF function like scrypt. State actor like NSA could have store all possible 8 character combination today in a massive storage facility. God knows. But the size of such rainbow table is only effective if there is no salt, as with salt the hash is now different despite the underlying password is the same, thus there will never be enough storage if salt is present.

But the most effective "rainbow table"-like table is a look-up table with the followings:

* leaked password in plaintext, associate with email and any ID (forum username??)

* hash all of those passwords without salt

* hashes (with salt) of known leaked passwords (you try pas$w0rd and found a match for some hash with salt) - this only works if your attack succeed.

If you do a quick count you won't be surprise most passwords are fairly short and simple. If two complex passwords appear to be very similar, you can assume with a good probability they are used by the same person. You can learn some private data from just looking at password (e.g. birthday, pet's name, door number, company they worked for, sport team they root for, which many turn out to be the crucial hint or actual answer to security questions.)

I have never opened or downloaded any leaked data and don't know if it legal for use at all, but the black market probably has over petabyte volume of such data available.

It would be very interesting to see the whole world attack couple hashes per day. Imagine you go to a website, it gives you some plaintext, and you run a couple quick scrypt with random salt, and return the response. Now with a billion online users, run this every day once, you may end up finding one successful match of "this password == this hash with this salt" once in a while. But hey, that's what botnet can do...and then bitcoin!

If we presume the attackers had access to the system handling authorization, then the attackers introducing code to ship passwords offsite as users log in isn't really a stretch of the imagination.

That's true and great point. Let's play devil. You can't really be sure if Google engineer is sloppy and logging username and password on entry and then the SRE reading the log sees everything. I am not sure if their build system has plugin to detect such big red flag. Stacktrace is another place with potential leak of credentials. All of these are reasons when someone claims software is open source and auditable but they run the service themselves, it's really important to note you can't audit the actual server. They can log your username and password behind the scene while the client side appears to be 100% the same as the one on the server side.

What you describe is not rare, can be done with cross-site scripting. How it happens depends on the injection method (perhaps SQL injection).

12 character random strings are an absolute minimum for a secure password, because brute forcing and tabling start to become impractical. Longer strings are even better.

I wouldn't consider an 8 char password secure, no matter what the entropy is.

Yes length matters. That's why pretty much all "randomly generated" passwords are long. Mine are 20 characters.

They don't need to know the password with db write access.

In fact, depending on how the sessions are managed the attacker might just need read access to log in without a password.

If they've been more compromised than something like a simple SQL injection vulnerability, it could be something like added code to log passwords or post them off somewhere else.

If the Linode Manager database only stores the hash, how would they know the password?

Weak password? Weak hashing algorithm?

Reply on news.ycombinator.com