Чому паролі повинні бути зашифровані, якщо вони зберігаються в захищеній базі даних?

У мене є веб-служба. Зараз у мене на сервері паролі зберігаються у простому тексті в таблиці MySQL . Я знаю, що це не найкраща практика, і саме тому я працюю над цим.

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

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

Якщо паролі були зашифровані, ви можете просто відновити попередню базу даних. Це правильне мислення?

По-перше, ви повинні бути вільнішими з правами доступу лише для читання, ніж з читання-запису. Можливо, хакер має доступ до ваших даних, але не може їх редагувати.

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

Якщо ви відновите свою базу даних, хакер все ще має доступ до облікового запису вашого користувача.

А хто знає що ще? Що робити, якщо вони використовують той самий пароль в Google? Або PayPal? Що робити, якщо це дає хакеру доступ до дівочого прізвища їх матері чи останніх 4 цифр їхньої кредитної картки?

Що робити, якщо це потрапляє на інші рахунки? Не перекладайте хакера, щоб пройти систему підтримки користувачів та отримати більше інформації .

Просто ... просто не треба. Це приватна інформація вашого користувача, і вам не потрібно бачити її. Це також ваша репутація. Зашифруйте його.

EDIT: Ще один коментар, щоб врятувати будь-якого майбутнього читача від прочитання кожної відповіді та коментаря ...

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

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

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

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

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

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

Крім того, як сказав Елін, не намагайтеся прокручувати власне хешування (або шифрування). Використовуйте стандартну бібліотеку.

Але у мене є інші проблеми, якщо хтось потрапляє до моєї бази даних, тобто видалення даних.

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

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

... і оскільки так швидко хешувати паролі, у вас немає виправдань для того, щоб не дотримуватися кращих галузевих практик.

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

Крім того, не всі компроміси надають вам повний доступ до оболонки. Що робити, якщо вразливість, яку використовує зловмисник, є лише введенням SQL на usersстіл лише для читання ? Залишивши паролі незашифрованими, якраз і надав йому повний доступ.

Це на додаток до причин, наданих іншими відповідями щодо вашої відповідальності за захист даних користувачів. Моя думка, не тільки ваші користувачі мають що втратити.

Я маю розмістити тут відповідь на помилковість у самому запитанні. Ви запитуєте, чи потрібно шифрувати паролі. Ніхто не шифрує паролі; ніхто, за винятком таких служб та програм, як Firefox Sync та Roboform, єдиною метою яких є шифрування паролів.

Давайте розглянемо визначення:

У криптографії шифрування - це процес кодування повідомлень (або інформації) таким чином, що читати їх можуть лише уповноважені сторони.

І хешування:

Хеш-функція - це будь-який алгоритм, який відображає дані довільної довжини до даних фіксованої довжини.

Іншими словами, шифрування - це двостороннє перетворення, а хешування - це одностороння конверсія, тому, якщо ви не розшифровуєте їх для перегляду пізніше, це не шифрування.

Крім того, не просто хеш, сіль ! Прочитайте всю цю сторінку, перш ніж мати хеші.

Що стосується алгоритмів хешування, які зараз розглядає ОП, я запропонував би будь-який із варіантів високого класу SHA-2, наприклад SHA-384 або SHA-512.

І обов'язково використовуйте раунди хешування . Не хеш один раз, хеш кілька разів.

Розгляньте цю сторінку, щоб більше захистити процес входу.

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

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

Тут важливий принцип. Є лише одна людина, яка має будь-яку компанію, яка знає пароль користувачів. Це користувач. Не їхня дружина / чоловік, їхній лікар чи навіть священик.

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

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

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

Більш поширеним рішенням буде:

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

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

Основними аспектами, які забезпечують безпеку, є:

1. Знання хешу безпосередньо не забезпечує аутентифікацію.
2. Зворотний розрахунок пароля з хеша недоцільно.
3. Використання таблиць веселок (довгі списки паролів та їх обчислені хеши) стає складнішим, оскільки отриманий хеш залежить від імені користувача та пароля.

Вам потрібно "зашифрувати" (власне, "хеш", щоб правильно уявити хешування) паролі як другий рівень захисту : це покликане запобігти ескалації зловмисника, який отримав огляд даних лише для читання. що отримують доступ до читання-запису і, точно, починають змінювати дані. Часткові порушення лише для читання трапляються в реальному світі, наприклад, через деяку атаку SQL-ін'єкції з облікового запису з доступом лише для читання або шляхом вилучення жорсткого диска або старої резервної стрічки з сміттєвого контейнера. Я написав докладно на цю тему там .

Щодо правильних способів хеш-паролів, дивіться цю відповідь . Це передбачає солі, ітерації та, головне, не вигадування власних алгоритмів (саморобна криптографія - вірний рецепт катастрофи).

Я не повторюю те, що сказали інші люди, але якщо припустити, що у вас PHP 5.3.8 або вище, вам слід використовувати рідну PHP bcryptдля зберігання ваших паролів. Це вбудовано в PHP. Якщо у вас PHP 5.5, ви можете використовувати найкращу доступну констант паролів. Ви також можете використовувати бібліотеку, щоб змусити 5.3.8 або краще поводитись як 5,5.

Питання про переповнення стека Як ви використовуєте bcrypt для хешування паролів у PHP? пояснює це, а інші відповіді там пояснюють більше. Будь ласка, не поспішайте, намагаючись зробити це самостійно.

Я погоджуюся з відповіддю від pdr з причин, зазначених у цій відповіді.

Я додам наступне: ви повинні це зробити, тому що це легко зробити і загальновизнано як найкраща практика для будь-якої програми. Більш конкретно, паролі завжди повинні бути засоленими та хешированими перед тим, як писати на будь-яке стійке сховище. Ось хороша довідка про важливість засолювання та вибору хорошого криптографічного хешу (який також надає безкоштовний вихідний код на кількох популярних мовах): https://crackstation.net/hashing-security.htm

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

Сценарій, про який я можу придумати, - це те, що вас зламали.

Ще один сценарій, про який потрібно придумати: хтось пропустив вашу DBA (або хто інший може виконувати вибрані запити у вашій БД) 100 доларів, щоб дати їм паролі користувачів. Або соціальних інженерів якийсь стажист для цього.

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

Потім користувач irate подає до суду на вашу компанію за викриття свого пароля.

NOBODY (включаючи людей у ​​вашій компанії) повинен мати можливість читати звичайний текстовий пароль. Колись. Немає законної справи чи технічної потреби в цьому.

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

Що ж, дивно, що ніхто про це ще не згадав, але як бути з ФІЗИЧНОЮ безпекою вашої бази даних?

У вас може бути створена найкраща ІТ-безпека у світі, але це не зупиняє тих, хто може отримати фізичний доступ до ваших носіїв пам’яті. Що станеться, коли ваша команда сьогодні виграє Superbowl, а в центрі міста, де знаходиться ваш офіс / провайдер хостингу, спалахне невеликий бунт? (З огляду на те, що це два ситні сфери ІТ у США - Сіетл проти Денвера, я не вважаю це необґрунтованим). Моб пробивається до вашої будівлі, і поки влада переповнена, хтось захоплює частину вашого обладнання з базою даних, що містить паролі чіткого тексту?

Що станеться, коли федери з’являться та заволодіють вашим обладнанням, оскільки якийсь високопоставлений виконавець використовував свою посаду в компанії для здійснення незаконних біржових торгів? Тоді федерати використовують ці паролі для дослідження ваших клієнтів, хоча вони нічого поганого не зробили. Тоді вони усвідомлюють, що саме ВАС залишив їх вразливими.

Що відбувається, коли ваш ІТ-відділ забуває стерти старі диски RAID, які містили вашу БД, коли вони виконували планові заміни, перш ніж «роздавати» старі диски інтернам, а потім їхні сусідки по інтернату знайдуть те, що залишилося, і зрозуміють, що вони можуть » продати "його і ніколи їх не відстежувати?

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

Будь-який порядний архітектор знає, що безпека - це не те, про що ви пізніше «підтягуєтесь» за допомогою брандмауерів та політик експлуатації. Безпека повинна бути основною частиною дизайну з самого початку, а це означає, що паролі є односторонніми, НІКОЛИ не передаються із шифруванням (навіть усередині власних центрів обробки даних) і не підлягають відновленню. Все, що можна отримати, може бути поставлено під загрозу.

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

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

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

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

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

Якщо хто - то зацікавлений в вас, ви будете отримувати зламали. Важливо зробити все можливе, щоб в першу чергу запобігти злому, а також пом'якшити збитки, які наносяться, коли це трапиться, поставивши якомога більше перешкод. Хаші ваші паролі. Це не так важко налаштувати, і ви робите своїм користувачам сумлінну послугу, не сприймаючи їх конфіденційність серйозно. Спритно вважати, що ви якось краще захищаєтесь від зловмисних атак, ніж такі компанії, як Yahoo , Sony , або Target , яких усіх зламали.