2015-12-10 5 views
-1

Я алгоритм в noob и не очень умный. Но у меня есть вопрос в голове. Существует множество алгоритмов хэширования, которые могут быть в 10 раз более сложными, чем то, что я написал, но почти все они предсказуемы в наши дни. Недавно я прочитал, что писать собственную функцию хеширования - не очень хорошая идея. Но почему? Мне было интересно, как программа/программист может нарушить мою логику, которая (например) создает уникальный хеш для каждой строки с шагом 5+. Предположим, что кто-то успешно ввел SQL-запрос на моем сервере и получил все хеши. Как программа (например, hashcat) может помочь ему расшифровать эти хэши? В этом случае я вижу сильную сторону своего собственного алгоритма, о которой никто не знает, и хакер понятия не имеет, как это реализовано. С другой стороны, известные алгоритмы (например, sha-1) уже не являются непредсказуемыми. Имеются доступные веб-сайты, которые имеют высокую вероятность эффективного разрыва этих хэшей. Итак, мой простой вопрос: почему умные люди не рекомендуют использовать самонаписанные алгоритмы хеширования?Каковы недостатки использования моего собственного алгоритма хэширования вместо популярных?

+0

Возможный дубликат [Безопасный хэш и соль для паролей PHP] (http://stackoverflow.com/q/401656/1146608) и [Как безопасно хранить мои пароли] (http://stackoverflow.com/q/1581610/1146608). «С другой стороны, известные алгоритмы (например, sha-1) уже не являются непредсказуемыми». SHA-1 и SHA-2 [нарушены] (https://www.google.com/webhp?&ion=1&espv=2&ie=UTF-8#q=sha%20hash%20broken). Есть более эффективные алгоритмы хеширования. Короче говоря, [используйте bcrypt, PBKDF2 или scrypt] (http://security.blogoverflow.com/2013/09/about-secure-password-hashing/). –

+0

@PatrickM - Ссылаясь на передовую практику, кажется, не ответ на этот вопрос. Вопрос больше о причинах, почему не изобретать собственный алгоритм. Конечно, ссылки в любом случае полезны. – martinstoeckli

ответ

0

Безопасность от неизвестности может быть преимуществом, но вы никогда не должны полагаться на нее. Вы полагаетесь на то, что ваш код остается в секрете, как только он станет известен (общий хостинг, резервные копии, источник-контроль, ...), сохраненные пароли теперь более безопасны.

Изобретение нового безопасного алгоритма чрезвычайно сложно, даже для криптографов. Есть много моментов, которые следует учитывать как правильные соления или key-stretching, убедившись, что подобный вывод не позволяет сделать выводы о подобии ввода и т. Д. ... Только алгоритмы, выдерживающие годы атак другими криптографы считаются безопасными.

Существует лучшая альтернатива придумыванию вашей собственной схемы. При разработке алгоритма вы фактически добавляете секрет хэширования (ваш код), только с учетом этого кода злоумышленник может начать грубый ввод паролей. Лучший способ добавить секрет:

  1. Хешируйте пароли с помощью известного проверенного алгоритма (BCrypt, SCrypt, PBKDF2).
  2. Зашифровать полученный хэш секретным ключом на стороне сервера (двустороннее шифрование).

Таким образом, вы также можете добавить секретный ключ (серверный ключ). Только если злоумышленник имеет привилегии на сервере, он может знать ключ, в этом случае он также знает ваш алгоритм. Эта схема также позволяет обменивать ключ, когда необходимо, обмен хэш-алгоритмом будет намного сложнее.