Хранение пароля в базах данных в виде простого текста по сравнению с потребностями клиентов

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

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

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

Также стоит отметить, что, если кто-то спроектировал систему с такими фундаментальными недостатками, как эта, вероятность появления ошибки, которая может раскрыть такие конфиденциальные данные, экспоненциально выше.

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

Бастаннеу, знаете ли вы английское выражение «Cover your a **»? Представьте себе такой сценарий:

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

Я рекомендую вам сообщить о своих опасениях заранее. И сохраните доказательства (подписанное письмо и т. Д.).

Демонстрации и пояснения наиболее полезны, но когда вы говорите, что должны «обновить» приложение, вы работаете с документацией, функциональной или технической спецификацией?

Было бы неплохо попросить принять участие в доработке этих документов и включить их в их подписание.

В конечном счете, это потребность клиента, он просто еще не осознает этого.

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

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

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

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

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

Никогда не храните пароль в виде открытого текста.

Я бы порекомендовал прочитать следующие вопросы:

• Как лучше всего хранить информацию о пользователях, а также логин и пароль пользователя
• Рекомендации по хранению базы данных пароли
• Лучшие методы управления паролями (суп к орехам, а не только хранение или генерация)
• Солить свой пароль: лучшие практики?
• Можно ли когда-либо хранить пароль в виде простого текста в переменной php или константе php?

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

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

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

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

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

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

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

Ура, дружище!

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

Тогда возникает вопрос, как вы убедить деловые люди, что это не верное решение. Это тоже должно быть довольно легко. Найдите лиц, принимающих решения, и приведите их к машине, на которой открыт браузер запросов к базе данных. Введите запрос "Выберите пароль из учетных данных, где имя пользователя = 'DECISION_MAKERS_USERNAME'", затем попросите лицо, принимающее решение, выполнить его (будьте вежливы и не смотрите на экран, пока он это делает). Объясните, что любой сотрудник с доступом к базе данных сможет это сделать. В целом я бы подумал, что это поможет, но если вам нужно сделать дополнительные убедительные объяснения, объясните, что большая часть пользователей разделяет пароли между приложениями и что любой сотрудник сможет взломать такие вещи, как банковские счета, учетные записи электронной почты и т. Это. Если и этого недостаточно, объясните примеры судебных исков и штрафов для компаний, которые это сделали.

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

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