Теперь жизнь неотделима от электронных платежей WeChat/Alipay.Когда вы идете поесть или сделать покупки, вам нужно только взять с собой мобильный телефон, чтобы решить все, поэтому я уже давно не прикасался к настоящей вещи.
Однажды я вышла поесть, выстроилась в очередь, чтобы заплатить, и процесс ожидания был очень скучным, я уже собирался вытащить свой мобильный телефон, чтобы сражаться в глуши, но обнаружил, что это место не может даже подключиться к Интернету.
Глядя на мобильный телефон, сигнал полный, но он показывает, что нет подключения к сети.Пользователям мобильных телефонов Apple больно, кто знает, кто им пользуется.
Голос за кадром: Я очень хочу диссить Iphone, который использует базовую полосу Intel, 📶 Это так плохо, сеть будет мигать, когда ничего не происходит~
Возвращаясь к сути, поскольку интернета нет и у меня нет с собой денег, я боюсь, что при оплате я не смогу использовать Alipay для списания денег, потому что в моем мобильном телефоне нет интернета. Когда я думал об этом, я уже был в очереди, Неважно, что три, семь или двадцать один, я должен сначала попробовать это с Alipay.
Но я не ожидал, что, когда продавец использовал скан-код для сканирования кода платежа на Alipay для оплаты, хотя мой мобильный телефон в конечном итоге не открыл страницу успешной оплаты, сторона продавца показала, что платеж прошел успешно, и Чек был успешно распечатан.Через некоторое время я получил дебетовое текстовое сообщение Alipay на свой мобильный телефон.
Поскольку моя недавняя работа связана с WeChat/Alipay, общий процесс оплаты все еще относительно ясен, но не очень понятно, почему платежный код может быть оплачен в автономном режиме, поэтому я провел небольшое исследование, и у меня есть сегодняшняя статья.
Эта статья включена вstudyidea.cn/, нажмите, чтобы просмотреть другие статьи, связанные с платежами
Научно-популярный способ оплаты
Прежде чем говорить об офлайн-принципе платежного кода, давайте сначала познакомим студентов, не знакомых со способами оплаты Alipay/WeChat, с двумя распространенными способами оплаты.
Существует два распространенных способа оплаты для офлайн-платежей WeChat и Alipay. Один из них заключается в том, что мы включаем мобильный телефон и активно сканируем кодовую табличку, предоставленную продавцом. Этот способ оплаты обычно называется платежом основного сканирования (пользователь активно сканирует код ).
Взяв в качестве примера Alipay, процесс оплаты показан на рисунке:
Во-вторых, мы включаем мобильный телефон, отображаем наш платежный код, а затем продавец использует такие инструменты, как сканер кода, чтобы получить платежный код для завершения платежа.Этот способ оплаты обычно называется отсканированным платежом (пользователь сканируется по коду).
Взяв в качестве примера Alipay, процесс оплаты показан на рисунке:
Для первого метода вам необходимо отсканировать код в приложении на мобильном телефоне, а затем подтвердить платеж во всплывающем окне.Этот метод не может завершить платеж, когда мобильный телефон не подключен к сети, поэтому ситуация, о которой мы упоминали выше без сети относится к оплате по коду оплаты.
Платежный код процесс оплаты
Прежде чем говорить об офлайн-оплате с кодом оплаты, давайте взглянем на общий процесс кода оплаты.В качестве примера на примере покупок в супермаркете поток платежной информации для одного кода оплаты показан на рисунке:
В этом процессе фоновая система продавца является интерфейсом платежа Alipay со штрих-кодом, который необходимо вызвать для завершения платежа.
Поскольку серверной части продавца необходимо взаимодействовать с серверной частью Alipay в режиме онлайн, офлайн-оплата платежного кода относится к ситуации, когда у клиента нет сети, а продавец должен быть в сети в режиме реального времени.
Поток вызовов интерфейса одноразового платежного кода представлен на рисунке:
Благодаря двум приведенным выше рисункам у нас есть общее представление о процессе взаимодействия платежного кода.
Техническое решение платежного кода фактически можно разделить на две ситуации: клиент онлайн и офлайн Давайте посмотрим на конкретные методы реализации двух решений.
Схема онлайн-кода
Схема онлайн-кода на стороне клиента должна быть относительно простой.Пока Alipay/WeChat войдет в систему и нажмет кнопку оплаты, клиент вызовет интерфейс платежного кода приложения фоновой системы.
После получения запроса фоновая система генерирует код платежа, затем сохраняет связь между кодом платежа и пользователем в базе данных и возвращает ее клиенту.
Пока клиент отображает код платежа в течение срока действия, платеж может быть завершен, в противном случае срок действия QR-кода истечет.
Использование этой схемы относительно безопасно, поскольку сервер каждый раз генерирует код, сервер может контролировать идемпотентность и отсутствует риск подделки клиента.
Кроме того, даже если необходимо изменить правила кода платежа, например добавить одну цифру кода платежа, нам нужно только настроить код сервера, и клиент не нуждается в обновлении.
Однако очевидны и минусы этого решения: клиент должен быть подключен к сети Интернет в режиме реального времени, при отсутствии сети невозможно получить код платежа.
Кроме того, некоторые смарт-устройства стали поддерживать оплату Alipay, и большая часть этих устройств не подключена к Интернету (Например, Xiaomi Mi Band 4.), в этом случае невозможно использовать схему онлайн-кода.
Исходя из этой ситуации, существует автономная схема кода.
Схема автономного кода
Вы можете быть незнакомы с автономными кодами, но на самом деле, если вы внимательно посмотрите, автономные коды действительно используются во многих сценариях.
Например, когда я заходил в черное интернет-кафе, чтобы поиграть в Fantasy Westward Journey, мой аккаунт всегда был украден.
Ни в коем случае, я потратил много денег, чтобы купить общий заказ NetEase.Каждый раз, когда я захожу, помимо ввода имени пользователя и пароля, мне также нужно вводить динамический пароль. С тех пор учетная запись редко была украдена.
Другой пример: каждый раз, когда мы платим с помощью NetEase, помимо ввода пароля банковской карты, нам также необходимо вводить динамический код на экране онлайн-банкинга, чтобы платеж мог быть завершен.
Голос за кадром:
Я должен снова пожаловаться здесь, щит онлайн-банкинга было действительно трудно использовать, и драйверы были несовместимы на каждом шагу. Я до сих пор помню, как использовал онлайн-банкинг для пополнения желтых бриллиантов, и весь день мне это не удавалось --!
Конечно, они могут быть ужевинтажТеперь многие люди, возможно, не использовали его, и сейчас он более популярен.Мобильное приложение для аутентификации,НапримерGoogle AuthenticatorЖдать.
Этот токенизатор динамически генерирует одноразовые пароли (OTP, One-time Password) для предотвращения угроз безопасности, вызванных кражей пароля.
Собственно, на этой схеме и основан технический прототип кодовой схемы офлайн-платежей, поэтому давайте рассмотрим принцип, основанный на Google Authenticator.
Принцип технологии динамических паролей
Во-первых, если нам нужно использоватьGoogle Authenticator, нам нужно включить функцию двухэтапной аутентификации на сайте.На примере аккаунта Google в месте, где установлена двухэтапная аутентификация, можно найти следующие настройки:
Когда мы нажимаем на настройки, появляется QR-код, а затем используйтеGoogle AuthenticatorПривязка кода сканирования приложения.
После того, как мы свяжемся,Google AuthenticatorПриложение отобразит динамический код.
Давайте разберем этот QR-код, который соответствует следующей строке:
otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google
В приведенной выше строке самое важное — это строка ключей.secret, этоBASE32Закодированная строка, вам нужно использовать ее, когда вы действительно ее используетеBASE32Декодирование, обработка псевдокода происходит следующим образом:
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
Клиент и сервер одновременно сохранят копию этого ключа, и обе стороны будут вычислять один и тот же алгоритм для сравнения корректности динамического кода.
Давайте возьмем клиент в качестве примера для создания динамического кода. Сначала нам нужно пройти через функцию подписи, здесь **Google Authenticator** используетHMAC-SHA1, который представляет собой код проверки сообщения на основе хэша, который может использовать относительно безопасную одностороннюю хеш-функцию (например, SHA1) для создания подписи.
Псевдокод функции подписи выглядит следующим образом:
hmac = SHA1(secret + SHA1(secret + input))
В приведенной выше функцииinputЗначение, которое делится на 30 с текущим временем.
input = CURRENT_UNIX_TIME() / 30
Здесь время действует как параметр динамической переменной, так что динамические коды могут непрерывно генерироваться.
Кроме того, деление на 30 здесь дает проверочному коду срок действия 30 секунд.
Таким образом, для пользовательского ввода достаточно времени для подготовки к вводу динамического кода.Кроме того, может быть разница во времени между клиентом и сервером.Интервал в 30 секунд с большой вероятностью может скрыть эту разницу.
Голос за кадром: Это эффективное время на самом деле является соображением.Если оно больше, безопасность будет плохой.
Если он короче, пользовательский опыт будет плохим, и ввод данных будет непростым.
проходить черезHMAC-SHA1После функции подписи мы получаем строку длиной 40, которую нам также нужно преобразовать в 6-значное число для пользовательского ввода. Псевдокод для обработки выглядит следующим образом:
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
large_integer = INT(four_bytes)
small_integer = large_integer % 1,000,000
Полный псевдокод алгоритма выглядит следующим образом:
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
input = CURRENT_UNIX_TIME() / 30
hmac = SHA1(secret + SHA1(secret + input))
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
large_integer = INT(four_bytes)
small_integer = large_integer % 1,000,000
Когда клиент загружает динамический код на сервер, сервер запрашивает базу данных для получения ключа, соответствующего пользователю, а затем использует тот же алгоритм для его обработки для создания динамического кода и, наконец, сравнивает динамический код, загруженный пользователем. client соответствует тому, что сгенерировано сервером.
Платежный код Автономное решение
О реализации динамических паролей мы узнали выше, и принцип генерации платежного кода примерно такой же.
Однако схема кодов офлайн-платежей использует метод динамического ключа (глобально уникальный), периодически запрашивая у сервера смену ключа для обеспечения большей безопасности.
Кроме того, в схеме одноразовых динамических паролей обе стороны должны основываться на одном и том же секретном ключе, поэтому сервер должен это четко знать.Правильный пользователь позади. Взяв в качестве примера описанный выше сценарий входа в систему, имя пользователя вводится в процессе входа в систему, и в соответствии с этим сервер может запросить соответствующий ключ в базе данных.
Однако в сценарии платежа с кодом платежа процесс платежа может вычесть деньги у соответствующего пользователя только путем передачи кода платежа. Излишне говорить, что строка цифр в этом платежном коде должна содержать соответствующую информацию о пользователе.
Следовательно, соответствующий алгоритм платежного кода будет сложнее, чем динамический код, чтобы можно было эффективно гарантировать безопасность.
Увидев это, мне интересно, хотите ли вы узнать об этом алгоритме?
Ха-ха, шучу, как этот алгоритм может быть в пределах нашей досягаемости.
Мы не знаем основного алгоритма Alipay, но мы можем узнать кое-что из общедоступных схем дизайна других.
Здесь маленький черный брат даст вам жиху нетизен@bell в противоположном направлении ответилАвтономная реализация QR-кода дает вам возможность посмотреть.
Недостатки платежного кода офлайн-кода
Наконец, давайте взглянем на недостатки решения с кодом офлайн-платежей:
Во-первых, корректировка алгоритма негибкая, если соответствующий алгоритм сильно корректируется, может потребоваться апгрейд клиента, а также сервер должен быть совместим с платежными кодами, генерируемыми старым и новым алгоритмами в этот период.
Во-вторых, проблема безопасности: при нормальных обстоятельствах соответствующие ключи не могут быть получены обычными пользователями, но они не могут находиться у людей с намерениями. Они могут использовать вредоносные программы для получения ключей путем рутирования пользователя телефона или джейлбрейка телефона, а затем по желанию генерировать платежные коды.
Увидев это, каждый может переживать за сохранность своих кошельков. Тем не менее, я не думаю, что я слишком беспокоюсь об этом.У Ant Group так много великих богов, они не едят сухой рис.У них должно быть много мер для обеспечения безопасности платежей.
Третья проблема конфликта данных: платежный код, сгенерированный пользователем А, рассчитывается так, чтобы он соответствовал коду пользователя Б. Это то же самое, что и алгоритм хеширования. сгенерировано.
Это привело к первоначальному вычету денег пользователя А, но, в конечном итоге, к вычету денег пользователя Б. Таким образом, это действительно очень улун.Для пользователя B деньги необъяснимо вычитаются.
Но не волнуйтесь, я думаю, что такие вещи все же ниже, чем выигрыш лотерейного билета, поэтому не стоит слишком беспокоиться о таких вещах.
Даже если она будет списана по ошибке, не волнуйтесь, Alipay точно потеряет деньги с клиентами с таким большим объемом.
Наконец
Подводя итог, мы обычно используем платежный код для оплаты, Фактически, принцип заключается в том, что сторона продавца получает платежный код нашего мобильного приложения (на самом деле это набор цифр), а затем вызовите платежный интерфейс Alipay в фоновом режиме, чтобы завершить списание.
В этом процессе фоновая программа на стороне продавца должна быть в сети, но для нашего клиента она может быть в сети или в автономном режиме.
Если наш клиент находится в сети, мы можем отправить код платежа клиенту через сервер.Этот метод более безопасный и гибкий, но в слабой сетевой среде опыт очень плохой.
Если у нашего клиента нет сети, то клиент сгенерирует код платежа по определенному алгоритму, а сервер получит его после соответствующей проверки, подтвердит, какой это пользователь, подтвердит действительность кода и завершит вывод. Этот метод подходит для случая, когда у клиента нет сети, но он относительно негибкий и немного менее безопасный.
Эй, чтобы понять принцип, ты думаешь, это все еще интересно~
В следующий раз, когда вы встанете в очередь, чтобы заплатить, если ваш мобильный телефон не в сети, не беспокойтесь о смущении, достаньте свой мобильный телефон и платите с уверенностью ~
Ссылаться на
Добро пожаловать, чтобы обратить внимание на мою официальную учетную запись: общение программы, ежедневный толчок галантерейных товаров. Если вам интересен мой рекомендуемый контент, вы также можете подписаться на мой блог:studyidea.cn