Замена обычного текстового пароля для приложения

Question

В настоящее время мы храним пароли в виде простого текста для имеющегося у нас веб-приложения.

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

Есть ли доля правды в этом аргументе?

Answer 1

Абсолютно никакой.Но это не имеет значения.Я уже публиковал аналогичный ответ:

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

Answer 2

От Википедия

Некоторые компьютерные системы хранят пароли пользователей, против которых можно сравнить попытки пользователя, как ClareText.Если злоумышленник получает доступ к такому внутреннему хранилище паролей, все пароли и все учетные записи пользователей будут скомпрометированы.Если некоторые пользователи используют один и тот же пароль для учетных записей в разных системах, они также будут скомпрометированы.

Более безопасные системы хранят каждый пароль в криптографически защищенной форме, поэтому доступ к фактическому паролю будет все равно трудным для Snooper, который получает внутренний доступ к системе, в то время как проверка попыток доступа пользователя остается возможной.

Общий подход хранит только «хешированную» форму пароля с открытым текстом.Когда пользователь вводит пароль в такой системе, программное обеспечение для обработки паролей проходит через алгоритм криптографического хэша, и если значение хэш, сгенерированное из записи пользователя, соответствует хэш, хранящемуся в базе данных пароля, пользователю разрешается доступ.Значение хэша создается путем применения криптографической хеш -функции к строке, состоящей из отправленного пароля, и, как правило, другого значения, известного как соль.Соль не позволяет злоумышленникам составить список хэш -значений для общих паролей.MD5 и SHA1 часто используются криптографические хеш -функции.

На этой странице вы можете прочитать гораздо больше по этой теме.По моему мнению, и во всем, что я читал и с чем работал, хеширование — лучший сценарий, если вы не используете очень маленький (<256 бит) алгоритм.

Answer 3

Нет абсолютно никаких оправданий хранению простых текстовых паролей в веб-приложении.Используйте стандартный алгоритм хеширования (SHA-1, а не MD5!) со значением соли, чтобы радужные атаки были невозможны.

Answer 4

Я не понимаю, как другие ваши разработчики говорят: «Больше паролей могут соответствовать хешу».

Есть аргумент в пользу того, что «хеш-атака будет быстрее», но только если вы не добавляете пароли во время их хеширования.Обычно функции хеширования позволяют предоставить соль, что делает использование известной хэш-таблицы пустой тратой времени.

Лично я бы сказал «нет».Основываясь на вышесказанном, а также на том факте, что если вы каким-то образом получаете доступ к открытому тексту, соленое хешированное значение не имеет особой ценности для того, кто пытается проникнуть.Хеширование также дает преимущество: все пароли выглядят одинаковой длины.

т. е. если хеширование любой строки всегда приводит к хешу из 20 символов, то, если вам нужно просмотреть только хэш, вы не сможете определить, например, исходный пароль состоял из восьми символов или шестнадцати.

Answer 5

Я столкнулся с точно такой же проблемой на своем рабочем месте.Чтобы убедить его в том, что хеширование более безопасно, я написал SQL-инъекцию, которая возвращала список пользователей и паролей из общедоступного раздела нашего сайта.Это сразу же было обозначено как серьезная проблема безопасности :)

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

Answer 6

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

Другому разработчику следует перестать говорить о безопасности, если вы храните пароли в открытом виде, и начать читать о безопасности.

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

Так:Добавьте соль к своим паролям (добавив соль справа от пароля*) и используйте хороший алгоритм хеширования, например SHA-1 или предпочтительно SHA-256 или SHA-512.

ПС:Немного подробнее о хешах здесь.

*я немного не уверен, должна ли соль находиться в начале или в конце строки.Проблема в том, что если у вас есть коллизия (два входа с одним и тем же хэшем), добавление соли на «неправильную» сторону не изменит полученный хэш.В любом случае, с Rainbow Tables у вас не будет больших проблем, только с коллизиями

Answer 7

Есть старая поговорка о программистах, притворяющихся криптографами :)

У Джеффа Этвуда есть хороший пост на эту тему: Вероятно, вы неправильно храните пароли

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

Answer 8

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

Однако с практической точки зрения это плохой аргумент: хорошая хэш-функция (md5 или sha1 подойдет) может в значительной степени гарантировать, что для всех значимых строк, особенно коротких, не будет никаких коллизий.Даже если бы они были, совпадение двух паролей для одной учетной записи не является большой проблемой. Если кто-то может случайно угадать пароли достаточно быстро, чтобы они могли войти, у вас возникнут более серьезные проблемы.

Я бы сказал, что хранение паролей в виде обычного текста представляет гораздо больший риск для безопасности, чем коллизии хэшей при сопоставлении паролей.

Answer 9

Я не эксперт по безопасности, но у меня такое ощущение, что если бы простой текст был более безопасным, хеширование вообще не существовало бы.

Answer 10

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

Answer 11

Это зависит от того, от чего вы защищаетесь.Если злоумышленник разрушает вашу базу данных (или обманом заставляет ваше приложение отобразить базу данных), то пароли в виде открытого текста бесполезны.Существует множество атак, которые основаны на том, чтобы убедить приложение выдать свои личные данные: внедрение SQL, перехват сеанса и т. д.Зачастую лучше вообще не хранить данные, а хранить хешированную версию, чтобы злоумышленники не могли ее легко использовать.

Как предполагает ваш коллега, это можно тривиально обойти, запустив тот же алгоритм хэширования для словаря и используя радужные таблицы для извлечения информации.Обычное решение — использовать секретную соль плюс дополнительную информацию о пользователе, чтобы сделать хешированные результаты уникальными, например:

String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() +  user.getPassword);

Пока ваша соль является секретной или злоумышленник не знает точной даты создания записи пользователя, атака по словарю потерпит неудачу - даже в том случае, если он сможет извлечь поле пароля.

Answer 12

Нет ничего менее безопасного, чем хранение паролей в виде открытого текста.Если вы используете достойный алгоритм хеширования (хотя бы SHA-256, но даже SHA-1 лучше, чем ничего), то да, коллизии возможны, но это не имеет значения, потому что, зная хэш, невозможно* вычислить, что именно строки хэшируют его.Если вы хешируете имя пользователя С паролем, то эта возможность также исчезает.

* - технически не невозможно, но «вычислительно неосуществимо»

Если имя пользователя — «graeme», а пароль — «stackoverflow», создайте строку «graeme-stackoverflow-1234», где 1234 — случайное число, затем хешируйте ее и сохраните «хеш-выход1234" в базе данных.Когда дело доходит до проверки пароля, возьмите имя пользователя, предоставленный пароль и число в конце сохраненного значения (хеш имеет фиксированную длину, поэтому вы всегда можете это сделать), хешируйте их вместе и сравните с хешем. часть хранимой стоимости.

Answer 13

больше паролей могут соответствовать хешу, и атака по словарю/хэшу будет быстрее.

Да и нет.Используйте современный алгоритм хеширования, например вариант SHA, и этот аргумент станет очень и очень слабым.Стоит ли вам беспокоиться, если эта грубая атака займет всего 352 года вместо 467 лет?(Анекдотическая шутка.) Ценность, которую можно получить (отсутствие пароля, хранящегося в системе в виде обычного текста), намного превосходит беспокойство вашего коллеги.

Answer 14

Надеюсь, вы простите меня за подключение решения, которое я написал для этого, с использованием клиентского JavaScript для хеширования пароля перед его передачей: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html