Что делать, если ваша компания не шифрует пароли

Фон

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

Эти ребята уже некоторое время работают на своем сервере, и у меня на последних ногах есть то, что я бы назвал устаревшим приложением. Он использует магические кавычки, глобальные переменные (что позволяет $idих перезаписывать $_GET['id']), использует .htaccess в качестве единственной защиты в некоторых случаях, вы называете это. Кошмар безопасности и программирования.

В прошлом нас взламывали, в основном с помощью SQL-инъекций, которые запускали SLEEP(99999999)команды и действовали как DOS-атака. К счастью, они не управляли «маленькими заколоченными столиками»,

XKCD: http://xkcd.com/327/

Поэтому я переписал их уязвимые операторы SQL из mysql_query()(не mysqli) в транзакции PDO. Я также анализирую запросы для SLEEPи UNION, которые мы не используем, но есть уколы. Все идет нормально.

Последний выпуск

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

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

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

Общение с клиентами

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

    ВЫПУСК № 1
        конспект
        Почему это проблема
        Что может случиться, если это не исправить
        Предлагаемое исправление

    ВЫПУСК № 2
        конспект
        Почему это проблема
        Что может случиться, если это не исправить
        Предлагаемое исправление
        

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

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

https://en.wikipedia.org/wiki/Information_privacy_law

И у вас есть этот XKCD, чтобы помочь вам:

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

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

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

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

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

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

Из личного опыта, который я обычно нахожу, когда начинаю работать на нового работодателя или клиента, обсуждение сценариев и ожиданий заранее может сэкономить много стресса с вашей стороны, например: если я найду какие-либо проблемы с безопасностью, которые я могу исправить, вы рады мне идти вперед и завершить эту работу, не приходя к вам каждый раз, только уведомляя вас о предполагаемых нарушениях / инцидентах? Они почти всегда говорят «да», потому что, с их точки зрения, они не заинтересованы в том, чтобы беспокоиться о безопасности или о компьютерах - вот почему они наняли вас! Возможно, это не отвечает на вопрос так, как вы ожидали, но я надеюсь, что это даст пищу для размышлений. Желаю вам всего наилучшего и надеюсь, что проблема будет исправлена!

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

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

Конечно, если они могут, или если (в маловероятном случае), что вы не полностью защитили БД, то обязательно нужно выполнить шифрование паролей - как это сделать? Просто поместите его в тот же контекст, что и проблема «обновление адресов электронной почты». Требует ли это изменения приложения и является ли это «слишком сложной» проблемой - это другой вопрос, который необходимо обсудить с ними. Посмотрите на код и посмотрите, сколько будет стоить его изменение, прежде чем предлагать им исправление.