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

Question

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

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

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

Answer 1

Абсолютно нет. Но это не важно. Я отправил подобный ответ раньше:

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

Answer 2

С Википедия

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

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

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

Существует гораздо больше того, что вы можете прочитать по этой теме на этой странице. На мой взгляд, и во всем, что я читал и с чем работал, хэширование - лучший сценарий, если вы не используете очень маленький (<256 бит) алгоритм. </p>

Answer 3

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

Answer 4

Существует старая поговорка о программистах, притворяющихся криптографами:)

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

PS: немного подробнее о хэшах здесь .

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

Answer 8

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

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

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

Answer 9

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

* - технически не невозможно, но "вычислительно невозможно"

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

Answer 10

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

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

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

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