Free TON

TON 2FA. Two-factor authentication for any online business. First mass application for Free TON. Двухфакторная авторизация для любых онлайн бизнесов. Первое массовое применение

TON 2FA. Two-factor authentication for any online business. First mass application for Free TON.

Russian version below.

Author: Woney Fest
Telegram: @moqub
Date: 2021-Jan-28
PDF: 370.2 KB file on MEGA
DOC: 80.9 KB file on MEGA

Short description

This proposal describes the idea of mass deployment of the Free TON infrastructure. This solution will give a result suitable for widespread implementation.

Problem

In fact, personal information and correspondence of users is distributed on the network among different services. Governments of countries seek to obtain illegal access to personal information. At the same time, Internet services use two-factor authentication using the user’s cell phone as a reliable solution for user identification. But this is not the case, because governments control local cellular companies and can intercept SMS. The unique code intercepted by the government in SMS makes it possible to restore access to accounts, channels and user groups, including in the Telegram messenger. The right decision is to abandon the cell phone. It means restoring access to services, but at the same time maintaining a reliable, fast, secure connection between the service and the user. Such a solution is TON 2FA two-factor authorization using the Free TON blockchain.

For those who do not know, what 2FA - basically, it is the transfer confirmation code through the phone.

Decision

The transfer of a unique access code from the Internet service to the user should take place by making a minimum payment to the user with the addition of the code to the encrypted comment.

Thus, the encrypted access code will be transferred to the public Free TON blockchain i.e. it will be available wherever there is the Internet, but only the recipient can read it. In this case, no one will be able to intercept the code the way it can now be done with SMS.

Explanation

In addition to SMS, there are two-factor authorization services that are not directly related to the phone number. For example, Google Authenticator provides variable synchronized codes to both the Internet service and the user. But in this case, the Internet service becomes dependent on the third party organization, its security policy and the potential for this third party to access the Internet service on behalf of and without the knowledge of the user.

Currently, we see how Internet giants selectively restrict users’ access to accounts (facebook, google, youtube), third-party applications (parler) access to their services via api.

SMS and synchronized codes are quite convenient. They work quickly and largely without interruption. They are used by banks to confirm transactions, crypto exchanges to authorize and confirm transactions, and other personalized businesses. To replace the code delivery method with a new one, it should be faster and more secure than the existing code delivery method. In addition, businesses may be forced to switch to a new way of two-factor authentication under pressure from users to improve security and availability.

According to the declared and partially tested characteristics, the Free TON network can provide the required bandwidth and security for the transmission of the two-factor authorization code by making a minimum payment to the user with the addition of the code in the encrypted comment.

For those unfamiliar with the technology of two-factor authorization, I will explain that in order to increase the security of the business, namely to reduce the risk of user refusal from their actions. Business supplements the personalization of the user by including an officially identified and registered device - a telephone - in the process. The phone receives a unique code, by entering which, the user confirms to the business the fact of physical access to the phone at the moment. This means that the user does this personally and of his own free will. This gives the user the opportunity, if necessary, to restore access to the service if he has access to the phone. The downside of a convenient function is the constant deprivation of anonymity and the risk of inability to retain access and personal information from the country’s government.

Two-factor authorization through the Free TON blockchain (TON 2FA) allows Internet services to refuse any methods of user identification other than the wallet number in the blockchain (meaning the address of the smart contract, but the word wallet will be used in what follows). In addition, in certain cases, the Internet service may generally refuse to store any information for authorization, such as password hashes, by going only to the access code transmitted through the blockchain.

Like any payment, transferring a code with a payment in the Free TON network spends funds on the balance of outgoing and incoming wallets. Payment for such a transaction can be made both by the Internet service and by the user in advance. If the business decides that the transaction can be paid for and is beneficial to it, an unconditional minimum payment is made with the transmission of an encrypted message. A business payment can either cover the user’s costs of receiving a message, or be sufficient to send, but not sufficient to receive. I think the last option is the most balanced.

The payment must be less than the wallet deployment price to prevent unreasonable or malicious mass creation of wallets. The most successful solution is not to make a payment to an inactive wallet. For this, the beneficiary’s address must be checked for an active state before payment, and, possibly, a sufficient amount of funds to accept a payment with an access code.

In case of payment for the transaction by the user, they must make a prepayment to the wallet of the Internet service. Thus, unspent balances of users in total can be an additional motivation for businesses in the form of revenue from staking or validation. In case of insufficient balance of the user on the wallet of the Internet service, the user may be shown a message about the need to replenish his account. In addition, the fact that a user has topped up an account on the side of the Internet service will be a kind of confirmation that the address belongs to the user, although this reduces privacy. However, in the future, the fact that the user logs into the Internet service using the code received with the payment will also confirm the ownership of the address to the user. The only difference is in the time of this confirmation.

From a privacy point of view, businesses are encouraged to create a unique outgoing wallet address from which a payment will be made to the user. The same outgoing address will be the user’s personal account on the side of the Internet service. However, this contradicts the idea of ​​generating income from staking unspent balances on users’ balances due to the need to consolidate the balances on the general business wallet and then transfer them to a stake. Such consolidation will tie all outgoing wallet balances of users together. Transfers of small amounts from each wallet-balance to a stake may not be cost-effective. In addition, in the case of staking, the business takes on the risks associated with the return of funds from the stake. Also, the Internet service needs to provide secure storage of access keys to a large number of outgoing wallets.

The decision of a business to use a single outgoing wallet improves control over resources, allows you to receive additional income, but there is a need for secure off-chain (off-chain) storage of information about user balances.

There is a variant of the idea implementation when the user initiates the login to the Internet service using two-factor authorization. The user is the first to transfer to the account of the Internet service, and the service, in response and using the funds received from the user, transfers the entire amount available for refund with the access code in the comments to the payment. Thus, there is no accumulation of funds on the wallet of the Internet service. Only current operations of receiving and returning with an encrypted access code are performed minus network fees. Also, at the discretion of the business, it is possible to charge a commission for providing this functionality.

From the point of view of user privacy, it is not necessary, but it is recommended to create a separate wallet for use in TON 2FA services. The incoming address is not related to the main payments of the user. In addition, to maintain privacy, replenish and activate this wallet from the address of the exchange, crypto-mixer, through a fiat money exchange.

Unfortunately, at the moment, the TON Labs Surf wallet application does not allow working with several wallet addresses in one application at the same time, but progress does not stand still and the community may soon receive this functionality.

Proposal (implementation contest):

  • propose the Telegram service to consider the possibility of transferring the two-factor authorization code through the Free TON blockchain.
  • propose TON Labs to supplement the Surf app functionality with the ability to simultaneously access multiple wallets.
  • propose community partners to implement the TON 2FA implementation in their services.

General description

This proposal can be used to form a description of the competitions by dividing it into two parts - software and visual.

The tasks formulated below can be presented:

  • as two competitions in the Main SG,
  • as separate contests in specialized SGs, Web Design SG and DevEx SG

Proposal (development) ----------------------------

Short description

Development of a service of using TON 2FA (code and application technology) for the server side of the site using php, python, nodejs technologies and possibly others.

Type of contest

Competition

Contest dates

Determined by the SG

Motivation

Mass application of Free TON blockchain technologies to solve the everyday tasks of users that were not initially associated with the community ecosystem. Attracting new users to the community ecosystem by involving them in TON 2FA technology.

General requirements:

An example should include:

-description of the execution environment of the developed code and applied technologies / components / versions in text format,

-requirements for possible, but not tested, runtime environments of the developed code, compatible technologies / components / versions in text format,

-minimum working code posted for public access on github. The code must comply with generally accepted design / formatting standards,

-description of adding (application technology) the developed code to the existing site *,

- Sequence diagram (see Wikipedia) UML *,

- Deployment diagram (see Wikipedia) UML *,

-the authorship of the code must belong to the contestant,

-the components used must be distributed under a free license **,

-others at the discretion of the authors and the SG *.

*-In pdf formats and the source development environment in the amount of developed code and elements with which it interacts

** - it is possible to use commercial components from the runtime environment (commercial engine or framework) if the technology for using TON 2FA in a commercial product is submitted to the contest. In this case, the provision of source or executable code of commercial components is not required.

Specification

Selection criteria and winning conditions:

Determined by the SG

Voting

Determined by the SG

Reward

Determined by the SG

Award to judges

Determined by the SG

Author reward

In case of accepting proposals and organizing a contest described in the proposal, the remuneration of the author of the proposals is 5% of payments to the winners of the contest organized by the SG or a fixed amount at the discretion of the Main SG.

Proposal(design contest) ------------------------

Short description

Development of a branded tag / banner for support or compatibility of an Internet service with TON 2FA technology, similar to existing 3D Secure tags or << see images in pdf attached >>

Type

Contest

Contest dates

Determined by the SG

Motivation

Mass application of Free TON blockchain technologies to solve the everyday tasks of users that were not initially associated with the community ecosystem. Attracting new users to the community ecosystem by involving them in TON 2FA technology.

General requirements

Determined by the SG, may include:

-recommended banner size in png format from 32x32px to 100x200px,

-source files of the development environment (e.g. Photoshop, Illustrator, Corel, etc.),

-color palette…,

-background-transparent,

-banner language - English.

Recommendations

I suggest, not to do limit for contestants for considering the possibility of displaying payment technology options from different sources (see Extended explanation above):

-at the expense of the service,

-at the expense of the user’s prepayment,

-at the expense of the user’s incoming payment.

Possible keywords

PS TON 2FA –Paid by Service TON 2FA

PPU TON 2FA - Prepaid by User TON 2FA

PU TON 2FA - Paid by User TON 2FA

Specification

Evaluation criteria and winning conditions:

Determined by the SG

Voting

Determined by the SG

Reward

Determined by the SG

Award to judges

Determined by the SG

Author reward

In case of accepting proposals and organizing a contest described in the proposal, the remuneration of the author of the proposals is 5% of payments to the winners of the contest organized by the SG or a fixed amount at the discretion of the Main SG.

Conclusion

I wish to thank all of Free TON Russian SMM Sub-governance and especially @ducktalesblock for help in translation this proposal to english. See Free TON Russian SMM blog here

To motivate the translator of the proposal into English - payment in accordance with the current tariffs and from the SMM board.

For everyone, you can thank the author by sending a translation to the address

0:a19bb3f75057490fd24c79f23c784db573bdf17dd75c955565b9ba3d439b5c3a

https://uri.ton.surf/surf/0:a19bb3f75057490fd24c79f23c784db573bdf17dd75c955565b9ba3d439b5c3a

==================================
RUSSIAN VERSION

TON 2FA. Двухфакторная авторизация для любых онлайн бизнесов. Первое массовое применение.

Author: Woney Fest
Telegram: @moqub
Date: 2021-Jan-28
PDF: 370.2 KB file on MEGA
DOC: 80.9 KB file on MEGA

Краткое описание

Настоящее предложение описывает идею массового применения инфраструктуры Free TON и формулирует задачи, решение которых даст результат пригодный для повсеместного внедрения.

Проблема

Фактически персональная информация и переписка пользователей распределена в сети среди разных сервисов. Получить незаконный доступ к персональной информации стремятся правительства стран. При этом интернет-сервисы применяют двухфакторную авторизацию с использованием сотового телефона пользователя как надежное решение идентификации пользователей. Но это не так, потому, что правительства контролируют локальные сотовые компании и могут перехватывать СМС . Уникальный код, перехваченный правительством в СМС дает возможность восстановить доступ к аккаунтам, каналам и группам пользователей, в том числе в мессенджере Telegram. Правильное решение – отказаться от сотового телефона как средства восстановления доступа к сервисам, но при этом сохранить надежную, быструю, безопасную связь между сервисом и пользователем. Такое решение – TON 2FA двухфакторная авторизация с использованием блокчейна Free TON.

Для незнакомых с 2FA – в основном, это передача кода подтверждения через телефон.

Решение

Передача уникального кода доступа от интернет-сервиса к пользователю должна проходить путем выполнения минимального платежа пользователю с добавлением кода в зашифрованный комментарий.

Таким образом, код доступа в зашифрованном виде попадет в публичный блокчейн Free TON т.е. доступный везде где есть интернет, но при этом прочесть его сможет только получатель. В этом случае никто не сможет перехватить код так, как это сейчас можно сделать с СМС.

Расширенное пояснение

Кроме СМС существуют сервисы двухфакторной авторизации не связанные напрямую с номером телефона. Например, Google Authenticator предоставляет переменные синхронизированные коды как интернет-сервису, так и пользователю. Но в этом случае у интернет-сервиса возникает зависимость от сторонней организации, ее политики безопасности и потенциальной возможности доступа этой третей стороны к интернет-сервису от имени и без ведома пользователя.

В настоящее время мы видим как интернет гиганты выборочно ограничивают доступ пользователям к аккаунтам (facebook, google, youtube), сторонним приложениям (parler) доступ к своим сервисам через api.

СМС и синхронизированные коды достаточно удобны. Они работают быстро и в основном без сбоев. Ими пользуются банки для подтверждения транзакций, крипто биржи для авторизации и подтверждения транзакций и прочие персонализированные бизнесы. Для замены способа доставки кода на новый, он должен превосходить по скорости и безопасности существующий способ доставки кода. Кроме того бизнесы могут быть вынуждены перейти на новый способ двухфакторной авторизации под давлением пользователей, требующих повышения безопасности или доступности.

По заявленным и частично протестированным характеристикам сеть Free TON может обеспечить требуемую пропускную способность и безопасность для передачи кода двухфакторной авторизации путем выполнения минимального платежа пользователю с добавлением кода в зашифрованный комментарий.

Для незнакомых с технологией двухфакторной авторизации поясню, что для повышения безопасности бизнеса, а именно для снижения риска отказа пользователя от своих действий, бизнес дополняет персонализацию пользователя включением в процесс официально идентифицированного и зарегистрированного устройства –телефона. На телефон поступает уникальный код, введя который, пользователь подтверждает бизнесу факт физического доступа к телефону в данный момент. Под этим подразумевается, что пользователь это делает лично и по доброй воле. Пользователю же это дает возможность в случае необходимости восстановить доступ к сервису при наличии доступа к телефону. Обратная сторона удобной функции – постоянное лишение анонимности и риск невозможности сохранить доступ и персональную информацию от правительства страны.

Двухфакторная авторизация через блокчейн Free TON (TON 2FA) дает возможность интернет сервисам отказаться от каких либо способов идентификации пользователей кроме как номер кошелька в блокчейне (имеется в виду адрес смарт-контракта, но далее будет использоваться слово кошелек). Кроме того, в определенных случаях, интернет-сервис может вообще отказаться от хранения какой либо информации для авторизации, как то - хэши паролей, перейдя только лишь на код доступа, переданный через блокчейн.

Как любой платеж, передача кода с платежом в сети Free TON расходует средства на балансе исходящего и входящего кошельков. Оплата такой транзакции может быть произведена как интернет-сервисом, так и предварительно пользователем. В случае решения бизнеса, что транзакция им может быть оплачена и выгодна ему, производится безусловный минимальный платеж с передачей шифрованного сообщения. Платеж бизнеса может как покрывать расходы пользователя на прием сообщения, так и быть достаточным для отправки, но недостаточным для приема. Я считаю последний вариант наиболее сбалансированным.

Платеж должен быть меньше цены деплоя кошелька, чтобы предотвратить необоснованное или вредоносное массовое создание кошельков. Наиболее удачное решение – не выполнять платеж на неактивный кошелек. Для этого адрес получателя перед платежом в обязательном порядке должен проверяться на активное состояние, и возможно, достаточное количество средств для приема платежа с кодом доступа.

В случае оплаты транзакции пользователем, им должна быть внесена предоплата на кошелек интернет-сервиса. Таким образом неизрасходованные балансы пользователей суммарно могут быть дополнительной мотивацией бизнесов в виде получения доходов от стейкинга или валидации. В случае недостаточного баланса пользователя на кошельке интернет-сервиса, пользователю может быть показано сообщение о необходимости пополнить его счет. Кроме того, сам факт пополнения пользователем счета на стороне интернет-сервиса будет своего рода подтверждением принадлежности адреса пользователю, хотя это и снижает приватность. Однако в дальнейшем, факт входа пользователя в систему интернет-сервиса с использованием полученного с платежом кода точно так же подтвердит принадлежность адреса пользователю. Разница только во времени этого подтверждения.

С точки зрения приватности, бизнесам рекомендуется создавать уникальный исходящий адрес кошелька, с которого будет производиться платеж пользователю. Этот же исходящий адрес будет являться личным счетом пользователя на стороне интернет-сервиса. Однако это противоречит идее получения дохода от стейкинга неизрасходованных остатков на балансах пользователей по причине необходимости консолидации остатков на общем кошельке бизнеса с последующим переводом в стейк. Такая консолидация свяжет все исходящие кошельки-балансы пользователей воедино. Переводы же небольших сумм с каждого кошелька-баланса в стейк могут быть экономически не эффективны. Кроме того в случае стейкинга бизнес берет на себя риски связанные с возвратом средств из стейка. Так же интернет-сервису необходимо обеспечить безопасное хранение ключей доступа к большому количеству исходящих кошельков.

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

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

С точки зрения приватности пользователя, не обязательно, но рекомендуется создать отдельный кошелек для использования его в сервисах TON 2FA. Входящий адрес не связанный с основными платежами пользователя. Кроме того для сохранения приватности пополнить и активировать этот кошелек с адреса биржи, крипто-миксера, через обменный пункт фиатных денег.

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

Предложения внедрения

Предложить сервису Telegram рассмотреть возможность передачи кода двухфакторной авторизации через блокчейн Free TON.

Предложить компании TON Labs дополнить функционал приложения Surf возможностью одновременного доступа к нескольким кошелькам.

Предложить партнерам сообщества внедрить реализацию TON 2FA в свои сервисы.

Общая информация о предложениях сообществу

Настоящее предложение, может быть использовано для формирования описания конкурсов путем разделения на две части – программную и визуальную.

Сформулированные ниже задачи могут быть представлены:

-как два конкурса в главном правлении,

-как отдельные конкурсы в профильных правлениях, а именно правлении разработчиков и правлении вэб дизайна.

Предложение конкурса 1 (разработка) ----------------------------------

Краткое описание

Разработка примера использования TON 2FA (кода и технологии применения) для серверной стороны сайта на технологиях php, python, nodejs и возможно других.

Тип

Конкурс

Период проведения конкурса

Определяется профильным правлением

Мотивация

Массовое применение технологий блокчейна Free TON для решения повседневных задач пользователей изначально не связанных с экосистемой сообщества. Привлечение новых пользователей в экосистему сообщества путем вовлечения в технологию TON 2FA.

Основные требования

Пример должен включать:

-описание среды исполнения разработанного кода и примененных технологий/компонент/версий в текстовом формате,

-требований к возможным, но не протестированным, средам исполнения разработанного кода, совместимые технологии/компоненты/версии в текстовом формате,

-минимально работающий код размещенный для публичного доступа на github. Код должен соответствовать общепринятым стандартам оформления/форматирования,

-описание добавления (технологии применения) разработанного кода в существующий сайт *,

-диаграмму последовательности (sequence, Sequence diagram - Wikipedia) UML *,

-диаграмму развертывания (deployment, Deployment diagram - Wikipedia) UML *,

-авторство кода должно пренадлежать конрусанту,

-используемые компоненты должны распространяться под свободной лицензией**,

-прочее по усмотрению авторов и правления *.

*‑в форматах pdf и исходной среды разработки в объеме разработанного кода и элементов с которыми он взаимодействует

**‑возможно использование коммерческих компонентов из состава среды исполнения (коммерческого движка или фреймворка) в случае предоставления на конкурс технологии применения TON 2FA в коммерческом продукте. В этом случае предоставление исходного или исполняемого кода коммерческих компонент не требуется.

Спецификация конкурса

Критерии отбора и условия победы

Определяются профильным правлением

Правила голосования

Определяются профильным правлением

Награда

Определяется профильным правлением

Награда судьям

Определяется профильным правлением

Награда автору

В случае принятия предложений и организации конкурсов, описанных в предложении, вознаграждение автора предложений - 5% от выплат победителям организованных правлением конкурсов или фиксированная сумма по усмотрению основного правления.

Предложение 2 (дизайн) ----------------------------------

Краткое описание

Разработка брендированной метки/баннера поддержки или совместимости интернет‑сервиса с технологией TON 2FA, аналогичной существующим меткам 3D Secure или <изображения в pdf>

Тип

Конкурс

Период проведения конкурса

Определяется профильным правлением с учетом и по факту получения результатов, полученных на конкурсе для разработчиков.

Мотивация

Повышение узнаваемости технологии TON 2FA среди не вовлеченных пользователей и их вовлечение в экосистему сообщества. Информирование вовлеченных пользователей о возможности применения TON 2FA.

Основные требования

Определяются профильным правлением, могут включать:

-рекомендуемый размер баннера в формате png от 32х32px до 100х200px,

-исходные файлы среды разработки (напр. Photoshop, Illustrator, Corel итп),

-цветовая палитра…,

-фон-прозрачный,

-язык баннера – английский.

Рекомендации

Предлагаю, но не ограничиваю конкурсантов, рассмотреть возможность отображения вариантов технологии платежей за счет разных источников (см. Расширенное пояснение выше):

-за счет сервиса,

-за счет предоплаты пользователя,

-за счет входящего платежа пользователя.

Возможные ключевые слова

PS TON 2FA –Paid by Service TON 2FA

PPU TON 2FA - Prepaid by User TON 2FA

PU TON 2FA - Paid by User TON 2FA

Спецификация конкурса

Критерии отбора и условия победы

Определяются профильным правлением

Правила голосования

Определяются профильным правлением

Награда

Определяется профильным правлением

Награда судьям

Определяется профильным правлением

Награда автору

В случае принятия предложений и организации конкурсов, описанных в предложении, вознаграждение автора предложений - 5% от выплат победителям организованных правлением конкурсов или фиксированная сумма по усмотрению основного правления.

Заключение

Хочу поблагодарить весь Free TON Russian SMM Sub-governance и особенно @ducktalesblock за помощь в переводе этого предложения на английский. Читайте Free TON Russian SMM blog здесь

Для мотивации переводчика предложения на английский язык – выплата в соответствии с действующими тарифами и из средств правления SMM.

Для всех желающих, вы можете поблагодарить автора, послав перевод на адрес
0:a19bb3f75057490fd24c79f23c784db573bdf17dd75c955565b9ba3d439b5c3a
https://uri.ton.surf/surf/0:a19bb3f75057490fd24c79f23c784db573bdf17dd75c955565b9ba3d439b5c3a

8 Likes

Like it. However questionable is who has to pay for gas: service provider or service consumer, if at all. Because there is some massive attack potential for sucking tokens from service provider into validators nirvana.

Updated - english version added

Now english version added. Please find “Payment for such a transaction can be made both by the Internet service and by the user in advance.” in text. My thoughts written there and next 2 paragraphs.

Кажется что название 2FA не очень хорошее. Такой же способ аутентификации хотелось бы использовать как один и единственный фактор при логине на не критичных сайтах. Например магазин мерча. Кажется стоит придумать название аутнтификации на подоби OTP(One Time Password) или OAuth, как пример может быть TON Auth?

Мне показалось наоборот, устоявшийся термин, от которого можно получить перенос доверия на TON. А так, конечно можно рассмотреть любой не занятый вариант

Please write comments if You like or dislike this proposal. I’m interested in Your opinion.