Що робити, коли ваша компанія не шифрує паролі

Фон

Мене домовили про допомогу компанії підтримувати їх сервер. Я працюю над деякими незначними проектами 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, щоб допомогти вам також:

Це дійсно залежить від аудиторії, в якій ви намагаєтеся з цим підійти. Я працював у компаніях із серйозними проблемами безпеки, як ви заявляєте, але вони відмовились його слухати, поки я не показав їм це.

Один із підходів, якщо це можливо, полягає в тому, щоб зібрати в основному те, що ви маєте намір зробити, оскільки буде деталізація того, що вже можливо сталося в цих хаках. Якщо ваша аудиторія не є технічною, вам, ймовірно, потрібно вказати вартість бізнесу, яку можуть мати ці компроміси. Очевидно зламані облікові записи знижують довіру до вашої системи та сприймають споживчу цінність вашого продукту. Не кажучи вже про порушену систему з простими текстовими паролями та електронними адресами для користувачів, це може спричинити серйозний ефект пульсації.

Наступне, що вам слід зробити, якщо це можливо, це довести. Якщо ви можете витримати цю систему в тестовому середовищі, зробіть це. Потім продемонструйте перед ними вид впливу, який ви можете мати на систему з боку клієнта програми. Навіть з технічними людьми це виявилося для мене досить переконливо (хоча вони досі зазвичай не діяли в моїх випадках).

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

Якщо, як ви говорите, у вас було укладено договір на підтримку їх сервера, безумовно, цей договір повинен включати в завдання опису завдань, такі як забезпечення цілісності, безпеки та доступності операційної системи, прикладного програмного забезпечення та всіх даних тощо ?! Якщо є навіть невиразний натяк на те, що контракт очікує (і несе вас відповідальності) щодо забезпечення надійності сервера, то я б не витрачав час на складання ділових справ і просто зробив би хорошу роботу, щоб переконатися, що проблеми усунені (приймаючи резервна копія до і після, зберігаючи історію версій вашого коду).

Я б не очікував, що така зміна займе більше, ніж за ранкову роботу, і якщо вони запитають, на що ви витратили свій час, працюючи, тоді ви можете вести журнал, щоб пояснити та виправдати свої дії. Якщо ви працюєте в рамках свого контракту, тут не повинно виникнути жодних проблем. Іноді безглуздість безпеки перед особами, які приймають рішення, викликає паніку або, в гіршому випадку, створює можливість для них сказати, що вони не цікавляться цими питаннями, тому не виправляйте це, тим часом, якщо ви укладаєте договір, ви все ще несете відповідальність у випадку порушення! Можливо, це не завжди є найбільш зручним для бізнесу підходом, але моя професійна етика не дозволила б мені залишати незашифровані паролі в будь-якій системі, за яку я коли-небудь відповідав за те, щоб він міг мені прийти до відома.

З особистого досвіду я схильний знаходити кожного разу, коли я починаю працювати для нового роботодавця чи клієнта, обговорення сценаріїв та очікувань наперед може врятувати великий стрес з вашого боку, наприклад: якщо я знайду якісь проблеми із безпекою, які я можу виправити, ви раді щоб я продовжував і завершував цю роботу, не приїжджаючи до вас щоразу, лише повідомляючи вас про підозру в порушеннях / інцидентах? Вони майже завжди скажуть «так», тому що з їхньої точки зору вони не зацікавлені у турботі про безпеку чи комп'ютерні речі - ось чому вони вас найняли! Можливо, це не відповідає на питання так, як ви очікували, але я сподіваюся, що це дає їжу для роздумів. Бажаю вам всього найкращого та сподіваємось, що проблема буде виправлена!

Безумовно, якщо зміна електронної адреси клієнта вже відбувається, і це вважається проблемою - тоді можливість зміни паролів також є проблемою.

Тепер, якщо ви забезпечили БД достатньою мірою, щоб не допустити цього в майбутньому, то шанс, що хтось може змінити пароль користувача, аналогічно виправлений, і вам потрібно лише врахувати, чи може хтось зараз прочитати пароль.

Звичайно , якщо вони можуть, або якщо (в малоймовірному випадку) , що ви не повністю забезпечені БД , то , звичайно , шифрування паролів має бути зроблено - як це зробити? Просто поставте його в той же контекст, що і проблема "з оновленнями електронних адрес". Чи потребує це зміна програми та чи це "занадто складна" проблема - це ще одна справа, яку потрібно вирішити разом із ними. Подивіться на код і подивіться, скільки коштуватиме його зміна, перш ніж приймати запропоновані виправлення до них.