Достаточно ли 'if password == XXXXXXX' для минимальной безопасности?

20

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

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Кажется, легко быть эффективным, но я, конечно, не возражал бы, если бы это было все, что требовалось. Достаточно ли простой проверки на имя пользователя и пароль?

Обновление: конкретным проектом является веб-служба, проверка выполняется исключительно на стороне сервера и не является открытым исходным кодом. Меняется ли домен, как бы вы справились с этим?

Морган Херлокер
источник
3
это зависит от того, откуда взялся validPassword? если он жестко запрограммирован, вы не сможете настроить / изменить пароль без изменения кода. Если это происходит из файла конфигурации, он будет виден всем, кто обращается к нему.
Alb
1
"достаточно ли проверки комбо имени пользователя / пароля?"
Крис
3
@opinion: маловероятно, что это хуже, чем отсутствие логина. Пожалуйста, предоставьте некоторые основания для такого серьезного утверждения.
Морган Херлокер
1
Ваша терминология неверна, когда вы сравниваете пароль, вы проверяете его, а не проверяете его действительность. Пожалуйста, найдите время, чтобы понять разницу.
billy.bob
1
Это подразумевает хранение пароля в виде простого текста, что безответственно. Это также подразумевает предупреждение пользователя о неправильности пароля, что предоставляет потенциальному злоумышленнику слишком много информации. Вы всегда должны быть неоднозначными, то есть «Логин или пароль неверны».
Рейн Хенрикс

Ответы:

26

Не без SSL

Это небезопасно, если пароль передается по сети в виде простого текста. Хеширование пароля на стороне сервера также небезопасно, если пароль передается по сети в виде простого текста.

Поскольку <input type="password"/>тег HTML отправляет свое содержимое в виде простого текста, это будет проблемой независимо от того, как вы храните пароль на сервере, если только ваш сайт не использует SSL для передачи пароля.

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

Нет, если администраторы сайта подозревают

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

Способ защиты паролей от администратора

Один безопасный способ хранения и проверки паролей заключается в следующем:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

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

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

Кен Блум
источник
1
Полезные советы :) Что касается SSL, мы должны были разработать что-то, что работало бы в дикой природе , и просто использовали асимметричную криптографию для кодирования пароля (требуется Javascript), а затем декодировали его на сервере. Соль + хеш тогда происходит нормально. Кроме того, поскольку открытый ключ отправляется вместе с веб-страницей, он может меняться произвольно часто.
Матье М.
1
@Matthieu M .: Когда кто-то может подделать вашу веб-страницу, он также может изменить открытый ключ там, где он сам знает соответствующий закрытый ключ. Таким образом, ваша идея помогает только против пассивных атак чтения, а не против человека посередине.
Паŭло Эберманн
@ Пауло: да, я согласен, что SSL касается не только шифрования, но и сертификата, к сожалению, я не называю снимки здесь, и когда люди говорят, что хотят использовать веб-страницу с обычным http://подключением ... это разочаровывает: /
Матье М.
@Matthieu: Значит ли это, что вы отправляете public_key как часть публичной веб-страницы, encrypt(entered_password, public_key)выполняете вычисления на клиенте и отправляете этот результат на сервер, который выполняет does_password_match?(user, decrypt(encrypted_password, private_key))?
Кен Блум
@Ken: более или менее, вы получили право шифрования. Для сопоставления пароля это больше does_password_match(user, salt, decrypt(encrypted, key)), с солью в зависимости от пользователя. Как я уже сказал, очевидной проблемой является отсутствие защиты человека посередине.
Матье М.
52

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

Вы должны иметь:

if(hash(enteredPassword) == storedHash)

Вы можете использовать простой хеш, как, например, MD5

Vartec
источник
22
+1 за хеширование пароля. Но я бы хотя бы добавил немного соли. В противном случае, поскольку пользователи собираются повторно использовать имена пользователей и пароли между системами, нарушение вашего приложения с низким уровнем безопасности может позволить злоумышленнику взломать приложение с гораздо более высоким уровнем безопасности. Например, недавнему взлому HBGary удалось скомпрометировать систему CMS, на которой запущен их веб-сайт, и частично превратить ее в корневой доступ к своим серверам, поскольку система CMS с низким уровнем безопасности не добавляла соли в хэши arstechnica.com/tech-policy/ новости / 2011/02 /…
Джастин Кейв
1
Согласитесь ... рассмотрите следующее .. "strings JavaFile.class | grep -i password"
Билл
В чем проблема с паролем в открытом тексте, если они используются только один раз?
10
@Tim, потому что пользователи не будут использовать пароль только один раз. Исследования последовательно показывают, что пользователи повторно используют пароли несколько раз (например, theregister.co.uk/2011/02/10/password_re_use_study ) независимо от того, сколько раз им было сказано не делать этого.
Скотт
3
@Tim: кроме того, просто откройте свой exe, dll и т. Д. В текстовом редакторе, и вы, скорее всего, прямо там увидите свой пароль.
Гас Кавальканти
14

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

glenatron
источник
Я только что обнаружил поставщиков членства в ASP.Net, но я смотрел на них, думая: «Сколько раз я потратил впустую свое время на реализацию чего-то подобного?»
Гленатрон
8

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

isSecuritySufficient = effortToBreak > rewardForBreaking

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

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

Общие принципы защиты паролем

  • Никогда не храните пароли в виде простого текста
  • Хеширование с использованием безопасной хеш-функции, такой как SHA-1 или даже SHA-512 (даже MD5 слишком легко найти подходящий хеш)
  • Используйте значение соли приложения. Соль - это случайные байты, которые либо добавляются к паролю, чтобы его было сложнее угадать. Соль должна генерироваться во время выполнения и использовать информацию о машине в качестве начального значения, а не храниться и ссылаться каким-либо образом.
  • Используйте специфическое для пользователя значение соли. Используйте это в сочетании с солью вашего приложения.
  • Зашифруйте все запросы аутентификации, которые идут по сети. Это означает использование SSL для веб-приложений.

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

Примечание об управлении паролями : пользователи будут время от времени забывать свой пароль. Самое худшее, что вы можете сделать, это отправить им пароль по электронной почте. Если вы реализуете принципы, изложенные выше, вы все равно не сможете этого сделать. Гораздо лучше предоставить способ сброса пароля, используя ссылку, отправленную на зарегистрированный адрес электронной почты. Эта ссылка для сброса будет иметь одноразовый код, чтобы гарантировать, что доступ к странице принадлежит им.

Берин Лорич
источник
1
Поначалу меня поразила идея приложения соль + пользовательская соль, но чем больше я об этом думаю, тем меньше я в этом убежден. Если бы вы использовали, скажем, 4 символа соли приложения и 4 соли пользователя, то разница между этим и 8 символами соли пользователя заключается только в том, что половина соли будет одинаковой для каждого пользователя. Казалось бы, было бы безопаснее просто увеличить размер пользовательской соли, чем использовать прикладную соль. Кроме того, если прикладная соль основана на аппаратном обеспечении, вы не можете обновить или сменить аппаратное обеспечение без аннулирования всех паролей.
Дэвид Конрад
Проблема в том, что пользовательская соль включена в строку базы данных с паролем пользователя. Если плохой человек знает, для чего нужна соль (и они знают), и они видят ее в базе данных, то они знают, как ее полностью взломать. Включение в приложение части, которая вычисляется (то же самое, что каждый раз, когда вы помните), а не хранится, это значительно усложняет взлом пользовательских таблиц. Конечно, вы можете пойти еще дальше и получить 1 чистую случайную соль и 1 расчетную соль, причем обе они зависят от пользователя.
Берин Лорич
Ах, я вижу, держи часть соли в базе данных. Это имеет смысл. Спасибо.
Дэвид Конрад
Я не вижу проблемы с хранением соли для каждого ряда, если она уникальна для каждого ряда. Вот хеш: "fd84235a55bbfeb1585a3dd069d48127989c9753058b51b6ba2056fd6c5a0a91" (SHA256), вот соль: "671254bdf7944f8fa88e6c9913b948ee". Думаешь, ты сможешь получить пароль? Там нет радужного стола для этой соли (даже если вам дают соль), вы застряли в грубой форме.
Брайан Бетчер
3

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

if(hash(enteredPassword) == hashOfValidPassword)

Если это для вас или кого-то, кто знает, что пароль хранится в виде простого текста, то это нормально.


источник
1
Как и в комментарии Джастина Кейва к ответу vartec, используйте соль, поэтому if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)- и обратите внимание, что, +вероятно, это конкатенация, а не дополнение. Это действительно препятствует использованию радужных таблиц, которые представляют собой таблицы хэшей вероятных паролей.
Дэвид Торнли
если все, что вы проверяете - это хеш, могут ли они просто проходить цикл возможных строк, пока не будет сгенерирован тот же хеш, что и хранимый хеш? В конце концов, есть много строк, которые могут соответствовать одному и тому же хешу.
Морган Херлокер
@Prof Plum: очень трудно найти коллизии, если алгоритм хеширования хорош. Это основа современной криптографии: они по сути являются односторонними функциями.
3

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

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

Анто
источник
2
Да, плохая идея, если это проект с открытым исходным кодом :)
-1 - Если вы думаете, что наличие источника имеет значение, вы ничего не знаете о безопасности.
Mattnz
1

Точно нет. Прочитайте это , оно описывает, как хакеры взломали сайт безопасности. Вы планируете сделать вас самым слабым звеном в цепи.

Дейв
источник
0

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

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

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

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

Пит
источник
-2

Пока это на стороне сервера .. Тогда да.

Если вы хотите немного больше безопасности, зайдите на https и зашифруйте \ хэшируйте пароль в БД.

Идиоты
источник
3
Зачем считать, что это веб-приложение?
Крис
Хорошая точка зрения! Я только что сделал.
дебилы
4
-1, даже если это серверная сторона, это все еще не нормально.
до