plantbased

You're adorable candyjapan. I want to bounce you on my knee. When you eventually run a biz that doesn't just generate millions in revenue but is massively profitable, give me a shout and let me know if you still feel this way.

Imagine you have a biz that prints money. You literally have dump trucks that roll up to your gate every morning and unload, and amazingly you get to keep about half of it.

It's rare to create a business like that and if word gets out you'll have competitors swarming all over you driving down your margins until you're blowing every last cent trying to out market them and all that profitability will go away.

So you learn to STFU. Because people will steal your idea.

In the Valley among startups almost no-one is profitable and so it's all about sharing the love and lots of hugs because no one has anything to defend.

For the love of god give us all the TL;DR, the site is awful.

"I want to believe." ~Poster on Mulder's wall.

You can interpret "get's away with" as "makes better business sense". On a slight tangent - in the infosec space those with closed source products (e.g. WAF's) laugh at those with open source products when it comes to the numbers of embarrassing and business-damaging zero-days reported.

Closed source rocks if you're a capitalist. Those who sell closed source love that open sourcers are so distracted by singing-it from the mountain.

~From a guy who runs a not-that-small open source biz.

Hey don't diss xor. If the key is at least as long as the message and is used once, it's unbreakable.

Not true re GPU bandwidth/dictionaries. see cudahashcat - we're using it on a switched PCIe bus feeding dictionaries with plenty of bandwidth. You're not limited to mask attacks, which is what you're describing.

The whole idea of salts is to prevent rainbow table attacks i.e. you can't use precomputed hashes.

In this case you'd need to precompute an SHA256 of a dictionary of scrypt hashes which would have been computed from a dictionary of english words.

In practical terms, if you steal the DB and wanted to reverse passwords, you'd need to scrypt lets say 100 million words, then SHA256 them, then compare them to what's in the DB.

The original blog entry argues (or maybe it was the post on the same site that linked to) that we should use more compute intensive hashing algorithms, rather than relying on salts. scrypt is definitely more compute intensive.

So if you didn't use a salt and wanted to throw a 100M word dict at this, how long would that take on decent hardware to create the rainbow table of 100M words which could be used repeatedly against stolen dictionaries? On a decent GPU you can do around 1.2 billion SHA256 hashes per second. So the SHA256 step is trivial.

ASIC bitcoin hardware can do around 4.5 million scrypt hashes per second: https://bitcoinmagazine.com/13000/new-benchmark-scrypt-minin...

So you could create your rainbow table to attack the non-salted version of this in around 25 seconds.

A salted version of this same system would need the scrypt to be salted because SHA256 is so fast. If you just salted the SHA256 you'd be able to use a precomputed scrypt rainbow table and then you only have to compute the salted SHA256's which as you can tell from my benchmark above is very fast.

So clearly the salt is needed and you need to compute scrypt(salt + password) -->> send to server and then SHA256(scryptHash). Note that you don't need to add the salt on the SHA256 side because you've already defeated a rainbow table attack by your initial salting.

So how fast could you attack a salted system like this using GPU's for your SHA256 and ASICS for your scrypt based on the benchmarks above?

You can pretty much ignore the SHA256 step because it's so fast, so you'd get around 4.5 million guesses per second using ASICS doing scrypt.

Compared to 1.2 billion guesses using a GPU for SHA256, that's not too bad.

mrb, this is awesome, thanks for sharing. Can you comment on storing the scrypt as an md5 hash and how that would impact security? [Asking because I'm confined to server side systems that only support md5]

IMHO While MD5 has a fraction of the keyspace of SHA2, it's still a very hard problem to reverse it and intuitively it seems this might provide a huge improvement over salted and stretched (multiple rounds) of md5 on the server.

Thanks again.