Опасно хранить хешированный пароль и метод, используемый для его хеширования?

Question

Я занимаюсь разработкой клиентского приложения на C #, которое будет взаимодействовать с сервером (страница php) для получения учетных данных и некоторых важных служб.Мне интересно, опасно ли хранить надежно хешированный пароль на компьютере клиента?Под «хорошим хэшированием» я подразумеваю случайное начальное число, использующее хорошо известную функцию безопасного хэширования.Для целей этого обсуждения предположим, что источник является свободно доступным (поскольку все двоичные файлы могут быть подвергнуты обратному проектированию).

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

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

Пример того, как хакер подделает чужой логинучетные данные, используя мою текущую логику:

1. Пользователь Legit впервые входит в систему, учетные данные сохраняются
2. Хакер получает доступ к файловой системе, находит имя пользователя и хешированный пароль
3. Хакер изменяет исходный код (или использует внедрение кода) для отправки полученного имени пользователя и хешированного пароля вместо того, что обычно делает программа

Продукт, который я создаю, не будет следующим ebay, facebook, или stackexchange, и имеет низкий бюджет.Мне не нужно что-то на высшем уровне, и я не забочусь о кражах, так как планирую использовать модель «Плати, что хочешь».Я в основном публикую это ради любопытства.

Answer 1

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

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

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

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

http://msdn.microsoft.com/en-us/library/ms995355.aspx

Но лучше вообще не хранить эквивалент пароля.

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

Чтобы решить эту проблему, сервер отправляет клиенту случайное число. Номер больше никогда не будет использоваться; это единовременно. Клиент кеширует хешированный пароль со случайным числом, а затем шифрует результат с помощью открытого ключа сервера. Зашифрованное сообщение xor'd отправляется на сервер.

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

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

Как я уже сказал, это тяжелые вещи. Не пытайтесь сделать это самостоятельно. Получить профессионала.

Answer 2

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

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

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

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

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

Answer 3

Я второй все выше, не пытаясь разобраться с системой безопасности. На мой взгляд, лучшая политика - просто сказать «нет» подобным вещам.

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

http://code.google.com/apis/accounts/docs/OpenID.html

http://wiki.openid.net/w/page/12995176/Libraries

Удачи.

Answer 4

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

Однако все зависит от слова "надлежащий". Во-первых, хеш-функцию не нужно переворачивать, если пользователь выбирает неверный пароль. Взломать сначала попробуйте список распространенных паролей, отсортированных по популярности. Довольно большое пространство паролей (8 или 9 символов) может быть взломано, если алгоритм хеширования не использует какое-либо усиление ключа (тысячи итераций), чтобы сделать его вычислительно дорогим. Предварительно вычисленные словари являются жизнеспособными, если алгоритм хеширования не использует соль.

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

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

Answer 5

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

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

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

3. Никогда не передавайте учетные данные в виде простого текста. Даже если переданные учетные данные хэшированы, если трафик захвачен, возможна атака воспроизведения. Протокол SSL не очень сложен в реализации, и он даст вам дополнительный бонус за то, что клиент сможет проверить, что он общается с нужным сервером, что помогает защитить от атак «человек посередине».

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

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

Answer 6

Это рай для хакеров!

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

:)