3 ms·
He said he was using SHA1 which to me is not an implication. Is SHA1(k.nonce,password) not a form of SHA1? All you had to do was say, with the information ava
by makulit 17y ago
He said he was using SHA1 which to me is not an implication. Is SHA1(k.nonce,password) not a form of SHA1? All you had to do was say, with the information available, you would not have been able to determine the password.
On a different note, why aren't more webapps tracking login attempts? Is this too difficult to implement based on simple but sane "timeout" rules?
Also, if an attacker does have access to the db through an injection and is able to dump/download the db what is really stopping the attacker from using a multitude of cheap machines? I'm just a small shop and I turn up 19 or 20(half cab)u dual density servers(16 cores/u) every few months. So I'm looking at 320 cores that a 32 million record database distributed over is actually pretty small. Does any kind of encryption matter at that point? In this day, that kind of processing power is cheap.
- tptacek 17y agoIt takes 10 hours for two fast cores to attack one single password across 32MM BCrypt hashes with the default cost factor. What does 320 cores get you? 160 passwords in 10 hours, or 0.06% of /usr/share/dict/words. No, you cannot simply scale your way to a BCrypt cracker using cloud servers. When you start worrying about attackers who will lease massive numbers of servers to crack your passwords, you dial up the cost on your hashes. You can do that transparently with BCrypt, migrating users as they log in. Every tiny incremental increase to the cost of a single login you make creates drastic cost increases for your attackers. You are on the right side of the scaling problem, the attacker is on the wrong side, and you can play the game indefinitely.