Если я создаю логин для приложения со средним или низким уровнем безопасности (другими словами, это не банковское приложение или что-то еще), могу ли я подтвердить пароль, введенный пользователем, просто сказав что-то вроде:
if(enteredPassword == verifiedPassword)
SendToRestrictedArea();
else
DisplayPasswordUnknownMessage();
Кажется, легко быть эффективным, но я, конечно, не возражал бы, если бы это было все, что требовалось. Достаточно ли простой проверки на имя пользователя и пароль?
Обновление: конкретным проектом является веб-служба, проверка выполняется исключительно на стороне сервера и не является открытым исходным кодом. Меняется ли домен, как бы вы справились с этим?
security
passwords
validation
Морган Херлокер
источник
источник
Ответы:
Не без SSL
Это небезопасно, если пароль передается по сети в виде простого текста. Хеширование пароля на стороне сервера также небезопасно, если пароль передается по сети в виде простого текста.
Поскольку
<input type="password"/>
тег HTML отправляет свое содержимое в виде простого текста, это будет проблемой независимо от того, как вы храните пароль на сервере, если только ваш сайт не использует SSL для передачи пароля.(HTTP-аутентификация, при которой в браузере появляется диалоговое окно с запросом пароля, может быть или не быть простым текстом, в зависимости от того, какие общие механизмы аутентификации используются у сервера и браузера. Так что это может быть способом избежать этого без использования SSL).
Нет, если администраторы сайта подозревают
Теперь, предположим, что вы используете HTTPS для создания веб-сайта, это может быть безопасно, если вы доверяете своим администраторам сайта (которые могут читать простые текстовые пароли) и другим людям, имеющим доступ к компьютеру, вести себя должным образом. Теперь может быть очевидно, что они могут делать с вашим сайтом все, что захотят (так как они его администрируют), но если они смогут прочитать пароль, они также смогут использовать украденные пары логин / пароль на сайтах других людей.
Способ защиты паролей от администратора
Один безопасный способ хранения и проверки паролей заключается в следующем:
Для хэш-функции попробуйте использовать что-то сильное и то, что еще не имеет хороших радужных таблиц в дикой природе. Вы можете изменить длину соли, если необходимо, обойти радужные столы.
В зависимости от среды, в которой вы находитесь, изменчивости задержки в вашей сети и того, должны ли имена пользователей быть общедоступными, вам может потребоваться вычислить другой путь к коду,
hash('0000'+entered_password)
если пользователя не существует, чтобы не дать злоумышленникам определение того, какие имена пользователей являются действительными, на основе времени, которое требуется, определите, что пароль является неправильным.источник
http://
подключением ... это разочаровывает: /encrypt(entered_password, public_key)
выполняете вычисления на клиенте и отправляете этот результат на сервер, который выполняетdoes_password_match?(user, decrypt(encrypted_password, private_key))
?does_password_match(user, salt, decrypt(encrypted, key))
, с солью в зависимости от пользователя. Как я уже сказал, очевидной проблемой является отсутствие защиты человека посередине.Это говорит о том, что вы храните пароли в открытом тексте, что нельзя, даже в сценариях с низким уровнем безопасности.
Вы должны иметь:
Вы можете использовать простой хеш, как, например, MD5
источник
Я согласен с теми, кто предлагает хеширование, но есть и колесо, которое вы здесь изобретаете. В зависимости от платформы вы, вероятно, сможете найти инструмент управления ролями / пользователями, который безопасно и надежно охватывает все элементы управления пользователями, не требуя слишком большого вмешательства с вашей стороны.
источник
Безопасность - очень деликатный вопрос, особенно потому, что необходимо соблюдать баланс между неудобством для ваших пользователей и обеспечением безопасности их информации. Как правило, формула того, какой уровень безопасности вам нужен, зависит от важности данных. Короче говоря:
Распространенное заблуждение о людях, которые делают плохие вещи, - то, что они ищут Большинство из них стремится разрушить доверие . Вы всегда должны делать все возможное, чтобы защитить доверие своих пользователей. Частью этого является ваша должная осмотрительность, чтобы убедиться, что их личность в безопасности. Они могут меньше заботиться о данных, которые они хранят, но они заботятся о своей идентичности - даже при самом низком пороге безопасности.
Существует ряд недорогих (для реализации и воздействия на пользователя) вариантов. Одним из них является хеширование пароля как минимум. Любой сервис, который хранит что-то такое же чувствительное, как пароль, в виде простого текста, заслуживает того, чтобы его взломали.
Общие принципы защиты паролем
Поскольку вы будете использовать SSL для аутентификации, как минимум, вы хотите зашифровать все страницы, которые также относятся к учетной записи пользователя. Это позволяет максимально защитить личность пользователя.
Примечание об управлении паролями : пользователи будут время от времени забывать свой пароль. Самое худшее, что вы можете сделать, это отправить им пароль по электронной почте. Если вы реализуете принципы, изложенные выше, вы все равно не сможете этого сделать. Гораздо лучше предоставить способ сброса пароля, используя ссылку, отправленную на зарегистрированный адрес электронной почты. Эта ссылка для сброса будет иметь одноразовый код, чтобы гарантировать, что доступ к странице принадлежит им.
источник
Это нормально, если пароль не используется ни для чего другого. Все еще существует риск, что пользователь решит, что он может повторно использовать пароль, поэтому было бы еще лучше с:
Если это для вас или кого-то, кто знает, что пароль хранится в виде простого текста, то это нормально.
источник
if (hash (enteredPassword + salt) == hashOfValidSaltedPassword)
- и обратите внимание, что,+
вероятно, это конкатенация, а не дополнение. Это действительно препятствует использованию радужных таблиц, которые представляют собой таблицы хэшей вероятных паролей.Доступен ли исходный код? Даже если нет, я вполне уверен, что пароль может быть найден в машинных инструкциях, если бинарный файл доступен. Я бы рекомендовал сделать контрольную сумму и сравнить ее.
Никогда не забывайте о безопасности, даже если это не очень важно по вашему мнению.
источник
Точно нет. Прочитайте это , оно описывает, как хакеры взломали сайт безопасности. Вы планируете сделать вас самым слабым звеном в цепи.
источник
В нескольких ответах было отмечено, что вы должны хранить не сам пароль, а хеш - и вам следует использовать SSL.
Вы можете сказать, в чем дело? Если мое приложение будет взломано, это не будет проблемой. Ну, это довольно распространенный шаблон для пользователей повторно использовать один и тот же пароль на всех сайтах. Если бы хакер взломал ваш сайт и получил доступ к паролям пользователей, он мог бы выдать себя за многих из этих пользователей на других сайтах, более важных для этих пользователей. Так что взлом вашего сайта может стать первым шагом для хакера, чтобы получить доступ к банковской информации для пользователей.
И простого хеширования пароля недостаточно. Вы должны смешать это с солью. Хакеры имеют таблицы обратного просмотра хэша, поэтому для данного хэша они могут найти соответствующий пароль.
Если вы решите не реализовывать эту функцию, вы должны проинформировать пользователей об этом недостатке безопасности, поощряя их не использовать тот же пароль, который они используют в другом месте.
источник
Пока это на стороне сервера .. Тогда да.
Если вы хотите немного больше безопасности, зайдите на https и зашифруйте \ хэшируйте пароль в БД.
источник