В соответствии с комментарием, который я сделал по вопросу:
Один важный момент был упущен почти всеми ... Моя первоначальная реакция была очень похожа на @Michael Brooks, пока я не понял, как @stefanw, что проблема здесь нарушены требования, но это то, что они есть.
Но потом мне пришло в голову, что это может быть даже не так! Отсутствует здесь невысказанная ценность ресурсов приложения. Проще говоря, для недорогой системы полностью безопасный механизм аутентификации со всеми задействованными процессами был бы излишним и неправильным выбором безопасности.
Очевидно, что для банка "лучший практики »являются обязательными, и нет никакого способа этически нарушить CWE-257. Но легко представить себе системы с низкой стоимостью, в которых оно того не стоит (но все же требуется простой пароль).
Важно помнить, что истинный опыт в области безопасности заключается в поиске подходящих компромиссов, а НЕ в догматическом изложении "передовых методов", которые каждый может прочитать в Интернете.
В связи с этим я предлагаю другое решение:
В зависимости от стоимости системы и ТОЛЬКО ЕСЛИ система имеет достаточно низкую стоимость без «дорогих» активов (включая саму идентификацию), И существуют действующие бизнес-требования, которые делают надлежащий процесс невозможным (или достаточно сложным / дорогостоящим), И клиент осведомлен обо всех предостережениях ...
Затем было бы уместно просто разрешить обратимое шифрование без каких-либо специальных обручей, через которые можно было бы перескочить.
Я останавливаюсь, чтобы сказать не беспокоиться о шифровании вообще, потому что это очень просто / дешево в реализации (даже с учетом проходного ключа management), и он ДЕЙСТВИТЕЛЬНО обеспечивает НЕКОТОРОЙ защиты (больше, чем затраты на его реализацию). Кроме того, стоит посмотреть, как предоставить пользователю исходный пароль, будь то по электронной почте, с отображением на экране и т. Д.
Поскольку здесь предполагается, что ценность украденного пароля (даже в совокупности) довольно низка , любое из этих решений может быть верным.
Поскольку идет оживленное обсуждение, на самом деле НЕСКОЛЬКО оживленных дискуссий в разных сообщениях и отдельных ветках комментариев, я добавлю некоторые пояснения и отвечу на некоторые из очень хороших моментов, которые были подняты в другом месте здесь.
Для начала, я думаю, что всем здесь ясно, что разрешение восстановления исходного пароля пользователя - это плохая практика и, как правило, не лучшая идея. Это нисколько не оспаривается ...
Далее подчеркну, что во многих, а точнее, в БОЛЬШИНСТВЕ ситуаций - это действительно неправильно, даже грязный, противный И некрасивый.
Однако суть вопроса заключается в принципе: Есть ли ситуация, когда нет необходимости запрещать это, и если да, то как это сделать в наиболее правильный способ, соответствующий ситуации.
Как отметили @Thomas, @sfussenegger и некоторые другие, единственный правильный способ ответить на этот вопрос - это провести тщательный анализ риска любой заданной (или гипотетической) ситуации, чтобы понять, что поставлено на карту. , сколько стоит защищать и какие еще существуют меры по снижению рисков.
Нет, это НЕ модное слово, это один из основных и наиболее важных инструментов для настоящего профессионала в области безопасности. Лучшие практики хороши до определенного момента (обычно в качестве рекомендаций для неопытных и хакеров), после чего начинает действовать вдумчивый анализ рисков.
Знаете, это забавно - я всегда считал себя одним из фанатиков безопасности, и почему-то я нахожусь на противоположной стороне этих так называемых «экспертов по безопасности» ... Ну, правда в том, что я фанатик, и реальный эксперт по безопасности - я не верю в распространение догмы "передовой практики" (или CWE) БЕЗ этого важнейшего анализа рисков.
"Остерегайтесь фанатика безопасности, который быстро применять все, что есть в их поясе с инструментами, не зная, от какой реальной проблемы они защищаются. Повышение безопасности не обязательно означает хорошую безопасность ».
Анализ рисков и истинные фанатики безопасности указали бы на более разумное, ценность / компромисс на основе риска, основанный на риске, потенциальных убытках, возможных угрозах, дополнительных мерах по смягчению последствий и т.д. догмы и CWE, даже не понимая, как проводить анализ рисков, не имеют значения, • Взломщики системы безопасности и их опыт не стоят той туалетной бумаги, на которой они ее напечатали.
В самом деле, именно так мы получаем нелепость, которую представляет служба безопасности аэропорта.
Но прежде чем мы поговорим о соответствующих компромиссах в ЭТОЙ СИТУАЦИИ, давайте посмотрим на очевидные риски (очевидные, поскольку у нас нет всей исходной информации об этой ситуации, мы все предполагаем - поскольку вопрос в том, какие гипотетические ситуация может быть ...)
Давайте предположим, что система НИЗКАЯ ЦЕННОСТЬ, но не настолько тривиальная, чтобы иметь открытый доступ - владелец системы хочет предотвратить случайное олицетворение, но "высокая" безопасность не так важна, как простота использования . (Да, это законный компромисс - ПРИНИМАТЬ риск того, что любой опытный скрипач может взломать сайт ... Погодите, разве APT сейчас не в моде ...?)
Например, скажем, я ' m организовать простое место для сбора большой семьи, что позволит каждому провести мозговой штурм о том, куда мы хотим отправиться в поход в этом году. Меня меньше беспокоит какой-нибудь анонимный хакер или даже кузен Фред, выдавливающий повторяющиеся предложения вернуться к озеру Вантанаманабикилики, поскольку я беспокоюсь о том, что тетя Эрма не сможет войти в систему, когда ей это нужно. Итак, тетя Эрма, физик-ядерщик, не очень хорошо запоминает пароли и даже не умеет пользоваться компьютерами ... Так что я хочу устранить все возможные трения. Опять же, меня НЕ беспокоят взломы, я просто не хочу глупых ошибок неправильного входа в систему - я хочу знать, кто идет и чего они хотят.
В любом случае.
Итак, каковы наши основные риски, если мы будем шифровать пароли симметрично, а не использовать односторонний хэш?
- Выдает себя за пользователей? Нет, я уже пошел на этот риск, не интересно.
- Злой администратор? Ну, может быть ... Но опять же, меня не волнует, сможет ли кто-то выдать себя за другого пользователя, ВНУТРЕННЯЯ или нет ... и в любом случае злонамеренный администратор получит ваш пароль независимо от того, что - если ваш администратор ушел плохо, игра все равно окончена.
- Другой вопрос, который был поднят, заключается в том, что идентичность фактически используется несколькими системами. Ах! Это очень интересный риск, который требует более пристального внимания.
Позвольте мне начать с утверждения, что это не настоящая личность, которой мы делимся, а доказательство или учетные данные аутентификации. Хорошо, поскольку общий пароль фактически позволит мне войти в другую систему (скажем, мой банковский счет или Gmail), это фактически тот же идентификатор, так что это просто семантика ... За исключением того, что это не . В этом сценарии идентификация управляется отдельно каждой системой (хотя могут быть сторонние системы идентификации, такие как OAuth - все же, в этой системе она отделена от идентификационной информации - подробнее об этом позже).
Таким образом, ядро Здесь есть риск, связанный с тем, что пользователь добровольно вводит свой (один и тот же) пароль в несколько разных систем - и теперь я (администратор) или любой другой хакер моего сайта будет иметь доступ к паролям тети Эрмы для сайта ядерных ракет.
Хм.
Вам здесь что-то не нравится?
Должно.
Начнем с того факта, что защита ракетно-ядерной системы - это не моя ответственность, я просто строю место для прогулок семьи Фраккинов (для МОЕЙ семьи). Так чья это ответственность? Эмм ... А как насчет ракетно-ядерной системы? Да.
Во-вторых, если бы я хотел украсть чей-то пароль (кто-то, кто, как известно, неоднократно использует один и тот же пароль между безопасными и небезопасными сайтами) - зачем мне взламывать ваш сайт? Или боретесь с симметричным шифрованием? Гошдарниталл, я могу просто создать свой собственный простой веб-сайт, чтобы пользователи подписывались, чтобы получать ОЧЕНЬ ВАЖНЫЕ НОВОСТИ обо всем, что они хочу ... Паффо Престо, я «украл» их пароли.
Да, обучение пользователей всегда возвращает нас, чтобы укусить нас, не так ли?
И с этим ничего не поделать ... Даже если вы БЫЛИ хешировали их пароли на своем сайте и делали все остальное TSA может придумать, что вы добавили защиту их паролю НЕ ОДИН БЕЛЫЙ, если они собираются и дальше беспорядочно вставлять свои пароли на каждый сайт, на который они натыкаются. ДАЖЕ не пытайтесь.
Другими словами, их пароли не принадлежат вам, поэтому перестаньте вести себя так, как вы.
Итак, мои дорогие эксперты по безопасности, как старая женщина спрашивала Венди: «ГДЕ риск?»
Еще несколько моментов в ответ на некоторые вопросы, поднятые выше:
- CWE - это не закон, не постановление или даже не стандарт. Это набор общих недостатков, т. Е. Противоположность "передового опыта".
- Проблема общей идентичности - актуальная проблема, но ее неправильно понимают (или искажают) скептики. Это проблема совместного использования идентичности как таковой (!), А НЕ взлом паролей в малоэффективных системах. Если вы разделяете пароль между системой с низкой и высокой стоимостью, проблема уже существует!
- Кстати, предыдущий пункт на самом деле указывал бы ПРОТИВ использования OAuth и т.п. как для этих малоэффективных систем, так и для высокодоходных банковских систем.
- Я знаю, что это был всего лишь пример, но (к сожалению) системы ФБР на самом деле не самые надежные. Не совсем как серверы блога вашей кошки, но и не превосходят некоторые из более безопасных банков.
- Разделение знаний или двойной контроль ключей шифрования происходит НЕ только в вооруженных силах, на самом деле PCI-DSS теперь требует этого практически от всех продавцов, так что это уже не так далеко (ЕСЛИ значение оправдывает это).
- Всем тем, кто жалуется, что именно такие вопросы заставляют профессию разработчика выглядеть так плохо: именно такие ответы делают профессию безопасности еще хуже. Опять же, анализ рисков, ориентированный на бизнес, - это то, что необходимо, иначе вы станете бесполезным. Помимо того, что ошибаюсь.
- Думаю, именно поэтому не стоит брать обычного разработчика и возлагать на него больше ответственности за безопасность, не обучая мыслить по-другому и искать правильные компромиссы. Без обид, для тех из вас, кто здесь, я полностью за это, но нужно еще тренироваться.
Уф. Какой длинный пост ...
Но чтобы ответить на ваш первоначальный вопрос, @Shane:
- Объясните клиенту, как правильно поступать.
- Если он все еще настаивает, объясните еще, настаивайте, спорьте. Если нужно, устроите истерику.
- Объясните ему ДЕЛОВЫЙ РИСК. Детали хороши, цифры лучше, живая демонстрация обычно лучше.
- ЕСЛИ ОН ВСЕ ЕЩЕ настаивает и представляет веские бизнес-причины - пришло время высказать свое мнение:
Этот сайт имеет низкую или нулевую ценность? Действительно ли это обоснованный бизнес-пример? Вам этого достаточно? Есть ли какие-либо другие риски, которые могут перевесить веские бизнес-причины? (И, конечно, клиент НЕ является вредоносным сайтом, но это так).
Если это так, просто продолжайте. Не стоит прилагать усилия, трение и упущенное использование (в этой гипотетической ситуации), чтобы запустить необходимый процесс. Любое другое решение (опять же в этой ситуации) - плохой компромисс.
Итак, итоги и фактический ответ - зашифруйте его с помощью простого симметричного алгоритма, защитите ключ шифрования с помощью надежных списков ACL и, предпочтительно, DPAPI или тому подобного, задокументируйте его и попросите клиента (кого-то достаточно старшего, чтобы принять это решение) подписать Это.
person
AviD
schedule
23.02.2010
