Что если клиенту нужна возможность восстановить пароли?


34

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

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

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

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

Что мне делать? Во-первых, я не создавал систему паролей, поэтому я не могу быть обвинен, если что-то пойдет не так. С другой стороны, я не чувствую себя хорошо по этому поводу, и я также не хочу иметь доступ к 100 000 потенциальных входов электронной почты.


9
«что они сказали, они требуют». И они тоже лгут.
С.Лотт

10
Что бы вы ни делали, просто прикрывайте свою задницу.
Работа

6
Одним из ключевых аспектов безопасности является отказ от авторства. Т.е. пользователь не должен быть в состоянии сказать «это был не я» и верить. Если администратор может войти в систему как пользователь, это вызывает сомнения относительно источника какого- либо действия. По сути, если у вас есть учетная запись администратора, вы можете делать все, что вы хотите.
Берин Лорич

10
Строим новый PSN? ;-)
vartec

11
Так что заманчиво пометить этот вопрос с «Сони».
Джоэл Этертон

Ответы:


57

Реализуйте функциональность, в которой они нуждаются, безопасным способом. Администраторы могут войти в систему под другим пользователем, не зная пароля пользователя. Они могут войти в систему как они сами, а затем использовать некоторую функцию «change-identity».

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


6
+1 за второй абзац и «Не делать это - ошибка». Я бы хотел, чтобы каждый разработчик это понял.
Арсений Мурзенко

3
+1 за «Защита базы данных паролей - это не бизнес, а техническая задача». , Я считаю, что некоторые решения, такие как это, должны быть чисто техническими.
Мачадо

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

Я работал в сфере оборонных контрактов и могу заверить вас, что правительство гораздо строже относится к компаниям, которые хотят соблюдения SOX, чем к самим себе.
CorsiKa

16

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

Иногда бывают явные случаи, когда одна сторона ошибается, а другая права. Это как-раз тот случай.

Посмотрите, что только что произошло с Sony. Кроме того, наш сайт недавно был взломан, и одна из причин, по которой он не стал явной катастрофой, заключалась в том, что мы использовали (относительно) хорошую одностороннюю функцию хеширования (SHA512). С тех пор мы перешли на bcrypt, чтобы предотвратить даже атаки методом «грубой силы» / словаря (или, по крайней мере, сделать их несостоятельными). Я просто не нахожу ничего более добросовестного.


8

Факт: люди используют один и тот же пароль на многих сайтах

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

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

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

Как реализовать делегирование аккаунта

Делегирование аккаунта в вашей заявке должно быть сделано иначе.

  1. Администраторы должны войти в систему как сами, а затем
  2. либо (так как они привилегированные пользователи)
    • введите только UserName или
    • выберите определенного пользователя из списка, чтобы войти в него

Это определенно не должно быть сделано путем входа в систему с комбинацией UserName + Password .

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

Почему делегированный вход лучше?

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

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


5

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

Так что, если бы меня привели для проверки кода, и вы подняли это для меня, вот с чего мы начнем. Что ты защищаешь? Каковы негативные последствия того, что одному человеку удастся войти в систему как другому? Каковы негативные последствия раскрытия всех хранимых данных? Может быть, они ужасны. Вы бы перечислили их для меня. Тогда каковы последствия того, что люди не могут нажать «отправить мне пароль по электронной почте», а вместо этого нажать «сбросить мой пароль»? Перестанут ли они пользоваться сайтом? А как насчет персонала, входящего в систему как человек? Это экономит время, деньги, потерянные продажи или что?

Последняя часть истории о затратах и ​​выгодах, которую вы можете получить только в том случае, если существует действительно большая разница между негативами, с которыми вы сталкиваетесь сейчас, и негативами, которые вы получите при удалении функциональности, - это стоимость ее исправления. Потратил бы я миллион, чтобы избавить меня от риска разоблачения в тысячу долларов? Нет. А как же наоборот? Я полагаю, что это зависит от шансов, но мой первый ответ - да.

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


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

10
Неважно, что делает приложение. Самая важная часть данных - это их пароль. Большинство пользователей используют пароли в разных системах. Если бы у меня был пароль к заявке, скорее всего, это был бы пароль электронной почты и т. Д.
RoboShop

2
@Rob Z, @RoboShop, я бы хотел, чтобы вы ошиблись. Увы, я знаю, что нет. Это хороший аргумент, чтобы избежать использования паролей на сайтах, которые в них не нуждаются ... он просто поощряет повторное использование пароля, который может иметь смысл в других местах.
Кейт Грегори

@Rob Z: или, еще один пример, я вспоминаю, что читал, что после взлома базы данных Gawker были написаны боты, чтобы попробовать все комбинации имени пользователя и пароля в Twitter, а затем публиковать спам-твиты со всех взломанных учетных записей.
Carson63000

5

Это может быть противозаконно и может привести к судебному преследованию. Если они сохраняют какую-либо личную информацию о пользователе или система взаимодействует с другими системами в качестве пользователя, вам может потребоваться проверить, подпадает ли система под действие какого-либо из государственных или федеральных законов или законов о конфиденциальности. то есть. Сарбейнс / Оксли, Калифорния ООПА и др.

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

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

Вам также не нужен пароль пользователя для выполнения операций как они. Вы можете реализовать sudoподобную функцию.


5

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

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

Для моей предыдущей компании я продолжал бороться за возможность отправлять электронные письма для сброса пароля, чтобы обойти эту проблему. И я продолжал отвергаться. В конце концов, мне надоело перелопачивать корму против течения, поэтому я ушел. Это был также заостренный босс, который думал, что глупые вопросы, которые задают некоторые банковские сайты, считаются «двухфакторной аутентификацией». Спорить с ним было похоже на карикатуру на Дилберта (он был похож на ПХБ).

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

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

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

Последний федеральный веб-сайт, над которым я работал, собирал у конечных пользователей 1/4 миллиарда долларов США в год (из них было около 400 пользователей), поэтому регистрация должна была быть очень жесткой, и что только авторизованному конечному пользователю было разрешено трогать веб-страницы, на которых они сообщали материал, за который они платили акцизы.

Sony была одной из компаний с последним нарушением безопасности. Это была не просто сеть PS3, это была также их сеть MMORPG игр, общая численность которой превышает 25 000 000 имен, адресов, номеров кредитных карт, имен пользователей и паролей. Вы можете поверить, что я совсем не счастлив (я хочу свою вечную трещину!).


75 миллионов аккаунтов для PlayStation Network, 25 миллионов аккаунтов для Sony Online Entertainment. Я не уверен, что считаю, что в этой утечке было только 12 000 кредитных карт. wired.com/gamelife/2011/05/sony-online-entertainment-hack Никаких трещин до выходных. Может быть.
Tangurena

4

Я ссылаюсь на Кодекс этики разработки программного обеспечения в отношении подобных проблем. На мой взгляд, ваша первоочередная задача - не подрывать общественный интерес (не так, как возможность взлома пароля, как в этом примере, где компания модифицировала ноутбуки Dell, чтобы компания проката могла шпионить за их арендаторами без их ведома). После этого вы должны информировать вашего клиента о потенциальных рисках и позволить им принять это во внимание. Конечно, это минимальная базовая линия. Вы должны использовать свое собственное суждение о том, считаете ли вы, что это все еще больше, чем вы можете себе позволить.

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


4
И если это правительственный проект, может быть даже не законно, чтобы он был небезопасным.
Восстановите Монику

3

Вы можете распечатать список электронных писем и расшифрованный пароль и положить его на стол вашего босса с большим предупреждением на титульной странице: «Конфиденциально»

Сделайте шрифт крошечным, чтобы не тратить бумагу, хотя.

Вы также можете показать им, как bugzilla позволяет администраторам выдавать себя за людей без использования их пароля.


+1 за пример для босса. Можно было бы возразить, что было бы лучше поставить на стол только пароли боссов и их семьи / знакомых.
Мачадо

2

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

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

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

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

Если вы не хотите полностью доверять одному администратору, вы также можете управлять этим. Например, вы можете решить, что 5 человек будут иметь ключи администратора, и вы хотите, чтобы как минимум три из них согласились, прежде чем ключ можно будет восстановить. В этом случае, когда вы храните зашифрованный пароль для административных целей, вы сохраняете его несколько раз, по одному для каждого набора из трех из пяти администраторов (что не занимает много места, поскольку вы храните только несколько ключей , ~ 256 бит за штуку, а не несколько копий данных). Каждая из этих копий последовательно шифруется с помощью (хэшей) каждого из паролей этих трех администраторов.

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

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


2

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

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

  • Сохранить текущий хэш пароля
  • Замена на известное значение
  • (Поддельная аудиторская деятельность, например перевод средств на оффшорный счет)
  • Заменить оригинальный хэш пароля

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


+1 за контрольный журнал, очень важный для повседневной работы, а также (надеюсь, не ежедневных) бедствий. Люди редко относятся к безопасности или аудиту серьезно.
Дейв

2

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

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


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

@Renesis - стоимость безопасности возвращается, когда ваши системы не скомпрометированы или скомпрометированы, но ничего ценного не потеряно. Компания должна иметь мышление, ориентированное на безопасность, иначе это будет тяжелая битва.
rjzii

1
@Rob Z - Да, и я думаю, что вопрос заключается в том, как достичь этого мышления. Очевидно, что бизнес не верит, что существует риск (или стоимость, или и то, и другое).
Николь

1
@RoboShop Нет, если пароль можно восстановить, он небезопасен, и вы (или ваша компания) неосторожны из-за несоблюдения лучших отраслевых стандартов.
Рейн Хенрикс

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

1

Учитывая текущие события (утечка данных Epsilon и утечка данных Playstation Network), можно было бы надеяться, что проблемы будут очевидными.

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

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


1

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


1
Да, закрытые ключи должны быть на машинах администратора (за брандмауэром), или даже лучше, если они находятся на USB-ключах, которые есть только у администраторов и которые они лично используют. Но им нельзя позволять брать эти ключи домой, потому что они могут быть украдены.
Роберт Коритник

Может храниться в безопасном пароле, таком как KeePass. Таким образом, даже если компьютер скомпрометирован, он защищен паролем администратора (надеюсь, хорошим). Я бы сказал о зашифрованном USB-ключе в сейфе, но похоже, что они планируют использовать его часто ...
Восстановите Монику

0

Обычно причина, по которой администратор видит пароль пользователя, заключается в том, что в случае его утери он может предоставить его пользователю. Насколько я могу судить, Windows также не позволяет администратору видеть пароль - так зачем ваше приложение? Любая внутренняя библиотека шифрования обязательно будет взломана, потому что я уверен, что тот, кто ее написал, не работает для АНБ.


Конечно, вы предполагаете, что Вопроситель не работает для АНБ.
Кристофер Махан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.