Open jtojnar opened 1 month ago
As a temporary (but valid) solution, you can change the separator field. Edit digest and:
$ john --field-separator-char="|" --show=left digest.txt
using field sep char '|' (0x7c)
bob|$response$6629fae49393a05397450978507c4ef1$bob$atlanta.example.com$REGISTER$sips:ss2.biloxi.example.com$ea9c8e88df84f1cec4341ae6cbe5a359
0 password hashes cracked, 1 left
$ john --field-separator-char="|" digest.txt
using field sep char '|' (0x7c)
Using default input encoding: UTF-8
Loaded 1 password hash (hdaa, HTTP Digest access authentication [MD5 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=8
Note: Passwords longer than 10 [worst case UTF-8] to 32 [ASCII] rejected
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 16 candidates buffered for the current salt, minimum 24 needed for performance.
Warning: Only 6 candidates buffered for the current salt, minimum 24 needed for performance.
Almost done: Processing the remaining buffered candidate passwords, if any.
0g 0:00:00:00 DONE 1/3 (2024-07-17 08:46) 0g/s 19620p/s 19620c/s 19620C/s Bob1921..Bob1900
Proceeding with wordlist:/snap/john-the-ripper/current/bin/password.lst
Enabling duplicate candidate password suppressor
A suitable solution could be $HEX support in john
.
As a side note:
cat /proc/cpuinfo | grep -e 'flags*\|model*' | head -3
As a temporary (but valid) solution, you can change the separator field.
I'm not sure we'll have any better solution. We do use colon as field separator by default. Maybe we need to document this problem and solution more prominently, but where?
What other solution can we possibly implement? Here are some ideas, out of which I don't like any:
One idea is to somehow know there are only 2 fields, and if so only consider the first colon as the field separator. We could magically do this where the are too few colons for this to be a full /etc/passwd
or PWDUMP-style line. However, such heuristic would be fragile, as well as even more confusing (than the current behavior) when it fails (perhaps rarely).
Another idea is to have a command-line option to claim the number of fields, allowing for values 1 (bare hash) and 2. This would allow to keep the colons intact, but would it be any easier to learn of this problem/solution and use it than the current field separator option? I doubt it.
We could maybe base the loader's field count expectation on the hash type, but this mixes two abstraction layers into one, so it could also be unexpected and confusing. Also, it's tricky implementation-wise, in many ways.
A suitable solution could be $HEX support in
john
.
Ah, of course. But even then, where exactly in the documentation, program messages, etc. would we provide such advice, so that it reaches the right people when they bump into this problem?
Warning: Only 16 candidates buffered for the current salt, minimum 24 needed for performance. Warning: Only 6 candidates buffered for the current salt, minimum 24 needed for performance.
I wonder why this got printed twice.
Warning: Only 16 candidates buffered for the current salt, minimum 24 needed for performance. Warning: Only 6 candidates buffered for the current salt, minimum 24 needed for performance.
I wonder why this got printed twice.
Oh, nevermind, we do allow up to 10 of these by default.
As a temporary (but valid) solution, you can change the separator field
Thanks, this made it recognizable.
A suitable solution could be $HEX support in
john
.
I guess we could also add a heuristic like:
$
--field-separator-char
option.But maybe adding an FAQ answer like the following would be enough:
--field-separator-char
option.
- Do you have a new/updated computer?
I use a ~2014 Haswell laptop. Why?
Could you post the result of the command:
$ cat /proc/cpuinfo | grep -e 'flags*\|model*' | head -3
model : 69
model name : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d
I use a ~2014 Haswell laptop. Why?
I had doubts about the binary not offering maximum performance (which is bad for the user).
I had doubts about the binary not offering maximum performance (which is bad for the user).
Oh, good catch, I opened a downstream issue https://github.com/NixOS/nixpkgs/issues/328226
I tried to determine a password for
F1
from an example in https://www.rfc-editor.org/rfc/rfc3665#page-7:I was stuck on
john
not liking the legacy variant:(I later realized that the
Authorization
header itself is actually invalid but that is unrelated to this report.)Looks like it does not like the colon in the
uri
since when I delete it, I getUsing absolute URI is allowed by the specification:
It is also commonly used by Session Initiation Protocol, which does not even allow non-absolute URIs.
I modified the Nix package to point to 367d6438e6bd5cfd20f3290aac479ab4f1e5fea2: