Как заверить пользователей, что сайт и пароли в безопасности [закрыто]

15

На надежных веб-сайтах я всегда вижу такие утверждения, как «Все данные зашифрованы» или «Все пароли зашифрованы с использованием 128-битного шифрования» и т. Д. Однако я никогда не сталкивался с такими утверждениями, как «Все пароли хешируются».

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

МОЙ ВОПРОС: Можно ли предоставить сообщение о том, что «все пароли зашифрованы и защищены», поскольку я не думаю, что обычный пользователь будет знать, в чем разница между хешированием и шифрованием, и, скорее всего, он будет чувствовать себя в безопасности только потому, что видит комфортное слово "шифрование"? Или я должен предоставить альтернативное сообщение?

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

security ethics encryption passwords hashing user2698818
источник
7
Лично я не слишком беспокоюсь об общении: напишите техническое описание того, что вы делаете, где-то глубоко в FAQ, где его найдут технические специалисты. Любому другому все равно все равно. Что еще более важно: убедитесь, что вы делаете правильные вещи (это сложно, если вы новичок, но, по крайней мере, вы пытаетесь!). Не создавайте свое собственное хеширование, используйте что-то вроде bcrypt .
Иоахим Зауэр
4
Что ж, правильная вещь состоит в том, чтобы объединить логин и не беспокоить пользователей еще одним именем пользователя и паролем.
Ян Худек
1
OpenID - это хорошо, но имя пользователя / пароль тоже хорошо. Я не думаю, что ваша проблема заключается в том, чтобы убедить пользователей в том, что ваш сайт защищен. Поскольку вы неопытны, это все равно что обещать то, чего у вас нет. Просто применяйте общие стандарты - вы не остановите профессиональных хакеров, но никто не может обвинить вас.
Hoàng Long
3
@coredump Действительно. Использование SHA-512 для хеширования паролей не очень хорошо. Это не хорошо".
Томас
3
Возможно, мне стоило бы задать любые последующие вопросы по информационной безопасности, чтобы убедиться, что вы получите самый лучший, актуальный совет. (Это не значит, что вы получаете плохой совет, просто мы не обязательно специалисты по безопасности).
ChrisF

Ответы:

22

  1. Пользователям все равно.

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

  2. Почти во всех случаях, когда я видел такие сообщения, они вводили в заблуждение. Самый веселый был на веб-сайте с ярлыками в стиле «военного уровня» на каждой странице. Было предупреждение о том, что сертификат HTTP недействителен. В форме входа произошла SQL-инъекция. Через несколько недель сайт был взломан, а затем исчез навсегда.

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

    Это как те ярлыки "W3C valid XHTML". Почему они обычно размещаются на сайтах, где даже домашняя страница содержит как минимум десятки ошибок и подобный код <DIV COLOR='red'>?

Если вы все еще хотите успокоить пользователей, вы можете добавить что-то вроде:

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

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

Подсказки из разных комментариев:

  • Не изобретайте велосипед: используйте OpenID. Таким образом, вы даже не храните хэши.

    Источник: комментарий Яна Худека .

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

    Источник: комментарий Яна Доггена .

Арсений Мурзенко
источник
Спасибо за вклад, ребята. Проблема в том, что я студент, который разрабатывает услугу для моего университета. Я не хочу, чтобы пользователи думали, что их пароли небезопасны, потому что их разработал какой-то ребенок в школе. Я рассмотрел множество различных методов, включая bcrypt, и я просто не решил, какой из них использовать. Я полагаю, что теперь это будет достаточно безопасно, и если многие люди начнут использовать его, я могу добавить его, если потребуется. Я просто сейчас работаю над тем, чтобы сделать это. Еще раз спасибо.
user2698818
3
@ user2698818 Что вы должны сделать, это спроектировать систему безопасности, а затем опубликовать вопрос, подробно описав его и спросив «достаточно ли это (достаточно)». Хорошая безопасность может быть полностью публичной.
Ян Догген
@ user2698818: хорошо. Отредактировал мой ответ.
Арсений Мурзенко
6
@JanDoggen: хорошо, он должен использовать существующую систему безопасности, которую кто-то другой спроектировал и спросил «достаточно ли она безопасна». Желательно, чтобы этот вопрос стоял довольно давно и привлек внимание нескольких экспертов в этой области ;-)
Иоахим Зауэр
12

Не храните пароли в первую очередь! Следуйте примеру Stack Exchange и позвольте пользователям входить в систему со своей идентификацией на другом сайте, который обеспечивает аутентификацию через OpenID . Реализации свободно доступны для большинства распространенных веб-фреймворков.

Или, возможно, любой другой протокол. Если это внутренний проект для какого-то учреждения (как следует из вашего комментария к другому ответу), то почти наверняка уже есть LDAP, Kerberos (Windows Active Directory также основана на этих двух; apache поддерживает HTTP-аутентификацию против них) или некоторые другие. такой сервис для входа в компьютер. Просто подключитесь к этому.

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

Ян Худек
источник
1
Скажите, пожалуйста, какие сайты вы создали, чтобы я мог их избежать, если вы рассматриваете разрешения как не важные для безопасности.
orlp
1
Что делать, если требуется хранить пароли. Также вопрос конкретно задается о хранении их.
Петр Кула
3
@ppumkin: Есть много вопросов типа «как мне использовать X, чтобы сделать Y», где лучший ответ «вы используете Z». Если вы не согласны, просто предоставьте лучший ответ ;-).
Ян Худек
3
@ppumkin Чтобы использовать аналогию: «Я пытаюсь разбить камень кулаком, какие перчатки мне следует использовать?» Проверьте, знают ли они о долотах, прежде чем предлагать 19-е немецкие кавалерийские рукавицы.
deworde
1
Я бы не стал слишком быстро предлагать OpenID. Да, это здорово, но, как правило, лучше всего работает, если вы поддерживаете несколько поставщиков OpenID / OAuth. Существует множество технических форумов, блогов, вопросов и ответов и т. Д., Где вы должны войти через OID-провайдера Facebook и не можете использовать другие. Я работаю в сети, которая блокирует домены Facebook оптом, поэтому я не могу работать с этими сайтами. Если вы собираетесь поддерживать OID и собираетесь использовать только один, выберите поставщика, который популярен среди вашей целевой аудитории и вряд ли будет заблокирован системным администратором. Google и Windows Live - хороший выбор.
KeithS
2

Высказывание:

«Это безопасно».

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

Значение: это утверждение может быть устаревшим, возможно, даже без вашего ведома.

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

stakx
источник
Нет, «Это безопасно» - это не «личное» или субъективное утверждение, это не похоже на «это красиво», для меня . Это на самом деле семантически пустой оператор, без указания «в отношении чего» или «защищен от каких атак» или «на каком уровне, в каком контексте». Если все ваше утверждение состоит из «это безопасно», оно устарело до того, как вы закончили вводить его, и весьма вероятно, что вы не знаете об этом. Я согласен, хотя в последней части речь идет о деталях.
AviD
@AviD: Возможно, вы слишком много читаете в моем конкретном выборе слов. Да, говорить, что что-то «безопасно», не раскрывая подробностей, бессмысленно. Но я по-прежнему убежден, что это также личное суждение, потому что не у всех одинаковое чувство и требования «безопасности»: то, что A считает достаточно безопасным, может чувствовать себя небезопасным для B. Поэтому, если сказать, что что-то «безопасно», предполагает, что человек, который делает заявление "находит это в безопасности". И это не такой веский аргумент, как предоставление кому-либо соответствующих фактов и предоставление им возможности сделать собственный вывод.
stakx
Правильно, «в отношении чего» я ​​имел в виду, для каких требований, профиля безопасности, рисков и т. Д. Все еще не личное суждение, но, возможно, то, что вы имели в виду под «личным», я имею в виду под «контекстом». «Безопасный» - это точная научная метрика, а не мягкое, неопрятное «чувство». Но да, как ты говоришь, не говори мне, что это "безопасно", скажи мне, что ты сделал, чтобы сделать это так.
AviD
@AviD: хорошо. Я не буду более подробно останавливаться на этом аргументе, за исключением того, что скажу, что безопасность - это тоже слабое чувство. Это, конечно, нечто большее, но когда вопрос касается «заверения» пользователей (см. Заголовок вопроса), то в конце концов значение имеет слабое желание.
stakx
1

Это действительно зависит от контекста вашего конкретного сайта.

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

Если это бизнес-приложение, то важен уровень безопасности всего сайта, а не только паролей. Кроме того, это зависит от того, кто является вашими целевыми пользователями - сугубо технический / не очень технический и т. Д.

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

Например, для нетехнических потребителей достаточно иметь несколько простых, простых комментариев, таких как:

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

(И, как уже говорили другие, вам лучше даже не имея паролей, используйте какой-то стандарт, такой как OpenId или OAuth.)

Для высокотехнологичных предприятий вы хотели бы иметь полную страницу технических и процедурных деталей, таких как:

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

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

Как упоминалось в одном из ответов, большинству пользователей все равно, они не поймут, что вы им скажете, и все равно все равно подпишутся, даже если вы скажете, что отправляете данные пользователя в АНБ.
Это не для них.
Они были бы так же счастливы, не имея никаких паролей, просто позвольте мне выбрать свое имя пользователя из списка и войти в систему автоматически.

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

алчный
источник
0

Если вы хотите, чтобы ваша система была защищена, сила алгоритма паролей не имеет смысла - большинство хакеров могут взломать пароли в кратчайшие сроки, особенно если выбранный пароль небольшой или состоит из общих слов, которые хакер уже "взломал и сохранил". "usiong радужные столы и аналогичные. Прочитайте статью ArsTechnica о взломе пароля для большей проницательности.

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

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

gbjbaanb
источник
0

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

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

CodeART
источник