Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Скажу так, технические проблемы надо решать техническими методами, социальные — социальными. Не смешивать.
Техническая проблема — слабость на уровне архитектуры парольной авторизации. На данный момент проблема решаема двухфакторной авторизацией. Есть даже более простая схема. Например, такая штука, как Battle Net Authentificator. Для меня до сих пор загадка, почему бы банкам и крупным порталам не использовать такую же схему, ведь уровень защищённости выше в несколько раз, а дополнительных проблем на 15 минут сразу, и по одной минуте в неделю на ввод кода. Как технарь, могу предложить даже распределённую архитектуру с открытой реализацией для таких аутентификаторов, что позволило бы кому угодно использовать такую схему авторизации. И это только один из вариантов, не требующий тотальной деанонимизации.
Социальная проблема — глобальное непонимание обществом границ личных данных. Когда я решил купить вторую SIM-карту, первый вопрос моего отца, знатного технофанатика и фаната анонимности в интернете (да, и такое бывает), был «первую спалил?», намекая на использование номера этой симки в соцсетях и для авторизации. Я был бы рад, если бы в таком направлении думала хотя бы половина пользователей интернета. Пока это не так, они будут жертвами киберпреступлений, какую техническую защиту не придумывай.
Техническая проблема — слабость на уровне архитектуры парольной авторизации. На данный момент проблема решаема двухфакторной авторизацией. Есть даже более простая схема. Например, такая штука, как Battle Net Authentificator. Для меня до сих пор загадка, почему бы банкам и крупным порталам не использовать такую же схему, ведь уровень защищённости выше в несколько раз, а дополнительных проблем на 15 минут сразу, и по одной минуте в неделю на ввод кода. Как технарь, могу предложить даже распределённую архитектуру с открытой реализацией для таких аутентификаторов, что позволило бы кому угодно использовать такую схему авторизации. И это только один из вариантов, не требующий тотальной деанонимизации.
Социальная проблема — глобальное непонимание обществом границ личных данных. Когда я решил купить вторую SIM-карту, первый вопрос моего отца, знатного технофанатика и фаната анонимности в интернете (да, и такое бывает), был «первую спалил?», намекая на использование номера этой симки в соцсетях и для авторизации. Я был бы рад, если бы в таком направлении думала хотя бы половина пользователей интернета. Пока это не так, они будут жертвами киберпреступлений, какую техническую защиту не придумывай.
По моему, вся статья какой-то троллинг с вполне определенным посылом. Пока государство старается централизовать все сферы в том числе экономическую, делать его центром сертификации всего нельзя. По идее государство — арбитр, который смотри за выполнением правил игры ради среднего благополучия. Если нарушаются правила, то есть установленный и известный порядок — сбор доказательств, суд, наказание. Введение таких внесудебных способов глобального влияния на экономическую и личную свободу граждан особенно когда государство имеет свои собственные экономические интересы плохо скажется на развитии государства. Технически, да — мультифакторная авторизация (пин/пароль, телефон, биопаспорт,… — любое из двух) решает проблему, но если поднять культуру до того, чтобы люди поняли зачем это надо, то они начнут задавать и другие вопросы.
> Тем самым намекая, что контролем и выдачей цифровых паспортов должны заниматься на государственном уровне.
А что делать, если я нашему государству на подобном уровне ну вот совсем не доверяю. Уж лучше, имхо, конторе вроде Гугла или Эппла «отдаться».
А что делать, если я нашему государству на подобном уровне ну вот совсем не доверяю. Уж лучше, имхо, конторе вроде Гугла или Эппла «отдаться».
Хорошая попытка, товарищ майор, но нет!
Если мы говорим о внедрении специальных устройств типа USB-токена, то такая опасная централизация становится ненужной. Действительно, пусть устройство хранит набор независимых ключей от всевозможных сервисов, а само отпирается по единому пин-коду, отпечатку пальца или чему там еще. Проблема уже будет решена на том же уровне безопасности, но без необходимости централизации.
Если мы говорим о внедрении специальных устройств типа USB-токена, то такая опасная централизация становится ненужной. Действительно, пусть устройство хранит набор независимых ключей от всевозможных сервисов, а само отпирается по единому пин-коду, отпечатку пальца или чему там еще. Проблема уже будет решена на том же уровне безопасности, но без необходимости централизации.
Насколько я знаю секретные ключи записывается в память USB-токена во время производства и не изменяется в будущем. А ведь не возможно заранее предусмотреть список всевозможных сервисов, которые вам понадобятся. Некоторые сервисы могут предоставить подобную авторизацию после выпуска вашего токена. А сколько новых сервисов появиться в будущем? В этом случае на мой взгляд найдутся много желающих сменить свои токены. Учитывая, что смена токена удовольствие не бесплатное многие скажут «зачем нам этот брелок, который не позволяет авторизоваться на нужных нам сайтах» Т.е. подобное решение оказывается несостоятельным еще до появления, так как не может стать универсальных ключом от всех дверей. А значит эти токены окажутся еще более проблемным решением чем использование паролей. Увы, в данном варианте я не вижу надежного решения проблемы безопасности. Именно поэтому я предлагаю использовать единый центр авторизации как центральное звено в данной задаче.
Если у вас есть свое решение, которое на ваш взгляд может иметь хорошие перспективы то предложите их более детально. Буду рад рассмотреть.
Если у вас есть свое решение, которое на ваш взгляд может иметь хорошие перспективы то предложите их более детально. Буду рад рассмотреть.
Не, в токене лежит некий уникальный ключ. Для его использования сторонним сервисом не нужно выпускать новый токен. Просто написать процедуру аутентификации, и все. Но тут проблема в том, что нужен будет некий центр, подтверждающий подлинность ключа.
А если использовать вариант со многими ключами (предложенный выше) — то тут вообще нет смысла делать токен RO.
Таким образом, описываемый токен — это, по сути, USB-флэшка с защищенным хранилищем клиентских сертификатов.
Таким образом, описываемый токен — это, по сути, USB-флэшка с защищенным хранилищем клиентских сертификатов.
Вопрос не только в подлинности ключа. Чтобы всевозможные сервисы могли самостоятельно авторизовать вас, они должны иметь вторую пару ключа, позволяющий расшифровать ваш биометрический отпечаток (или что там зашифровано передается). Но если этот ключ будет доступен множеству сайтов, то оно по определению будет является скомпрометированным. Это то же самое что выставить данный ключ публично. А каждый, кто имеет доступ ко второй паре вашего ключа может расшифровать цифровую копию вашего биометрического отпечатка и использовать его при создании нового брелка. Т.е. создадут поддельный токен с вашим отпечатком, и все последствия использования данного ключа посыпаться на вашу голову — ведь там ваша цифровая копия биометрического отпечатка, значит вам и отвечать перед законом. Решение мягко говоря не имеет абсолютно никакой безопасности. Поэтому вторая пара закрытого ключа должна находиться только в одном месте — в едином центре авторизации под семью замками от посторонних. Этот момент я также отметил и в самой статье
При этом закрытые ключи должны находится только на сервере авторизации (например, во внутреннем сервере единого центра авторизации проверяющего достоверность полученных данных, но не имеющего прямого выхода к сети интернет).Данный пример еще раз подтверждает, что авторизация должна идти только через единый центр авторизации (это не моя прихоть, как могут подумать читатели, типа я собрался создать тотальный контроль — это абсолютная необходимость данного метода)
См. "асимметричное шифрование".
Аутентификация не должна идти через этот некий центр. Он нужен только для подтверждения подлинности ключа (да и то можно обойтись и без него, в принципе).
Аутентификация не должна идти через этот некий центр. Он нужен только для подтверждения подлинности ключа (да и то можно обойтись и без него, в принципе).
Если вам не трудно, то опишите более детальную схему, при котором можно будет обойтись без центра авторизации. Где и что хранить, где и как производить проверку подписи и расшифровку данных. Т.е. всё как вы себе это представляете. Если получиться построить жизнеспособную модель с распределенной авторизации, то попробуем построить полностью схему и описать в новом топике. Далее можно будет сравнивать оба варианта и рассмотреть положительные и отрицательные обоих методов.
По ссылке достаточно подробно разобран принцип работы. Нечто подобное использует, например, StartSSL для аутентификации. И, вроде бы, в Госуслугах что-то такое есть (вход по УЭК/ЭЦП).
Да просто ради примера можете изучить принцип аутентификации по ключам в том же SSH.
Да просто ради примера можете изучить принцип аутентификации по ключам в том же SSH.
По ссылке описаны различные варианты — криптография с необратимым шифрованием, криптография с открытым ключом, криптография с несколькими открытыми ключами.
Я не совсем понял какую из этих вариантов и по какой схеме вы предлагаете использовать?
Я не совсем понял какую из этих вариантов и по какой схеме вы предлагаете использовать?
Вы, как я понял, изучаете возможность создания некоего сервиса — вот вам и думать, какой вариант вам лучше подойдет. Конкретных реализаций можно придумать много.
Самый простой вариант, который вы можете пощупать с минимальными усилиями и затратами времени — это аутентификация по ключам в SSH.
Самый простой вариант, который вы можете пощупать с минимальными усилиями и затратами времени — это аутентификация по ключам в SSH.
Самый простой вариант, который вы можете пощупать с минимальными усилиями и затратами времени — это аутентификация по ключам в SSH.Об этом я тоже думал. Но конкретные схемы которые я пытаюсь придумать оказываются с определенными изъянами, которые мешают возможности их массового применения.
С какими изъянами? Трудность генерации ключевой пары? Реализация защищенного хранилища?
Ну например рассмотрим такой вариант:
1) С закрытым ключом токен шифруется общедоступный SSL сертификат, например это сертификат производителя токена. А открытый ключ доступен всем.
2) Любой сайт может расшифровать ваше зашифрованное сообщение используя ваш открытый ключ и проверить SSL сертификат на сайте производителя токена. Т.е. только при шифрование вашим токеном можно после расшифровки получить SSL сертификат производителя токена. Подтасовка не возможна, так как при любых попытках шифрования другим ключом после расшифровки получится не сертификат а абракадабра. А закрытый ключ находится только внутри вашего токена и никому не доступна.
Недостатки:
1.1) Как все ресурсы должны получить ваш открытый ключ? Вы сами будете в аккаунте нужного вам сайта привязывать ваш открытый ключ? А ведь для этого нужно еще как то авторизоваться на сайте — решение мягко говоря не хорошая.
1.2) Хотя производитель токена на своем сайте может размещать все публичные ключи, вот только каким образом интернет ресурсы должны сопоставить эти ключи со своими аккаунтами? Ведь производитель ключа не должен публично раскрывать личные данные владельца открытого ключа, а публичное сопоставление хотя бы ФИО владельца будет явно не достаточно. Значит авторизацию нужно перенаправить на производителя ключа и снова получаем, что аутентификация должна идти через некий центр.
2) В процессе авторизации вы отправляете на сайт SSL сертификат производителя, подписанный вашим токеном. А каким открытым ключом должны расшифровать ваше сообщение на сайте? Сайты же не знают от кого пришло зашифрованное сообщение и какой открытый ключ им применить. Перебирать всеми ключами, пока на выходе не получат правильный SSL сертификат производителя? Снова нет оптимального решения.
1) С закрытым ключом токен шифруется общедоступный SSL сертификат, например это сертификат производителя токена. А открытый ключ доступен всем.
2) Любой сайт может расшифровать ваше зашифрованное сообщение используя ваш открытый ключ и проверить SSL сертификат на сайте производителя токена. Т.е. только при шифрование вашим токеном можно после расшифровки получить SSL сертификат производителя токена. Подтасовка не возможна, так как при любых попытках шифрования другим ключом после расшифровки получится не сертификат а абракадабра. А закрытый ключ находится только внутри вашего токена и никому не доступна.
Недостатки:
1.1) Как все ресурсы должны получить ваш открытый ключ? Вы сами будете в аккаунте нужного вам сайта привязывать ваш открытый ключ? А ведь для этого нужно еще как то авторизоваться на сайте — решение мягко говоря не хорошая.
1.2) Хотя производитель токена на своем сайте может размещать все публичные ключи, вот только каким образом интернет ресурсы должны сопоставить эти ключи со своими аккаунтами? Ведь производитель ключа не должен публично раскрывать личные данные владельца открытого ключа, а публичное сопоставление хотя бы ФИО владельца будет явно не достаточно. Значит авторизацию нужно перенаправить на производителя ключа и снова получаем, что аутентификация должна идти через некий центр.
2) В процессе авторизации вы отправляете на сайт SSL сертификат производителя, подписанный вашим токеном. А каким открытым ключом должны расшифровать ваше сообщение на сайте? Сайты же не знают от кого пришло зашифрованное сообщение и какой открытый ключ им применить. Перебирать всеми ключами, пока на выходе не получат правильный SSL сертификат производителя? Снова нет оптимального решения.
Подождите, вам нужна аутентификация (т.е. подтверждение что некий человек, пытающийся получить доступ к некоему ресурсу — это действительно тот, за кого себя выдает, без привязки к ФИО и паспортным данным) или функции ЭЦП?
Тогда п.1, 2 и 3 решаются просто — пользователь имеет ключевую пару. При регистрации на сайте заливает туда свой публичный ключ. Все.Вообще то логично)
Хотя проблему под пунктом 2 можно решить так: производитель токена на своем сайте размещает вместе с публичным ключом некий порядковый номер, привязанный на этот ключ. А в процессе авторизации токен включает в свое сообщение этот же номер в незашифрованном виде.
Есть еще одна проблема:
3) Сайты должны будут внедрять себе сложной функционал по работе с ЭЦП и привязывать его к аккаунту своих пользователей на уровне БД. Реализация получится весьма не простым, а по поводу привязывания к аккаунтам — тут вообще нужен чуть ли не персональный подход на каждом сайте. Много ли сайтов смогут это реализовать?
А если сайты сами не авторизуют а просто переадресуют процесс авторизации в некий центр и потом получают необходимое решение, то и модуль получиться весьма простым и легко реализуемым.
3) Сайты должны будут внедрять себе сложной функционал по работе с ЭЦП и привязывать его к аккаунту своих пользователей на уровне БД. Реализация получится весьма не простым, а по поводу привязывания к аккаунтам — тут вообще нужен чуть ли не персональный подход на каждом сайте. Много ли сайтов смогут это реализовать?
А если сайты сами не авторизуют а просто переадресуют процесс авторизации в некий центр и потом получают необходимое решение, то и модуль получиться весьма простым и легко реализуемым.
Реализация не такая уж и сложная. Есть тонны готового кода под кучу языков.
К слову, привязка в третьестороннему сервису тоже потребует неких усилий для реализации. Хотя тут можно подумать над чем-то OpenID-совместимым, например.
К слову, привязка в третьестороннему сервису тоже потребует неких усилий для реализации. Хотя тут можно подумать над чем-то OpenID-совместимым, например.
Можно предложить оба варианта:
1) Разработать методики внедрения под различные CMS и готовые коды по работе с ЭЦП, чтобы владельцы сайтов смогли реализовать авторизацию с токеном своими силами и меньшей кровью.
2) Предложить готовые OpenID-совместимые решения, для переадресации процесса авторизации на сервер производителя токена.
1) Разработать методики внедрения под различные CMS и готовые коды по работе с ЭЦП, чтобы владельцы сайтов смогли реализовать авторизацию с токеном своими силами и меньшей кровью.
2) Предложить готовые OpenID-совместимые решения, для переадресации процесса авторизации на сервер производителя токена.
Сервисы, которые требуют биометрию пользователя, идут лесом. Ну, кроме медицинских и тому подобных, которым принципиально важен доступ к телу или гарантия существования оного.
Если нужна идентификация личности (в банке, например), то делается очень просто: я распечатываю свой сертификат (который в идеале сгенерирован токеном по моей команде, хотя может и на моем компьютере, что несколько хуже, поскольку требует доверия к компьютеру), пешком иду в банк и там, показав паспорт, отдаю. Этот механизм уже достаточно давно отработан, и я им пользовался. Единственная проблема — банк сам выдает (точнее, продает) мне USB-токен, лишая возможности выбора поставщика.
Если нужна идентификация личности (в банке, например), то делается очень просто: я распечатываю свой сертификат (который в идеале сгенерирован токеном по моей команде, хотя может и на моем компьютере, что несколько хуже, поскольку требует доверия к компьютеру), пешком иду в банк и там, показав паспорт, отдаю. Этот механизм уже достаточно давно отработан, и я им пользовался. Единственная проблема — банк сам выдает (точнее, продает) мне USB-токен, лишая возможности выбора поставщика.
Не, в токене лежит некий уникальный ключ. Для его использования сторонним сервисом не нужно выпускать новый токен. Просто написать процедуру аутентификации, и все. Но тут проблема в том, что нужен будет некий центр, подтверждающий подлинность ключа.
Сейчас сервисы обходятся без централизованной аутентификации. Менять это не нужно.
Если я регистрирую аккаунт на форуме с ником «Вася Пупкин» нет нужды проверять, что это моё настоящее имя.
Сервису достаточно запомнить публичный ключ из новой сгенерированной мной пары ключей и пускать меня в аккаунт, если я подтверждаю, что владею секретным ключом к этому публичному.
Секретные ключи генерируются на самом токене и никогда его не покидают (токен не дает экспортировать эти ключи). Открытые же части ключей при регистрации отправляются на сервисы, которые хотят аутентификации по этому токену. При самой аутентификации токен подписывает закрытым ключем случайную строку, сервис проверяет сохраненным открытым. Единственная проблема в этом случае — утеря/выход из строя токена.
секретные ключи записывается в память USB-токена во время производства и не изменяется в будущем
Это какие-то неправильные токены. Возможно, они для чего-нибудь могут быть полезны, но не в нашем случае. Выше в комментариях про это написано.
Я представляю себе это устройство так. Оно управляет неограниченным набором ключей: умеет их создавать, уничтожать, отдавать сертификат и подписывать переданное внешним компьютером сообщение. Должны быть механизмы аутентификации пользователя самим устройством (пароли, биометрия, дополнительные имплантируемые устройства и т.п.; это, пожалуй, самая нетривиальная и потенциально уязвимая часть). Оно также должно иметь хотя бы одну кнопку и, очень желательно, мелкий экранчик, чтобы отображать некую выжимку (заголовок) подписываемого сообщения. Это важно, поскольку мы не должны доверять компьютерам, в том числе своим личным, поскольку они фундаментально уязвимы из-за необходимости устанавливать и обновлять софт.
Пожалуй поддержу, от поста как-то веет пропагандой УЭК. Не спорю нужно бороться с неграмотностью пользователей, но что-то с киберпреступностью, такое ощущение, никто бороться не собирается, а воспринимается как данность, а это прогрессирующая болезнь.
Есть решения, многие уже привели в комментариях и без выпуска цифрового паспорта.
Есть решения, многие уже привели в комментариях и без выпуска цифрового паспорта.
Если не трудно, то опишите более детальную схему, при котором можно будет обойтись без центра авторизации. Где и что хранить, где и как производить проверку подписи и расшифровку данных. Т.е. всё как вы себе это представляете. Если получиться построить жизнеспособную модель с распределенной авторизации, то попробуем построить полностью схему и описать в новом топике. Далее можно будет сравнивать оба варианта и рассмотреть положительные и отрицательные обоих методов.
По поводу УЭК. Я не давно читал статью про эти карточки, и после прочтения у меня осталось чувство неудовлетворенности некоторыми моментами реализации таких карт. В частности, из описаний этих карт я понял, что их предполагают использовать для быстрого ввод паспортных данных в вокзалах и в аэропортах, при посещении банка, пенсионного фонда и других организаций бюрократической машины. Т.е. предусмотрели только решение проблем бюрократической машины, но никак не рассматривают его использование в интернете, для решения пользовательских задач авторизации и проверки личности. И я решил предложить некую альтернативу таким бесполезным с точки зрения пользователей картам, и построить свою модель решения вопросов авторизации и безопасности в интернете.
По поводу УЭК. Я не давно читал статью про эти карточки, и после прочтения у меня осталось чувство неудовлетворенности некоторыми моментами реализации таких карт. В частности, из описаний этих карт я понял, что их предполагают использовать для быстрого ввод паспортных данных в вокзалах и в аэропортах, при посещении банка, пенсионного фонда и других организаций бюрократической машины. Т.е. предусмотрели только решение проблем бюрократической машины, но никак не рассматривают его использование в интернете, для решения пользовательских задач авторизации и проверки личности. И я решил предложить некую альтернативу таким бесполезным с точки зрения пользователей картам, и построить свою модель решения вопросов авторизации и безопасности в интернете.
В будущем можно будет объединить обе технологии и создать токены, для считывания цифровой копии биометрического отпечатка с карт УЭК.
Более подробно схему авторизации в интернете с использованием ЭЦП я предложил в следующем топике «Схема авторизации с использованием электронных цифровых подписей вместо парольной защиты».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пароли — это прошлый век, в дальнейшем требуются новые методы авторизации и хранения личных данных