|
2.8, Аноним (-), 10:43, 11/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> mpich (вместо openmpi) был выбран просто так или есть причины?
Авторы патчей для John the Ripper рекомендуют использовать mpich: "This has currently been tested on Linux/AMD64, MacOSX/Intel and Linux/x86 using mpich2-1.0.2"
Для OpenMPI вылязят мелкие глюки: "If you use OpenMPI instead of mpich2, the SIGHUP signal doesn't get passed to john. It is necessary to send a SIGUSR1 instead."
| |
|
|
|
3.19, solardiz (ok), 01:41, 24/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> JtR не умеет SHA-512.
Начиная с 1.7.6 (вышла прошлым летом), в JtR есть поддержка "generic crypt(3)", благодаря которой SHA-crypt хеши поддерживаются при условии их поддержки системой - т.е. на Linux с glibc 2.7 или новее, а также на свежих версиях Solaris. И на Linux и на Solaris реализована также OpenMP-параллелизация этого режима (включается раскомментариванием строчки в Makefile), благодаря crypt_r(3) на glibc и thread-safe crypt(3C) на Solaris. Автораспознавание хешей этого типа работает (т.е., например, просто "john /etc/shadow" без всяких опций сработает как надо, хотя лучше сначала применить "unshadow", чтобы использовать информацию из полей GECOS и имена домашних каталогов).
| |
|
|
|
2.20, solardiz (ok), 02:10, 24/03/2011 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> В JtR есть такая константа PLAINTEXT_LENGTH. Для MD5, например, она равна 15.
> Сделайте ваш пароль длиной больше 15 символов и хоть на кластере
> его ломай хоть на суперкомпьютере - JtR его ни в жисть
> не возьмет. А произвольно увеличить PLAINTEXT_LENGTH и перекомпилить нельзя :(
Да, для MD5-based crypt(3) действительно есть ограничение в 15 символов, которое связано с оптимизацией алгоритма под типичный случай (для выявления слабых паролей, длины до 15 актуальнее, чем бОльшие). Число 15 выбрано не случайно: начиная с 16-ти потребовался бы другой алгоритм, более медленный.
Тем не менее, это ограничение можно обойти воспользовавшись поддержкой "generic crypt(3)", опция "--format=crypt". Заодно там есть поддержка OpenMP. Правда, скорость проверки каждого пароля будет в несколько раз ниже (в расчете на одно ядро процессора), чем при специализированном коде.
Если уж выбирать сложный пароль, то следует уделить внимание не только длине. А длина может быть и меньше. Особенности поддержки конкретно в JtR не так важны, как сложность подбора в предположении наличия поддержки.
Спасибо за дельный комментарий!
| |
|
|