61–70 of 141 posts
I'd never checked out Blind before. I just went there and checked out a few of the front page posts & comments. It has some of the most toxic and destructive "advice" I've seen for people asking for help or insight. I'm a bit astounded. Is this typical?
Earlier quoted context omitted.
It's pathetic, you see some of the most depraved, narcissistic members of the tech society there. The quality of the discourse you can guess is shockingly bad, and most people are from the Bay area. Is this an accurate representation of people in the Bay? Or is it just a platform for toxic folk to hang out?
I spent more time reading the threads than I should have, it's strangely addicting. I now feel naive for thinking that the people working at the big tech companies have a certain base level of "all-round" skills. In no way I expected so much cynicism, narcism and lack of empathy! Isn't this showing up in interviews? Or should it just be seen as online trolling and venting?
Reason enough not to work there if you ask me.
Earlier quoted context omitted.
> Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are managing data. We use more advanced methods like salted hash and SHA2 on securing users’ data in our database.” !!!!!!
Isn’t SHA2 the standard hashing algorithm? If not, what do people use now?
His lib is can be dropped in to any project (that doesn't have something similar built in already) https://github.com/iamcal/lib_bcrypt
Anyone writing code has no excuse for not using this, it's not rocket surgery.
> The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried.
That's not how hash functions work...
> Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are managing data. We use more advanced methods like salted hash and SHA2 on securing users’ data in our database.”
This sounds much more likely.
> (Logging in with an email address and unscrambled password would be unlawful, therefore we cannot verify this claim.)
So, they directly claim that weakly hashed passwords were available (and unscramble-able, apparently??), but they're unable to prove this and they're ignoring the company's reasonable explanation. Great reporting.
This bothers me: > The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried. That's not how hash functions work... > Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are…
This bothers me: > The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried. That's not how hash functions work... > Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are…
I forgot my password once, but I knew the general letters and it brute forced in a minute.
This bothers me: > The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried. That's not how hash functions work... > Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are…
Kind of. A hash function just provides a near random set of characters of fixed length for a given set of input in a way where the output characters are reproducible for the given input. Passwords are not stored. It is the computed hash value that is stored. When a user attempts to login with a username and password the password is hashed and compared to the stored hash.
That said you don't need the actual password to login. Any input that hashes to the same hash string is acceptable, which is called a hash collision. When they say cracking the hash this is likely what they mean, and its trivial to compute provided a rainbow table.
Salting provides an additional round of computation. For example let's say a user is trying to login. Their password is hashed but before the hashed are compared some additional information is added on the end of the computed hash and that new value is hashed. It is this new hash that is compared with the stored hash, which requires knowledge of the hash algorithm, the salt, and the hash value. You can generally guess the final hash algorithm in question by observing the character length of the stored hashes, but since there are two hash computations a different hash algorithm could be used for the first round of hashing.
To be secure the salt must be stored in a different location from the stored hashes and the salt value should not be statically visible in the source code provided a source code compromise. Statically expressed passwords are uploaded to code repositories all the time. Don't believe that you are protected from associated vulnerabilities merely because the code base isn't open source.
To the article's defense neither claim was verified, but both claims were reported. When the journalist cannot validate a claim themselves, or with experts, it is completely acceptable to report the claim and report the validation status.