В настоящее время мы храним простые текстовые пароли для веб-приложения, которое у нас есть.
Я продолжаю выступать за переход к хэшу пароля, но другой разработчик сказал, что это будет менее безопасно — больше паролей может соответствовать хешу, и атака по словарю/хэшу будет быстрее.
Есть ли правда в этом аргументе?
Абсолютно никаких. Но это не имеет значения. Я уже публиковал аналогичный ответ:
К сожалению, люди, даже программисты, слишком эмоциональны, чтобы их легко поколебать аргументами. Как только он вложится в свою позицию (а если вы пишете здесь, так оно и есть), вы вряд ли сможете убедить его одними фактами. Что вам нужно сделать, так это переложить бремя доказывания. Вам нужно заставить его искать данные, которые, как он надеется, убедят вас, и таким образом узнать правду. К сожалению, у него есть преимущество в статус-кво, так что вам предстоит трудная дорога.
Из Википедии
Некоторые компьютерные системы хранят пароли пользователей, с которыми можно сравнивать попытки входа пользователей в систему, в виде открытого текста. Если злоумышленник получит доступ к такому внутреннему хранилищу паролей, все пароли и, следовательно, все учетные записи пользователей будут скомпрометированы. Если некоторые пользователи используют один и тот же пароль для учетных записей в разных системах, они также будут скомпрометированы.
Более безопасные системы хранят каждый пароль в криптографически защищенной форме, поэтому доступ к фактическому паролю будет по-прежнему затруднен для злоумышленника, получившего внутренний доступ к системе, в то время как проверка попыток доступа пользователя остается возможной.
Обычный подход хранит только «хешированную» форму открытого текста пароля. Когда пользователь вводит пароль в такой системе, программное обеспечение для обработки паролей запускает алгоритм криптографического хеширования, и если значение хеш-функции, сгенерированное из ввода пользователя, совпадает с хэшем, хранящимся в базе данных паролей, пользователю разрешается доступ. Хэш-значение создается путем применения криптографической хеш-функции к строке, состоящей из отправленного пароля и, как правило, другого значения, известного как соль. Соль не позволяет злоумышленникам создавать список хеш-значений для общих паролей. MD5 и SHA1 — часто используемые криптографические хэш-функции.
На этой странице вы можете прочитать гораздо больше по этому вопросу. По моему мнению, и во всем, что я читал и с чем работал, хеширование — лучший сценарий, если только вы не используете очень маленький (‹ 256 бит) алгоритм.
Нет абсолютно никаких оправданий хранению простых текстовых паролей в веб-приложении. Используйте стандартный алгоритм хеширования (SHA-1, а не MD5!) со значением соли, чтобы радужные атаки были невозможны.
Я не понимаю, как ваши другие вещи разработчика «больше паролей могут соответствовать хэшу».
Есть аргумент в пользу того, что «хэш-атака будет быстрее», но только если вы не добавляете соли в пароли по мере их хеширования. Обычно хэш-функции позволяют вам предоставить соль, которая делает использование известной хэш-таблицы пустой тратой времени.
Лично я бы сказал "нет". Основываясь на вышеизложенном, а также на том факте, что если вы каким-то образом получаете доступ к открытому тексту, хэшированное значение с солью не имеет большого значения для того, кто пытается войти в систему. одинаковая длина.
т. е. если хеширование любой строки всегда приводит к 20-символьному хешу, то, если у вас есть только хеш для просмотра, вы не можете сказать, был ли первоначальный пароль восемью символами или, например, шестнадцатью.
Я столкнулся с точно такой же проблемой на своем рабочем месте. Что я сделал, чтобы убедить его, что хэширование более безопасно, так это написал SQL-инъекцию, которая возвращала список пользователей и паролей из публичного раздела нашего сайта. Это было сразу же эскалировано как серьезная проблема безопасности :)
Чтобы предотвратить атаки по словарю/хешированию, убедитесь, что хэш-токен уникален для каждого пользователя и статичен (хорошо работает имя пользователя/дата присоединения/userguid)
Если вы не посолите свой пароль, вы подозреваетесь в атаках Rainbow Table (предварительно скомпилированные словари, которые имеют действительные входные данные для данного хэша)
Другой разработчик должен перестать говорить о безопасности, если вы храните пароли в открытом виде, и начать читать о безопасности.
Возможны коллизии, но обычно это не большая проблема для приложений паролей (в основном они возникают в тех областях, где хэши используются как способ проверки целостности файлов).
Итак: посолите свои пароли (добавив соль справа от пароля*) и используйте хороший алгоритм хеширования, такой как SHA-1 или предпочтительно SHA-256 или SHA-512.
PS: Подробнее о хешах здесь.
* я немного не уверен, должна ли соль быть в начале или в конце строки. Проблема в том, что если у вас есть коллизии (два входа с одним и тем же хэшем), добавление соли на «неправильную» сторону не изменит результирующий хэш. В любом случае, с Rainbow Tables у вас не будет больших проблем, только с коллизиями
Есть старая поговорка о программистах, притворяющихся криптографами :)
У Джеффа Этвуда есть хороший пост на эту тему: Возможно, вы неправильно храните пароли
Чтобы ответить более подробно, я согласен со всем вышеизложенным, хэш облегчает теоретически получение пароля пользователя, поскольку несколько паролей соответствуют одному и тому же хешу. Тем не менее, это гораздо менее вероятно, чем кто-то получить доступ к вашей базе данных.
Есть правда в том, что если вы что-то хэшируете, да, будут коллизии, поэтому два разных пароля могут разблокировать одну и ту же учетную запись.
Однако с практической точки зрения это плохой аргумент — хорошая хэш-функция (md5 или sha1 подойдет) может в значительной степени гарантировать, что для всех осмысленных строк, особенно коротких, не будет коллизий. Даже если бы это было так, совпадение двух паролей для одной учетной записи не является большой проблемой. Если кто-то может случайным образом угадывать пароли достаточно быстро, чтобы он мог войти, у вас есть большие проблемы.
Я бы сказал, что хранение паролей в виде простого текста представляет гораздо больший риск для безопасности, чем коллизии хэшей при сопоставлении паролей.
Я не эксперт по безопасности, но мне кажется, что если бы простой текст был более безопасным, хеширования вообще бы не существовало.
Теоретически да. Пароли могут быть длиннее (больше информации), чем хеш, поэтому существует вероятность коллизии хэшей. Однако большинство атак основаны на словаре, и вероятность коллизий бесконечно меньше, чем успешное прямое сопоставление.
Это зависит от того, от чего ты защищаешься. Если злоумышленник вытаскивает вашу базу данных (или обманом заставляет ваше приложение отображать базу данных), то незашифрованные пароли бесполезны. Существует множество атак, которые полагаются на то, чтобы убедить приложение выдать свои личные данные — SQL-инъекция, перехват сеанса и т. д. Часто лучше вообще не хранить данные, а сохранить хешированную версию, чтобы злоумышленники не могли легко ее использовать. .
Как предполагает ваш коллега, это можно легко обойти, запустив тот же хеш-алгоритм со словарем и используя радужные таблицы для извлечения информации. Обычное решение состоит в том, чтобы использовать секретную соль плюс дополнительную информацию о пользователе, чтобы сделать хешированные результаты уникальными, например:
String hashedPass=CryptUtils.MD5("alsdl;ksahglhkjfsdkjhkjhkfsdlsdf" + user.getCreateDate().toString() + user.getPassword);
Пока ваша соль является секретной или ваш злоумышленник не знает точную дату создания записи пользователя, атака по словарю не удастся, даже если они смогут получить поле пароля.
Нет ничего менее безопасного, чем хранение паролей в виде простого текста. Если вы используете приличный алгоритм хеширования (хотя бы SHA-256, но даже SHA-1 лучше, чем ничего), то да, коллизии возможны, но это не имеет значения, потому что по хэшу невозможно* вычислить, что строки хэш к нему. Если вы хешируете имя пользователя с паролем, то эта возможность также исчезает.
* - технически не невозможно, но "вычислительно невозможно"
Если имя пользователя — «graeme», а пароль — «stackoverflow», создайте строку «graeme-stackoverflow-1234», где 1234 — случайное число, затем хешируйте ее и сохраните «hashoutput1234» в базу данных. Когда дело доходит до проверки пароля, возьмите имя пользователя, предоставленный пароль и число в конце сохраненного значения (хэш имеет фиксированную длину, поэтому вы всегда можете это сделать), хешируйте их вместе и сравните с хешем. часть сохраненного значения.
больше паролей может соответствовать хешу, и атака по словарю/хэшу будет быстрее.
Да и нет. Используйте современный алгоритм хеширования, такой как вариант SHA, и этот аргумент становится очень, очень слабым. Вам действительно нужно беспокоиться, если эта атака грубой силы займет всего 352 года вместо 467 лет? (Там анекдотическая шутка.) Ценность, которую можно получить (отсутствие хранения пароля в виде простого текста в системе), намного превосходит озабоченность вашего коллеги.
Надеюсь, вы простите меня за то, что я включил решение, которое я написал для этого, используя JavaScript на стороне клиента для хеширования пароля перед его передачей: http://blog.asgeirnilsen.com/2005/11/password-authentication-without.html
