Аутентифікація в Інтернеті за допомогою PKI Certs

Я добре розумію PKI з концептуальної точки зору - тобто приватні ключі / відкриті ключі - математика за ними, використання хешу та шифрування для підписання сертифіката, цифрове підписання транзакцій або документів тощо. Я також працював над проектами, де openssl Бібліотеки C використовувались із certs для забезпечення зв'язку та аутентифікації. Я також надзвичайно знайомий з інструментами командного рядка openssl.

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

Вимоги

Це веб-сайт банку. Усі користувачі Інтернет-банкінгу можуть використовувати будь-який сертифікат, виданий декількома відомими ЦА (verisign, Thawte, доручення тощо). Банк не несе відповідальності за придбання сертифікатів для користувача. Ці сертифікати будуть використані для аутентифікації на веб-сайті банків. Платформи / ОС тощо досі не закріплені.

Дизайн

Мені було цікаво, який найкращий спосіб зробити аутентифікацію.

1. Я бачив, що в Apache є спосіб ввімкнути двосторонній ssl - у цьому випадку, я думаю, що перехід на веб-сайт автоматично запитає сертифікат у користувача. Але я не впевнений, чи цього достатньо, тому що здається, що все, що він перевіряє, це те, чи сертифікат підписаний довіреною службою CA & також може бути, чи потрапляє він у білий список тематичних рядків сертифікатів тощо. Але цього недостатньо для банківської справи, оскільки вам потрібно мати можливість пов’язати банккусерид із сертифікатом.

2. Здається, у IIS є спосіб, яким я можу мати сертифікат, що зберігається для кожного користувача в Active Directory. Це я зрозумів, прочитавши кілька статей MSDN. Ви включаєте двосторонній SSL в IIS і тоді, коли користувач намагається перейти на веб-сайт, IIS надішле запит до браузера зі списком затверджених ЦС, і браузер дозволить користувачеві вибрати відповідний сертифікат зі свого сертифікату і надішле його до бекенда. Я припускаю, що IIS зробить 2 речі

   • Переконайтеся, що користувач має приватний ключ, відповідний cert (за допомогою переговорів на обкладинці)
   • На підставі картографічного відображення користувача AD, IIS повідомить ім’я користувача про програму.

3. Виконайте чіткість аутентифікації, зателефонувавши до функцій криптовалюти, а не залежно від веб-сервера.

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

Мені було цікаво, який метод є найпоширенішим? Які найкращі практики? Якщо мені варто піти з №3, які найкращі способи зробити це?

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

Оновлення

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

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

Хоча я дуже хотів відповідати на питання, але думаю, що я потрапив у цю тему за темою:

Авторизація / автентифікація

Гаразд, спочатку все. Для вашого прикладу вам потрібно обидва:

• Автентифікація - доказ того, що користувач - це той, про кого він каже. Ви вибрали PKI, маючи на увазі підтвердження приватного ключа, як автентифікацію.
• Авторизація - підключення користувача до того, що йому дозволено робити. Це точка зв'язку між входом у систему та отриманням доступу до дозволених облікових записів. Відображення сертифіката для можливостей доступу до облікових записів та облікових записів є авторизацією.

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

SSL, автентифікація клієнта / сервера, підтвердження приватного ключа

Протокол SSL завжди включає автентифікацію сервера, з додатковим додатковим параметром для авторизації на стороні клієнта. Ви маєте рацію №1 в тому, що Apache пропонує налаштування, яке додає автентифікацію клієнта PKI, і ви можете надати йому список надійних ЦО. Під час налаштування сеансу SSL, який вимагає автентифікації клієнта через PKI - ви отримаєте підтвердження приватного ключа.

Будь-який варіант №1 або варіант №2 забезпечать це - і Apache, і IIS можуть бути налаштовані таким чином. Найкраща мудра практика, я б взяв будь-який із способів прокрутити власне рішення. №3 небезпечно наближається до правила "не пишіть власну криптовалюту". Якщо припустити, що ви можете прив’язати свою транзакцію до наявності автентифікованого сеансу SSL, немає ніяких причин просувати свою власну.

Також - або в варіанті №1, або у варіанті №2, є спосіб отримати ваші руки на весь сертифікат, а звідти на будь-яку частину сертифіката. Як правило, суб'єктний DN та / або серійний номер сертифіката використовуються для визначення ідентичності користувача для цілей авторизації.

З точки зору "загального використання" - всі основні веб-сервери досить поширені. IIS, Apache, Tomcat та багато інших можуть бути налаштовані з клієнтом auth SSL. Рішення звідси багато в чому ґрунтується на загальній реалізації. На основних веб-серверах були всі способи отримати доступ до сертифіката, наданого в сеансі SSL, і це те, що вам потрібно для більш детальної перевірки.

Підтвердження сертифікату Додайте

Як мінімум, вам потрібно буде:

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

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

У IIS можуть бути гачки для перевірки OCSP або CRL - це, як правило, більш всеохоплююча система (тримаючись за руки!), Але я не пам'ятаю вгорі голови. Я також не пам'ятаю, чи не змусить вас використовувати для цього продукти Microsoft. Для Apache вам майже напевно доведеться кодувати або додавати чек OCSP / CRL. Я вважаю, що він має гачки під час встановлення сеансу SSL - зазвичай ця перевірка виконується один раз, коли сеанс SSL налаштований.

Авторизація

Що стосується №1 проти №2 - ви маєте рацію, що IIS має вбудовану функціональність, яка прив'язуватиме сертифікат, наданий у сесії SSL, до сховища AD. Це один із випадків, коли Microsoft проходить додаткову милю, щоб полегшити покупку та використання більшої кількості продуктів. :) Є нюанси того, як зв'язки IIS в AD виходять за рамки цього питання і поза моїм негайним спогадом. Я зробив деякі досить шалені речі з IIS та AD, і моя загальна думка полягає в тому, що, хоча ви робите щось настільки просто, як витягувати ім'я користувача на основі сертифіката з сховища AD - ви, мабуть, добре. Це коли ви стикаєтесь із складнішими питаннями зберігання даних, незвичайними пошуками AD та особливо шаленими (але законними) речами з PKI,

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

Для №1 - так, вам потрібно написати власний пошук. Вам потрібно кодувати: - базу даних або ієрархію LDAP, що з'єднує сертифікат з користувачем, а користувач - на банківські рахунки користувача. Гарантована унікальна частина сертифіката - серійний номер + емітент DN. Часто Subject DN працюватиме, але це не гарантується у всіх системах PKI.

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

Це звучить як поєднання №1 та №3 - мої настійні поради - використовувати власні можливості будь-якого додатка / веб-сервера, який ви використовуєте для генерації сеансу SSL. Це дозволить налаштування браузера на сервер із запитом на сертифікат проходити стандартним, найкращим способом. Звідти, з Apache, вам потрібно буде передати власну систему авторизації. IIS надасть ідею Microsoft, як це має працювати для вас.

Відомі готчі

Зробіть купу тестування браузера. З року в рік я переглядаю браузер до браузера, і я знаходжу ґетчі з обробкою сеансів SSL. Правильне пов’язання сеансу SSL із серією запитів веб-сторінок та переконання, що вихід із системи виходить правильним, є найбільшою проблемою. І це має багато спільного як з сервером, так і з браузерним програмним забезпеченням. SSL є досить стабільним, що, коли він працює, він зазвичай працює, хоча може бути IE проти всіх інших питань.

Зокрема, останній раз, коли я це робив, питання про кодування сили та час відключення сеансу було великою справою.

Розумні телефони

Добре. Удача. є про все, що я можу сказати. Я зовсім не розробник мобільних додатків, але поки що моє враження полягає в тому, що в середньому смартфоні обробка PKI cert не є номінальною або не існує.

Я б так хотів, щоб довели неправильність.

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

але там, де це не вдається

• Вартість за сертифікат
• сумісність із сучасними браузерами
• кінцеві користувачі витягують сертифікати та зберігають приватні ключі

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

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

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

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

Наступна найкраща практика - використання каталогу для обробки клієнта: відображення сертифікатів. Тож ви будете дивитись на AD або LDAP. Як ви вже згадували, Windows та IIS роблять це досить бездоганним для вас. IIS.net має хороший пробіг у налаштуванні відображення сертифікатів під IIS .

Якщо ви котитеся з Apache, це не так просто поза рамками. Схоже, mod_authz_ldap робить відображення сертифікатів клієнта, але я особисто не працював з ним.

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

Я хотів би переглянути, що Google і Facebook роблять для встановлення файлів cookie для надійних пристроїв, щоб уникнути двофакторного. Я мав би нові пристрої auth з двофакторним, перш ніж дозволити auth лише для сертифікатів.

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

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