В настоящее время я унаследовал приложение на работе и, к своему ужасу, понял, что пароли пользователей, хранящиеся в базе данных, зашифрованы с использованием внутренней функции шифрования, которая также включает в себя возможность дешифрования.
Поэтому все, что кому-то действительно нужно сделать, это скопировать таблицу пользователей и скопировать сборку шифрования (любой, у кого есть доступ к производственной базе данных), и тогда у них будет доступ к 100 000 адресов электронной почты и потенциальных паролей для них.
Я пытаюсь объяснить бизнесу, почему это не очень хорошая идея, но концепции безопасности, кажется, выходят за рамки их, поскольку они не настолько технически настроены (это для правительства). Кроме того, в приложении фактически существуют функциональные возможности для пользователей-администраторов, которые могут извлекать пароли пользователей, чтобы войти в них и выполнять какие-либо действия (что, как они сказали, они требуют).
Поэтому они не понимают последствий для безопасности. И чтобы реализовать более строгую политику безопасности (хеширование паролей, чтобы их было нелегко восстановить), я должен удалить для них существующую функциональность.
Что мне делать? Во-первых, я не создавал систему паролей, поэтому я не могу быть обвинен, если что-то пойдет не так. С другой стороны, я не чувствую себя хорошо по этому поводу, и я также не хочу иметь доступ к 100 000 потенциальных входов электронной почты.
источник
Ответы:
Реализуйте функциональность, в которой они нуждаются, безопасным способом. Администраторы могут войти в систему под другим пользователем, не зная пароля пользователя. Они могут войти в систему как они сами, а затем использовать некоторую функцию «change-identity».
Защита базы данных паролей - это не бизнес, а техническая проблема. Не делать это ошибка. Если бизнес думает о безопасности как о функциональном компромиссе, безопасность потеряет. Вы не должны давать им никаких оснований думать об этом таким образом.
источник
Вы должны убедить их, что они действительно не должны нести гражданскую ответственность в случае взлома их сервера. И при этом им не нужна обратная реакция от информированной пользовательской базы, которая понимает, что они небрежны.
Иногда бывают явные случаи, когда одна сторона ошибается, а другая права. Это как-раз тот случай.
Посмотрите, что только что произошло с Sony. Кроме того, наш сайт недавно был взломан, и одна из причин, по которой он не стал явной катастрофой, заключалась в том, что мы использовали (относительно) хорошую одностороннюю функцию хеширования (SHA512). С тех пор мы перешли на bcrypt, чтобы предотвратить даже атаки методом «грубой силы» / словаря (или, по крайней мере, сделать их несостоятельными). Я просто не нахожу ничего более добросовестного.
источник
Факт: люди используют один и тот же пароль на многих сайтах
Ваш начальник, вероятно, не осознает, что люди часто используют один пароль (или их очень ограниченный набор) для всех видов услуг (включая банковские услуги, Facebook и т. П.). Если пользователи могут изменить свой пароль в вашей системе, они, скорее всего, используют тот же пароль, что и в других местах.
Если ваш начальник считает, что доступ к паролю не является проблемой, вы должны сообщить им об этом, и, возможно, они начнут думать иначе. Даже если ваше приложение находится за стеной и не является общедоступным, оно может представлять угрозу безопасности для других онлайн-сервисов. Имена пользователей (особенно когда они электронные письма) довольно легко угадать. Я не могу представить, как смешно было бы войти в аккаунт босса в Facebook и поставить что-то на их стену.
Пароли пользователей всегда должны рассматриваться как конфиденциальная информация высшего уровня, к которой имеет доступ только ограниченное число людей. Лучше избегать хранения такой изменчивой информации. И даже когда вы это делаете, вам должен быть предоставлен каждый доступ к этой информации. Например, получение конфиденциальной бумаги из надежного сейфа, который можно открыть только несколькими ключами. Люди знают, кому и когда был предоставлен доступ.
Как реализовать делегирование аккаунта
Делегирование аккаунта в вашей заявке должно быть сделано иначе.
Это определенно не должно быть сделано путем входа в систему с комбинацией UserName + Password .
Это правда, что новый экран должен быть разработан для разрешения делегированного входа, но все же.
Почему делегированный вход лучше?
Вы также можете предоставить дополнительные функциональные возможности, которые позволят понять, что администратор выполнил какое-то действие от имени какого-либо пользователя (чего вы не можете знать сейчас, потому что администраторы действуют как боги и входят в систему как кто-либо и могут делать вещи, которые могут навредить реальная репутация работника).
Вы должны согласиться с тем, что люди делают ошибки. Админы тоже люди. И если они сделают ошибку от имени кого-то другого, они попытаются обвинить их. Я на 100% уверен в этом. Это сделает его более безопасным для пользователей, не являющихся администраторами, чтобы их реальная репутация не пострадала от ошибок других людей.
источник
Вы не упоминаете, что делает приложение. Если это паспортные приложения, полные информации о краже личных данных, которые должны быть защищены, это заслуживает максимальной защиты. Но если это «скажи мне о дорожно-транспортных происшествиях на моем пути домой», каковы последствия взлома пароля? Некоторые системы, которые я написал, даже не имеют паролей - вы просто вводите свой адрес электронной почты, номер вашего студента или какой-то другой идентификатор, который люди часто знают друг о друге, а владельцы системы ценят простоту использования и невозможность блокировки из-за возможного нарушения конфиденциальности, если люди подражают друг другу. У меня тоже нет проблем с этим. Зачем мне пароль, например, чтобы настроить расписание предпочитаемых сессий на конференции?
Так что, если бы меня привели для проверки кода, и вы подняли это для меня, вот с чего мы начнем. Что ты защищаешь? Каковы негативные последствия того, что одному человеку удастся войти в систему как другому? Каковы негативные последствия раскрытия всех хранимых данных? Может быть, они ужасны. Вы бы перечислили их для меня. Тогда каковы последствия того, что люди не могут нажать «отправить мне пароль по электронной почте», а вместо этого нажать «сбросить мой пароль»? Перестанут ли они пользоваться сайтом? А как насчет персонала, входящего в систему как человек? Это экономит время, деньги, потерянные продажи или что?
Последняя часть истории о затратах и выгодах, которую вы можете получить только в том случае, если существует действительно большая разница между негативами, с которыми вы сталкиваетесь сейчас, и негативами, которые вы получите при удалении функциональности, - это стоимость ее исправления. Потратил бы я миллион, чтобы избавить меня от риска разоблачения в тысячу долларов? Нет. А как же наоборот? Я полагаю, что это зависит от шансов, но мой первый ответ - да.
ps - канадское правительство начало работу с сайтом подачи заявления на получение паспорта, у которого были идентификаторы в URL: если вы редактировали URL с другим идентификатором, вы увидели наполовину заполненную форму какого-то другого случайного гражданина. И у меня есть клиенты, которые входят в качестве своих клиентов в целях обслуживания клиентов для общего счастья, поэтому я вижу в этом хорошую сторону, хотя я бы не стал этого поддерживать, если данные за паролем действительно важны для незнакомцев.
источник
Это может быть противозаконно и может привести к судебному преследованию. Если они сохраняют какую-либо личную информацию о пользователе или система взаимодействует с другими системами в качестве пользователя, вам может потребоваться проверить, подпадает ли система под действие какого-либо из государственных или федеральных законов или законов о конфиденциальности. то есть. Сарбейнс / Оксли, Калифорния ООПА и др.
Помимо потенциальных юридических проблем, вы также можете указать, что любой администратор может в любое время сбросить всю таблицу на переносную карту данных и оставить ее с возможностью входа в систему под именем любого пользователя и вызвать хаос или продать данные.
Даже если вы предполагаете, что все администраторы заслуживают доверия, это также делает компромисс с паролем администратора разрушительным.
Вам также не нужен пароль пользователя для выполнения операций как они. Вы можете реализовать
sudoподобную функцию.источник
Это не может быть системой федерального правительства, так как требования FIPS и FISMA запрещают обратимое шифрование паролей, а родительский отдел отправляет их на Луну.
Для моей предыдущей компании я продолжал бороться за возможность отправлять электронные письма для сброса пароля, чтобы обойти эту проблему. И я продолжал отвергаться. В конце концов, мне надоело перелопачивать корму против течения, поэтому я ушел. Это был также заостренный босс, который думал, что глупые вопросы, которые задают некоторые банковские сайты, считаются «двухфакторной аутентификацией». Спорить с ним было похоже на карикатуру на Дилберта (он был похож на ПХБ).
Я видел, как это реализовано в финансовом учреждении. Люди в зоне поддержки клиентов будут входить в систему со своими учетными данными, и, если у них есть на это права, они могут притворяться, что входят в систему как клиент. Это не вошло в систему как клиент, просто выдало себя за клиента . Таким образом, если представитель отдела обслуживания клиентов решит снять деньги, он не будет отображаться в журнале как клиент, делающий это: он покажет, как представитель отдела обслуживания клиентов пытается это сделать (а также отправит уведомление, чтобы их уволили, как только Рентакоп мог добраться до их пола).
Если сделать это плохо, то персонал службы поддержки сможет создать впечатление, что конечный пользователь занимается какой-либо деятельностью, которая может привести к серьезным финансовым или юридическим обязательствам.
Последний федеральный веб-сайт, над которым я работал, собирал у конечных пользователей 1/4 миллиарда долларов США в год (из них было около 400 пользователей), поэтому регистрация должна была быть очень жесткой, и что только авторизованному конечному пользователю было разрешено трогать веб-страницы, на которых они сообщали материал, за который они платили акцизы.
Sony была одной из компаний с последним нарушением безопасности. Это была не просто сеть PS3, это была также их сеть MMORPG игр, общая численность которой превышает 25 000 000 имен, адресов, номеров кредитных карт, имен пользователей и паролей. Вы можете поверить, что я совсем не счастлив (я хочу свою вечную трещину!).
источник
Я ссылаюсь на Кодекс этики разработки программного обеспечения в отношении подобных проблем. На мой взгляд, ваша первоочередная задача - не подрывать общественный интерес (не так, как возможность взлома пароля, как в этом примере, где компания модифицировала ноутбуки Dell, чтобы компания проката могла шпионить за их арендаторами без их ведома). После этого вы должны информировать вашего клиента о потенциальных рисках и позволить им принять это во внимание. Конечно, это минимальная базовая линия. Вы должны использовать свое собственное суждение о том, считаете ли вы, что это все еще больше, чем вы можете себе позволить.
Конечно, когда вы упоминаете правительственный проект, если личная информация граждан находится под угрозой из-за этой практики, то это подрывает общественный интерес.
источник
Вы можете распечатать список электронных писем и расшифрованный пароль и положить его на стол вашего босса с большим предупреждением на титульной странице: «Конфиденциально»
Сделайте шрифт крошечным, чтобы не тратить бумагу, хотя.
Вы также можете показать им, как bugzilla позволяет администраторам выдавать себя за людей без использования их пароля.
источник
Прежде всего, я согласен с другими ответами, указывающими на то, что гораздо безопаснее просто избежать этого и хранить только хэши паролей, а не сами пароли или что-либо, что может быть преобразовано обратно в пароль.
Однако бывают случаи, когда вам нужно более или менее разрешить восстановление. В случае паролей вы обычно хотите восстановить, просто позволяя администратору сменить пароль при необходимости, а не восстанавливать существующий пароль.
Другая возможность, однако, заключается в том, что вы позволяете пользователю хранить данные на сервере, который зашифрован их собственным паролем. В этом случае, просто позволяя администратору изменить пароль является не достаточным. Новый пароль не будет работать для расшифровки данных, и большинство пользователей сочтет неприемлемым, что все их зашифрованные данные станут недоступными, когда / если они забудут / потеряют пароль. Для этой ситуации есть альтернатива, которая является достаточно безопасной и позволяет восстановление, когда это действительно необходимо.
Вместо того чтобы использовать пароль пользователя для шифрования данных, вы создаете случайный ключ для шифрования самих данных. Затем этот ключ хранится в нескольких местах: один раз зашифрованный с помощью пароля пользователя, а в другом месте зашифрованный с помощью пароля администратора. Затем, когда (не совсем так) пользователь теряет свой пароль и больше не может напрямую обращаться к данным, вы можете использовать пароль администратора для расшифровки реального ключа и использовать его для восстановления данных и / или повторного шифрования ключа с помощью новый пароль пользователя.
Если вы не хотите полностью доверять одному администратору, вы также можете управлять этим. Например, вы можете решить, что 5 человек будут иметь ключи администратора, и вы хотите, чтобы как минимум три из них согласились, прежде чем ключ можно будет восстановить. В этом случае, когда вы храните зашифрованный пароль для административных целей, вы сохраняете его несколько раз, по одному для каждого набора из трех из пяти администраторов (что не занимает много места, поскольку вы храните только несколько ключей , ~ 256 бит за штуку, а не несколько копий данных). Каждая из этих копий последовательно шифруется с помощью (хэшей) каждого из паролей этих трех администраторов.
Чтобы расшифровать его, вам нужно идентифицировать трех администраторов, которые вводят свои пароли, и выбрать правильный зашифрованный ключ для этого набора из трех, а затем расшифровать, используя каждый из трех паролей, чтобы в итоге получить исходный ключ. Затем вы можете использовать это для восстановления самих данных или просто зашифровать их с помощью (хэша) нового пароля пользователя, чтобы он все еще имел доступ к своим данным.
Однако, когда вы делаете это, вам действительно необходимо использовать стандартный алгоритм шифрования и (в силу строгих предпочтений) стандартную, хорошо известную и тщательно изученную его реализацию.
источник
Это беспокоит меня, учитывая, что это для правительственного проекта. Получение пароля пользователя для выполнения действия под его идентификатором делает бессмысленным любой вид аудита безопасности. Единственная причина, по которой я это вижу, - создать поддельный контрольный журнал.
Там действительно нет необходимости использовать обратимое шифрование для паролей. Если когда-либо есть законная причина подделать идентификатор пользователя, это можно сделать следующим образом:
Мне было бы неудобно с последним шагом - кто бы ни был изображен в системе, должен знать, что это произошло. Может быть, вы можете убедить бизнес, сказав: «Это похоже на то, что ваш банк позволяет мне получить доступ к вашему счету без вашего ведома, потому что я сказал, что мне действительно нужно»
источник
Их вера в лучшую систему паролей не является проблемой. Создайте решение, позволяющее администратору / службе поддержки выдавать себя за учетную запись пользователя и предоставлять исправления для паролей. Безопасность часто страдает для удобства. Сделать это удобно и безопасно.
Редактировать: они никогда, никогда, никогда не собираются полностью понять проблему безопасности пароля, но они действительно понимают потерю функциональности. Сделайте это предложение и посмотрите, сможете ли вы получить разрешение на внесение необходимых изменений. Они даже не знают, займет ли это один час или один год. Это изменение функции, а не полная перестройка.
источник
Учитывая текущие события (утечка данных Epsilon и утечка данных Playstation Network), можно было бы надеяться, что проблемы будут очевидными.
Однако иногда, как разработчик, вы просто не можете влиять на политику.
Я приложил бы все усилия, чтобы показать потенциал для скандала и расходов, что должно быть легко, снова учитывая текущие события. Но если это не удастся, что вы действительно можете сделать. Немного. Выйдите в знак протеста, продемонстрируйте уязвимость, чтобы привлечь внимание. Ни один не звучит как отличные варианты.
источник
Я бы посоветовал против этого, но если вам абсолютно необходимо иметь возможность расшифровывать пароли, вы должны использовать шифрование с открытым ключом. Таким образом, вы можете зашифровать все пароли с помощью открытого ключа. Вы можете проверить пароли, зашифровав их с открытым ключом и сравнив, и вы можете сохранить закрытый ключ где-то еще (не на рабочем компьютере).
источник
Обычно причина, по которой администратор видит пароль пользователя, заключается в том, что в случае его утери он может предоставить его пользователю. Насколько я могу судить, Windows также не позволяет администратору видеть пароль - так зачем ваше приложение? Любая внутренняя библиотека шифрования обязательно будет взломана, потому что я уверен, что тот, кто ее написал, не работает для АНБ.
источник