Кресты / Говнокод #3872 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
std::string wbfunc(std::string& hash)
{
   std::string line;
   std::ifstream f("/home/hromjo/q");
   int l = 0;
   while (std::getline(f, line))
   {
      std::cout << "Перебор: " << l << "паролей." << "\n";
      l++;
      if (md5(line) == hash)
      {
        return line;
        break;
      }
   }
}

Возможно слегка не в тему.
Писал я и хочу проверить, говнокод ли это.
И что можно исправить в этом говнокоде.

Запостил: hromjo hromjo, (Updated )

Комментарии (21) RSS

  • pushkoff, это кусочек из моего md5-брутера. Теперь ищу в нем говнокоды, для оптимизации.
    Ответить
    • >>Теперь ищу в нем говнокоды, для оптимизации.
      это серъезно, или в шутку - не въехал
      суровый бруттер if (md5(line) == hash)), походу сильно заточен на md5.

      0_0 я видел статью одного чувака реально рубящего в теме.
      он писал что бруттеры пишут все кому не лень
      и как не странно 95% из них - говно - они даже не достигают скоростей, которых можно достичь написав проверку md5 самым тупым образом...

      и знаете почему? потому что их авторы выводят инфу о скорости на каждой итерации, что в несколько раз медленнее чем проверить один хеш.

      PS Use for(), Luke ))
      Ответить
      • > выводят инфу о скорости на каждой итерации, что в несколько раз медленнее
        Ахахаха!
        Ответить
    • std::string не лучший выбор для таких алгоритмов... я не думаю что пароли будут длиннее чем 128 символов (это с боооольшим запасом), поэтому char line[128] это твой выбор...
      словарь можно тоже организовать по правильному, записав в него пароли в виде блоков (допустим по 4кб) по несколько штук с выравниванием...
      Ответить
  • не хватает паяльника, так как с применением этого принципиально нового устройства возможно использование метода термо-ректального криптоанализа.

    Метод термо-ректального криптоанализа же, в свою очередь, помогает свести число итераций до минимума. В некоторых случаях число итераций и вовсе сводится к нулю, заканчиваясь на стадии инициализации.
    Ответить
  • Долго же он будет работать. Особо доставил аутпут на каждой строке.
    И интересно где md5 без salt используется для паролей? в phpbb?
    Ответить
  • Не страдал подобным, но разве нет в инете базы: пароль | хеш ? Из которой потом делать выборку SELECT pass FROM table WHERE hash='abrakozyabra.....', просто летать будет.
    Ответить
    • Даже с учётом коллизий, такая база будет весит охренеть сколько.
      Ответить
      • И? Имея md5-"дехешер", разве нельзя провести алгоритм в обратную сторону каким бы он не был, если он использует только md5-хеширование? Конечно же, вероятно, будет получен другой изначальный ключ, но главное, что он будет давать такой же результирующий хеш, что даст возможность пользоваться данным ключом в замен оригинального в том месте, где используется данный хеш.
        Ответить
        • Смотрите на псевдокод:
          salt = 42;
          key = md5(value, salt);


          Если Вы не знаете salt, то толку от дехешера мало.
          Ответить
          • Вполне очевидно было, что вы говорили постом ранее про salt, но он используется по разному в разных алгоритмах. Какой конкретно алогритм с применением salt вы предлагаете?

            И что такое "не знаете salt"? Опишите как при "неизвестном salt" идёт проверка пароля самим "движком". Я просто не занимаюсь такими работами, где надо вручную вводить использование md5-хеширования, поэтому возможно чего-то не понимаю.

            Но пока нет ответов на данные вопросы, давайте рассмотрим случай
            hash = md5 ( ( password + salt ) + salt )
            , где salt выбирается случайно и размещается рядом с MD5-хешем используя разделитель "$", допустим. Как получить пароль, дающий тот же md5-хеш? Просто "дехешировать" имеющейся хеш, выбрать тот (32+strlen(salt)) символьный "дехеш", у которого на конце имеется "salt", отрубить данный salt и снова "дехешировать", выбирая тот "дехеш", у которого salt на конце.
            Ответить
            • Проблема только в том, что база без учёта коллизий и с достаточной максимальной длинной хешируемого ключа будет весить чрезвычайно немало.
              Ответить
              • Оценочно по самому минимуму 2^40 октета.

                Да и если допустим при составлении данной базы одих хеш будет генерироваться в одну микросекунду, то составляться она будет больше 500 лет.
                Ответить
                • ну есть же распределенные вычисления. если привлечь тысячи компьютеров как это проделали SETI@Home или Folding@Home, то 500 лет сократятся до нескольких месяцев
                  Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8