А вот наличие нужного кол-ва кадров нужной квалификации в одном месте под вопросом и тут Азия со своей плотностью населения оптимальна.
Я подозреваю, что плотность населения ни при чем. Вряд ли этих специалистов вообще нужно много. А причем — это то что этих немногих людей, которые этот процесс настроить могут, буквально по пальцам пересчитать можно на всем шарике, они связана 'пожизненными' (или даже в буквальном смысле пожизненными) контрактами, NDA, запретами работать на конкурентов итд итп.
Карту нельзя сделать потому, что вы таким образом компрометируете карту.
А этого не понял. Почему копрометирую? В смысле, почему приложение авторизации в этой же карте сильно опаснее, чем в соседней, только для этого предназначенной.
Если у вас несколько лет будут и карты и возможность делать «как раньше», то на фига вам карты? Уязвимость-то вы оставили. А если вы можете устранить уязвимость прямо сейчас без карт, то ключ-карты не нужна. Получается, что они в любом случае ненужны. «Л» — Логика.
Такое же рассуждение работает и для внедрения чипов в картах. "Если нужно оставить обратную совместимость с магнитной полосой, то зачем вам чип? Уязвимость же останется. Если хочется, давайте отдельную, чисто чипованую карту лучше сделаем"
Одноко этого не произошло, а сами чипы почти повсеместно использовать стали. Правда, мнооого лет прошло.
Как я уже сказал — есть другие способы. Например, просто разрешить применять стандартные NFC-токены для авторизации.
Я, в общем, согласен, но стандартные токены с нужным функционалом как-то сильно отдельно и неудобно покупать надо, а карты — просто банком выдаются.
Отсюда мораль — зачем вы топите за какие-то хитрые карты и прочее, если нужно топить за использование отпечатков?
Я не верю в биометрию для этих целей. Прежде всего, потому что железку можно уничтожить, после чего никто никуда по ней доступа не получит. А биометрию уничтожить нельзя.
Но это тупо будет отдельный функционал на том же чипе карте.
Да. Именно это и следовало бы сделать. Вон, тут целых полторы новых платежных системы разработали и внедрили (МИР+система быстрых платежей) и нечего, как-то живем.
Проще добавить поддержку стандартного второго фактора, чтобы желающие могли купить себе ключ и радоваться.
Все таки не понял, почему нельзя сделать саму банковскую карту этим самым вторым фактором (с тем же самым стандартным протоколом, что у отдельного ключа). Ну да, поначалу функционал будет не у всех и нужно будет специально просить такую. Или даже таки отдельный ключ покупать. Но постепенно (они же не вечные) карты сменятся, телефоны с NFC подешевеют, люди обзаведутся ридерами и проблема 'есть не у всех' пропадет.
В данном случае речь идет не о протоколе, что при покупке используется, а о том, который следовало бы использовать (по моему мнению) при авторизации банковского клиента. Какой надо пин, такой и будет. Пусть даже другой. Не вижу в этом проблемы.
И вы предлагаете некий свой воображаемый протокол. Там всё не так работает. Теоретически, можно на карту свой отдельный протокол прописать, но зачем?
Ну, и вообще в ваш протокол содержит сразу несколько критических уязвимостей, да, и просто плохой.
Весьма возможно. На ходу же придумывался, без старательных размышлений. Но протоколы, используемые в бизнес-клиентах банков, что с аппаратными токенами работают, уже ведь есть? Они достаточно хорошие?
Почему чип на банковской карте не может делать то же самое, что чип внутри этого токена делает?
а потом независимо что-то там от банка подписываете и всё через недоверенную третью сторону.
В существующией ситуации, когда банк-клиент просто на телефоне стоит, эта непроверенная третья сторона тоже есть. В точности та же самая. Если добавить еще карту, она хотя бы ничего не может сделать, если карты нет поблизости.
Ну и, если уж очень не хочется, чтобы карта какой-то пин помнила, можно весь обмен выше модифицировать так, чтобы переданный карте pin она просто использовала в процессе формирования подписи тикета при авторизации. И пускай уже банк, а не карта, разбирается, правильный он был или нет.
Очевидно, что компрометации PIN-кода. После чего можно сделать клон карты даже не имея самой карты.
Во первых, это вроде бы ничем не отличается от риска утечки CVV, т.е. мы ситуацию не ухудшаем.
Во вторых, как ключики из чипа карты выковыривать?
Если же имеется в виду клон только по магнитной полосе — то использование такого клона моментально оспаривается.
И на всякий случай ещё раз повторю — если всё сделано правильно, то ПИН-код в банке не хранится, как вы его проверять будете?
Приблизительно (этап согласования сессионного ключа для общения с картой опущен, токости протокола — тоже, придумывалось на ходу):
приложение -> карте: Тут пользователь такой пин ввел. OK?
карта->приложению: (увеличивает счетчик неудачных попыток) Нет.
приложение->пользователю: неверный, давай еще раз.
пользователь: повторяет ввод пина.
приложение -> карте: Тут пользователь такой пин ввел. OK?
карта->приложению: Да.
приложение->банку. Тут залогиниться хотят с картой номер..., дай тикет авторизации
банк->приложению: высылает одноразовый тикет
приложение->карте: держи тикет от банка.
карта: проверяет подпись банка, подписывает тикет своим ключем.
карта->приложению: держи подписанный тикет.
Приложение->банку: держи подписанный тикет.
Банк: проверяет подпись карты на тикете и (не)дает доступ к информации о счете.
<через некоторое время, когда пользователь операцию сформировал>
приложение -> карте: Сделай мне подпись на "пакет данных операции"
карта->приложению: подписывает своим ключем и возвращает результат.
приложение->банку: пользователь захотел операцию сделать, вот подписанные данные.
банк: проверяет подпись на операции и (не)делает ее.
Вообще, не понимаю суди возражений. Аппаратные крипто ключи давно и успешно используются в бизнес-вариантах банковских клиентов. Защищаются именно pin-ами. Вот карта — и есть, по сути, такой аппаратный ключ. Который почему-то использовать не хотят.
pin от SIM-ки он сам проверить тоже не может. Что не мешает его вводить и пользоваться. Тут точно так же. Спрашиваем и чипу карты отдаем, чтобы она операции над счетом подтвердила.
Этот телефон уже имеет доступ к управлению банковским счетом — на нем приложение банк-клиента стоит. Какой сценарий атаки добавляется, если мы начнем pin карты спрашивать, а не тот pin, что сейчас это приложение использует?
Ридер — он просто ридер. Адаптер интерфейса к чипу карты. Который интерфейс вполне стандартный. С другой стороны — USB. Где я утверждал, что он хоть как-то от кражи защищает — непонятно.
Подключать — к телефону (тут лучше бы, чтобы ридер умел usb host, чтобы otg от смарта не требовать) или компу. Протоколы более высокого уровня, по которому банковское приложение внутри чипа карты с банком общаться будет — это пускай у банка и производителей карты голова болит. Сумели же как-то договориться о протоколах, что в NFC оплате используются.
Предоставлять — как банку хочется. Я бы продавал. Тупой адаптер интерфейса дешевый при массовом производстве.
А как вы авторизовывать пользователя в банковской системе или приложении будете? Просить его ввести пин от карты вместо пароля или логина?
Если и карта и телефон NFC умеют — "приложите карту к телефону и наберите pin".
Если что-то из них этого не умеет — то же самое, но через контактный ридер.
Если на телефоне стоит зловред и он пин перехватил — то ему это мало что дает, т.к. любая операция еще и картой подтверждаться должна. Если же зловред очень злобный и умеет вклиниваться и подменять шифрованный обмен карта<->банк — то это означает, что он приватные ключи банка знает, чтобы MitM для карты устроить и совсем другой уровень проблем.
Если аналогия расходится — то нужно показывать, в чем. Я вот существенной разницы не вижу. Есть служба доставки сообщений. Физических или виртуальных. Она по своей конструкции (кроме очень неудобных к использованию реализаций) должна знать или узнает, какой адрес внутри ее сети с каким коммуницирует, потому что должна эти сообщения доставлять. И должна позволять проверить дошло/может быть доставлено сообщение по такому-то адресу или нет.
Если у человека есть смарт, то у практически наверняка есть учетка либо от Гугла, либо от Apple. В которой есть почта.
Ей и нужно пользоваться в подобных случаях.
Ага. Ту, которая умеет отличать выход бредогенератора от того, что люди считают осмысленным. А потом...
Подаем результат работы живых разработчиков на вход этой новой модели перед тем как Code Review живым человеком делать.
Я подозреваю, что плотность населения ни при чем. Вряд ли этих специалистов вообще нужно много. А причем — это то что этих немногих людей, которые этот процесс настроить могут, буквально по пальцам пересчитать можно на всем шарике, они связана 'пожизненными' (или даже в буквальном смысле пожизненными) контрактами, NDA, запретами работать на конкурентов итд итп.
А этого не понял. Почему копрометирую? В смысле, почему приложение авторизации в этой же карте сильно опаснее, чем в соседней, только для этого предназначенной.
Такое же рассуждение работает и для внедрения чипов в картах. "Если нужно оставить обратную совместимость с магнитной полосой, то зачем вам чип? Уязвимость же останется. Если хочется, давайте отдельную, чисто чипованую карту лучше сделаем"
Одноко этого не произошло, а сами чипы почти повсеместно использовать стали. Правда, мнооого лет прошло.
Я, в общем, согласен, но стандартные токены с нужным функционалом как-то сильно отдельно и неудобно покупать надо, а карты — просто банком выдаются.
Я не верю в биометрию для этих целей. Прежде всего, потому что железку можно уничтожить, после чего никто никуда по ней доступа не получит. А биометрию уничтожить нельзя.
Да. Именно это и следовало бы сделать. Вон, тут целых полторы новых платежных системы разработали и внедрили (МИР+система быстрых платежей) и нечего, как-то живем.
Все таки не понял, почему нельзя сделать саму банковскую карту этим самым вторым фактором (с тем же самым стандартным протоколом, что у отдельного ключа). Ну да, поначалу функционал будет не у всех и нужно будет специально просить такую. Или даже таки отдельный ключ покупать. Но постепенно (они же не вечные) карты сменятся, телефоны с NFC подешевеют, люди обзаведутся ридерами и проблема 'есть не у всех' пропадет.
В данном случае речь идет не о протоколе, что при покупке используется, а о том, который следовало бы использовать (по моему мнению) при авторизации банковского клиента. Какой надо пин, такой и будет. Пусть даже другой. Не вижу в этом проблемы.
Весьма возможно. На ходу же придумывался, без старательных размышлений. Но протоколы, используемые в бизнес-клиентах банков, что с аппаратными токенами работают, уже ведь есть? Они достаточно хорошие?
Почему чип на банковской карте не может делать то же самое, что чип внутри этого токена делает?
В существующией ситуации, когда банк-клиент просто на телефоне стоит, эта непроверенная третья сторона тоже есть. В точности та же самая. Если добавить еще карту, она хотя бы ничего не может сделать, если карты нет поблизости.
Ну и, если уж очень не хочется, чтобы карта какой-то пин помнила, можно весь обмен выше модифицировать так, чтобы переданный карте pin она просто использовала в процессе формирования подписи тикета при авторизации. И пускай уже банк, а не карта, разбирается, правильный он был или нет.
Не совсем. Есть оффлайновый еще, который именно картой проверяться может.
Во первых, это вроде бы ничем не отличается от риска утечки CVV, т.е. мы ситуацию не ухудшаем.
Во вторых, как ключики из чипа карты выковыривать?
Если же имеется в виду клон только по магнитной полосе — то использование такого клона моментально оспаривается.
Приблизительно (этап согласования сессионного ключа для общения с картой опущен, токости протокола — тоже, придумывалось на ходу):
приложение -> карте: Тут пользователь такой пин ввел. OK?
карта->приложению: (увеличивает счетчик неудачных попыток) Нет.
приложение->пользователю: неверный, давай еще раз.
пользователь: повторяет ввод пина.
приложение -> карте: Тут пользователь такой пин ввел. OK?
карта->приложению: Да.
приложение->банку. Тут залогиниться хотят с картой номер..., дай тикет авторизации
банк->приложению: высылает одноразовый тикет
приложение->карте: держи тикет от банка.
карта: проверяет подпись банка, подписывает тикет своим ключем.
карта->приложению: держи подписанный тикет.
Приложение->банку: держи подписанный тикет.
Банк: проверяет подпись карты на тикете и (не)дает доступ к информации о счете.
<через некоторое время, когда пользователь операцию сформировал>
приложение -> карте: Сделай мне подпись на "пакет данных операции"
карта->приложению: подписывает своим ключем и возвращает результат.
приложение->банку: пользователь захотел операцию сделать, вот подписанные данные.
банк: проверяет подпись на операции и (не)делает ее.
Вообще, не понимаю суди возражений. Аппаратные крипто ключи давно и успешно используются в бизнес-вариантах банковских клиентов. Защищаются именно pin-ами. Вот карта — и есть, по сути, такой аппаратный ключ. Который почему-то использовать не хотят.
pin от SIM-ки он сам проверить тоже не может. Что не мешает его вводить и пользоваться. Тут точно так же. Спрашиваем и чипу карты отдаем, чтобы она операции над счетом подтвердила.
Этот телефон уже имеет доступ к управлению банковским счетом — на нем приложение банк-клиента стоит. Какой сценарий атаки добавляется, если мы начнем pin карты спрашивать, а не тот pin, что сейчас это приложение использует?
Уже есть. Причем даже pin не спрашивает, как я предлагал, чтобы что-то со счетом карты сделать.
Осталось заменить софт, предназначенный для продавца софтом, предназначенным для управления банковским счетом.
EDIT: вот еще. Тут pin спросили.
Ридер — он просто ридер. Адаптер интерфейса к чипу карты. Который интерфейс вполне стандартный. С другой стороны — USB. Где я утверждал, что он хоть как-то от кражи защищает — непонятно.
Подключать — к телефону (тут лучше бы, чтобы ридер умел usb host, чтобы otg от смарта не требовать) или компу. Протоколы более высокого уровня, по которому банковское приложение внутри чипа карты с банком общаться будет — это пускай у банка и производителей карты голова болит. Сумели же как-то договориться о протоколах, что в NFC оплате используются.
Предоставлять — как банку хочется. Я бы продавал. Тупой адаптер интерфейса дешевый при массовом производстве.
Ну строчкой выше же написано 'то же самое, но через контактный ридер.'
Если и карта и телефон NFC умеют — "приложите карту к телефону и наберите pin".
Если что-то из них этого не умеет — то же самое, но через контактный ридер.
Если на телефоне стоит зловред и он пин перехватил — то ему это мало что дает, т.к. любая операция еще и картой подтверждаться должна. Если же зловред очень злобный и умеет вклиниваться и подменять шифрованный обмен карта<->банк — то это означает, что он приватные ключи банка знает, чтобы MitM для карты устроить и совсем другой уровень проблем.
Так pin же у карты. Для того и придуман.
Не использовать телефон для авторизации. Для этого банковская карта придумана. Которая pin-ом защищена на случай, если и телефон и карту украли.
Правда тем, у кого либо телефон, либо карта NFC не умеют, придется пользоваться специально придуманным для этого ридером.
Телеграм тоже не говорит.
Если я пошлю письмо по какому-то случайному физическому адресу — я не узнаю, кто там живет, пока в другие базы не полезу.
Точно так же если я постучусь на случайный номер в Телеграм — я тоже ничего не узнаю про того, кто им пользуется, пока в другие базы не полезу.
Если аналогия расходится — то нужно показывать, в чем. Я вот существенной разницы не вижу. Есть служба доставки сообщений. Физических или виртуальных. Она по своей конструкции (кроме очень неудобных к использованию реализаций) должна знать или узнает, какой адрес внутри ее сети с каким коммуницирует, потому что должна эти сообщения доставлять. И должна позволять проверить дошло/может быть доставлено сообщение по такому-то адресу или нет.