search

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.29k stars 2.1k forks source link

Reject hashes in a helpful manner #3222

Open kholia opened 6 years ago

kholia commented 6 years ago

See https://github.com/magnumripper/JohnTheRipper/issues/3221 for details.

Example: If the ethereum-opencl format seems a valid ethereum hash with an unsupported KDF (e.g. scrypt KDF), it should reject such hashes with a helpful error message.

magnumripper commented 6 years ago

A related "issue" is that ethereum is one format (for all versions) on CPU and two different ones on GPU (even though same ethereum2john is used, right?). That's unintuitive and that was my first guess for #3221 before I read his output.

magnumripper commented 6 years ago

A related "issue" is that ethereum is one format (for all versions) on CPU and two different ones on GPU

BTW just to be clear I'm not quite sure what's the best fix. We could join the OpenCL formats into one. That's easier for the user. Or we could have similar warnings/help messages refering to the "other" format. I think I'd vote for joining them into a single format (with -cost support) - simply because the CPU format is like that.

solardiz commented 6 years ago

When we join technically very different things (different KDFs, etc.) into the same format, we lose separate benchmark output in simple --test (even if such output can still be obtained by requesting the right KDF, etc. through --costs). This complicates detection of performance regressions e.g. between JtR versions with mass relbench.

Maybe we should enhance the benchmarks to run over all tunable costs whenever a cost indicates different underlying logic (we'd need a way to mark such magic costs in some way) or split any such joint formats (but perhaps we've already got too many of those to do that now, and it'd be worse for the users).

magnumripper commented 6 years ago

perhaps we've already got too many of those to do that now, and it'd be worse for the users

We have a good number of them, so splitting the existing ones is probably not an alternative (it also isn't very user friendly to require the user to know the difference between GPG this and GPG that). As for your other idea, that could definitely make sense.

Actually from a user perspective we probably shouldn't even have things like oldoffice and office or Oracle this/Oracle that. They may be totally different beasts to us but not to the user. Hashcat is even worse though - it has no autodetection at all and even requires the user to know a mostly arbitrary format number (as in -m2500 for WPAPSK).

magnumripper commented 6 years ago

BTW zip2john is another case of one tool supplying two completely different (to us) formats - pkzip and zip.

madtomic commented 4 years ago

I am using the latest bleeding-jumbo branch.

I recently ran into issues with ethereum-opencl format as well.

I also get this error message when trying to use this format reported by other user. https://github.com/magnumripper/JohnTheRipper/issues/3221

Using default input encoding: UTF-8 No password hashes loaded (see FAQ)

The test works with ethereum-opencl but when try to use a GPU for cracking run john as,

$ ../run/john --format=ethereum-opencl hashes # for Ethereum wallets using PBKDF2

It don't seems to work.

I also followed all the steps here to generate the hash file. https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/doc/README.Ethereum

EDIT: Is the nVidia CUDA tool require for the OPENCL to work?

solardiz commented 4 years ago

@madtomic Are you posting this for user support (if so, john-users would be a more appropriate place) or to help the project (if so, this is the right place)? You could want to make the intent of your comment clearer either way ("I need help", "I offer help", "here's another vote for the same", "just saying", etc.)

For actual usage, please omit the "--format" option altogether. You'll re-add it later, after you get the basics working.

Yes, you do need the CUDA toolkit installed for OpenCL to work. You say "test works with ethereum-opencl", so presumably you mean something like "../run/john --format=ethereum-opencl --test" worked for you and made use of the GPU, correct? If so, you already have everything needed.

madtomic commented 4 years ago

@solardiz

I will use john-users for help. I found this when searching to see if anyone else have similar issue I am having with the format=ethereum-opencl.

The cracking basics are working when using "../run/john --format=ethereuml --test" and "../run/john --format=ethereum-opencl --test"

The hash file works when using CPU but when trying with GPU cracking mode. It does not and kept saying "No password hashes loaded"

I don't have the CUDA toolkit install but it appears I didn't need it since "../run/john --format=ethereum-opencl --test" is working fine like you suggested. I will try to install the CUDA toolkit and follow up later.

solardiz commented 4 years ago

@madtomic Thank you for this additional detail. Then it appears that your specific hash is not yet supported in our "ethereum-opencl", and we'll count your comment as another vote for us to brings the functionality of that format on par with its CPU counterpart. It doesn't sound like you need to install anything else on your system - this is just for us to improve. Thanks again.