Hey. I have this big bcrypt project and i have not been able to crack even one hash!
I used both hashcat and hashsuite and no luck with any of them, full load and nothing else.
i tried running hashcat on cpu and still it didn't even solve one hash after a while.
i've seen people crack millions of bcrypts and I have not found anything about how to make this processor faster.
please help.
hashcat64 -a 0 -m 3200 hashes.txt rockyou.txt -w 3 -O
hashcat64 -a 0 -m 3200 hashes.txt rockyou.txt -w 3 -O -d 1
it's very difficult / dangerous to make comparison like this. What are you comparing to? dozens of hashes against 1 hash, cost factor 5 (2^5 = 32) against cost factor 19 (2^19 = 524288 "iterations").
Since it's parameterized with a flexible cost factor settings, you can't really make fair comparisons: apple to oranges.
bcrypt is a very hard to crack hashing type, because of the design of this slow hash type that makes it memory hard and GPU-unfriendly (especially with high cost factors).
In cases like this I would really suggest to take a step back, try to understand what the cost factor of your hashes is, try to crack a simple generated test and see how long you take to crack 1 single test with similar cost factor for which you have the password etc.
I don't think in these types of situations it's very common that there is something "wrong"... it's most of the time just a misunderstanding or missing knowledge about the details of the hashing algorithms and how the parameters (cost factor) and algo work etc
(06-29-2020, 08:17 AM)lightning Wrote: [ -> ]hashcat64 -a 0 -m 3200 hashes.txt rockyou.txt -w 3 -O
hashcat64 -a 0 -m 3200 hashes.txt rockyou.txt -w 3 -O -d 1
-a 0 is optional here
-w 3 can be changed for -w 4 (good for headless, do not do something else while cracking)
-d 1 : why? I would suggest to use all CPUs and GPUs (if any)
And yes, bcrypt is very slow. A 2080 Ti can get around 28,640 H/s for one hash (iterations: 32). But if you have more than ~10 hashes the speed will drastically drop.
yeah, very very good explanation @Mem5. your post is perfect because it explains what I forgot to mention above...
From my experience from the last couple of months/years, is that some people confuse the lower-case parameter with the correct upper-case parameter -D 1 (that stands for --opencl-device-types).
That means you need to use -D 1 (or -D 1,2) to even allow the CPU to run (if you have both CPUs AND GPUs)... if you only have CPUs, hashcat automatically allows CPUs too.
This implies that -D 1,2 or (-D 1 for only CPU) is needed to whitelist the CPUs, but the lowercase parameter (dash + lower case d) is something completely different, i.e. --backend-devices. The lower-case d allows you to select the different devices that are allowed to run (already whitelisted with -D). It should be very obvious now what the difference is between --opencl-device-types (-D) and --backend-devices (the "wrong" in your case, dash + lower case d).
Again, I saw a lot of users that just think it's "dash d that I need to use", without even checking the --help output and understanding that the command line parameter they use does something completely different.
That means, that instead of the dash+lowercase you currently use, you might want to test with and use:
or
instead.