Що робити, якщо клієнту потрібна можливість отримання паролів?

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

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

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

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

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

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

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

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

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

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

Факт: люди використовують один і той же пароль на багатьох сайтах

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

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

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

Як здійснити делегування рахунків

Делегування облікового запису у вашій заяві має бути здійснено інакше.

1. Адміністратори повинні увійти як самі, а потім
2. або (оскільки вони є пільговими користувачами)
   • введіть лише UserName або
   • виберіть певного користувача зі списку, щоб увійти як його

Це, безумовно, не слід робити, увійшовши за допомогою комбінації UserName + Password .

Це правда, що новий екран повинен бути розроблений для делегованого входу, але все ж.

Чому делегований вхід в систему краще?

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

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

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

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

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

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

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

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

Навіть якщо ви вважаєте, що всі адміністратори є надійними, це також робить компроміс паролем адміністратора руйнівними.

Також вам не потрібен пароль користувача для виконання операцій як їх. Ви можете реалізувати sudoподібну функцію.

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

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

У попередній компанії я продовжував боротися за можливість надсилати електронні листи для скидання пароля, щоб обійти цю проблему. І я продовжував отримувати відмову. Врешті-решт, я втомився лопати ковпаком проти припливу, тому пішов. Це був також гострий волохатий бос, який вважав, що дурні питання, які задають деякі веб-сайти банків, зараховуються до «двофакторної аутентифікації». Сперечатися з ним було схоже на мультфільм Ділберта (він був схожий на PHB).

Крім того, в програмі є фактично існуюча функціональність, щоб користувачі адміністратора отримували паролі користувачів, щоб увійти як користувачі, і робити те, що вони вимагають).

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

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

Останній федеральний веб-сайт, над яким я працював, збирав 1/4 мільярда доларів США на рік від кінцевих користувачів (з них близько 400 користувачів), тому реєстрація повинна була бути дуже щільною, і тільки дозволеного кінцевого користувача можна було торкатися веб-сторінки, де вони повідомляли про речі, за які сплачували акцизні збори.

Sony була однією з компаній з останніми порушеннями безпеки. Це була не лише мережа PS3, це і їх мережа MMORPG-ігор, де загалом було понад 25 000 000 імен, адрес, номерів кредитних карт, імен користувачів та паролів. Ви можете повірити, що я зовсім не щасливий (я хочу, щоб мій вічнокрилість!).

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

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

Ви можете роздрукувати список електронних листів та розшифровані паролі та помістити його на стіл свого начальника, з великим попередженням на титульній сторінці: "Конфіденційно"

Зробіть шрифт крихітним, щоб не витрачати папір.

Ви також можете показати їм, як bugzilla дозволяє адміністраторам себе представляти людям без використання пароля.

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

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

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

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

Якщо ви не хочете повністю довіряти одному адміністратору, ви також можете ним керувати. Наприклад, ви можете вирішити, що 5 людей матимуть ключі адміністратора, і ви хочете, щоб принаймні троє з них погодилися, перш ніж ключ можна буде відновити. У цьому випадку, коли ви зберігаєте зашифрований пароль в адміністративних цілях, ви зберігаєте його кілька разів, один раз на кожен набір з трьох з п'яти адміністраторів (що не займає багато місця, оскільки ви зберігаєте лише кілька ключів , при ~ 256 біт за штуку, а не декілька копій даних). Кожна з цих копій послідовно шифрується з (хешами) кожного з паролів для цих трьох адміністраторів.

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

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

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

Дійсно не потрібно використовувати зворотне шифрування паролів. Якщо коли-небудь є законна причина підробляти ідентифікатор користувача, це можна зробити:

• Збережіть поточний хеш паролів
• Заміна відомим значенням
• (Фактично-аудиторська-слідова діяльність, наприклад, переказ коштів на офшорний рахунок)
• Замініть оригінальний хеш пароля

Мені було б незручно з останнім кроком - той, хто був представлений у системі, повинен знати, що це сталося. Можливо, ви можете переконати бізнес, сказавши: "Це як ваш банк дозволив мені отримати доступ до вашого рахунку без вашого відома, тому що я сказав, що мені справді потрібно"

Їх віра в кращу систему паролів не є проблемою. Створіть рішення, щоб дозволити адміністратору / службі підтримки себе представити обліковий запис користувача та надати своє виправлення паролів. Безпека часто страждає для зручності. Зробіть це зручним і безпечним.

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

Враховуючи поточні події (витік даних Epsilon та витік даних Playstation Network), можна сподіватися, що проблеми будуть очевидно очевидними.

Однак іноді як розробник ви просто не можете впливати на політику.

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

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

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