Topic: Авторизация на сайтах, при помощи биткоин (Read 430 times)

А ты уверен что кривая ed25519 позволяет восстанавливать публичный ключ таким образом? Я напомню, что к примеру в RSA это невозможно (по телу сообщения и подписи. в PGP можно только KEY ID найти таким образом, но это не публичный ключ) именно так (там надо как минимум две пары сообщение-подпись) а DSA вообще невозможно никак.

Я в этот вопрос немного углубился, и могусказать следующее: большинство эллиптических кривых позволяют восстанавливать публичный ключ таким образом, через подпись тело и вид кривой. Но большинство это не все. Насчет Монеро есть сомнения.

В общем-то, эти три параметра можно определить по формату подписанного сообщения. Например, если речь о Bitcoin или Ethereum, то эллиптической кривой будет secp256k1 (разумеется, с различными методами хеширования публичного ключа). Если же речь о Monero, то кривая будет ed25519, и так далее.

---

Насчёт ранжирования участников верно отмечено. Это похоже на публикацию своих PGP-ключей на тематических сайтах, которые пользователи сами выкладывают для последующей идентификации и авторизации при утере контроля над аккаунтом. Но следует заметить, что в PGP по умолчанию используется асимметричная криптография RSA, а не ECDSA.

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

А вот для такова вида сайтов с выплатой денег, это некоторая проблема, но она решается майнингом.

Вы помните, как появился майнинг, это началось с того что, начали бороться со спамерами путем несложных вычислений.

Так и в кране, надо что-то такое придумать.

Но сейчас надо помнить и о армии индусов, китайцев и школьников которые разгадывают капчи.

Большое количество аков может и не создавать трудностей в открытой системе, при наличии системы ранжирования. Например, сейчас любой сайт может нагенерировать миллиард страниц. Но только эти страницы не попадут в поисковую выдачу. Поэтому пропадает смысл в такой генерации. Аналогично и с аккаунтами. Посты (или другой контент) от аков с нулевым рейтингом (трастом) могут просто не отображаться в списке, или быть на 100500 странице. Тоже самое и в различных системах голосования и оценки контента - вес разных аков может отличаться от 0 до 1000000.

Ну, речь вообще-то шла о регистрации-авторизации на обычных сайтах.
И да, что, если сайтом этим будет что-то вроде такого вот bitcoin-крана: https://freebitco.in/ ?
Очевидно, что регистрируя там миллиард мультиаккаунтов, можно очевиднейшим образом - получать по миллиарду выплат.
В общем мульты тут по-любасу - надо будет отсеивать как-то, нутыпонял.
Вот я и предложил подписывать новосгенерированным приватным ключём - личные данные.
Не обязательно личные, важно чтобы это было нечто уникальное для каждого пользователя, и нечто, его и только его.
Например, номер телефона, или хэш паспортных данных, который даже можно будет проверить потом,
просто запросив у юзера - его паспорт.

Так а чем они конкретно будут мешать.

Если это дисковое пространство, то решение это каждый пользователь пусть хранит свое.

Если это покупка продажа, то какая разница, если аккаунт деньги платит.

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

Ну это уже без меня  

Я вот говорю две вещи: возможность авторизации через ключевую пару (не обязательно биткоин) существует с момента создания ассиметричной криптографии. Людям в голову такой вариант использования сразу пришел.

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

Вторая вещь, это даже если мы придем здесь к консенсусу (я например не считаю идею плохой, а наоборот - довольно здравой) в мире это ничего не поменяет. Так как я не СЕО Гугла или Амазон-а. Вот и все.

Идея хороша, реализации не будет, скорее всего в ближайшем будущем (иначе она бы была еще в 90е, когда интернет был юн)

EDIT: Кстати да, к твоей идее. Я в своем том посте немного криво объяснил, но извлекать публичный ключ из сигнатуры можно только зная саму подпись + тело сообщения + вид использованой кривой. Это может добавить лишнего геммора для аутентификации. Сервер должен отправить сообщение, сохранить его, получить подпись и тогда уже работать (в итоге он получит два публичных ключа, один из которых наш искуемый)

Ну ладно, с публичным ключём внутри подписи - всё понятно...

---

А теперь, давай рассмотрим аспект мультиакков...

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

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

Но всё-же, продолжим рассматривать номер паспорта...

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

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

Но паспорт - это слишком уж личные данные!
Их могут даже продавать админы скамных недобирж и прочих централизованных параш - в каком-нибудь неведомом даркнете, среди киллеров.

Поэтому, уникальной строкой, идентифицирующей пользователя - мог бы быть тот же
номер телефона например, или email, для связи или... Да тот же - TOXID!

Таким образом, для генерации нового мультиаккаунта, юзеру необходимо будет создать ещё один TOXID (что не проблема),
ещё один email (а это - уже сложнее),
или купить ещё одну SIM-карту (что довольно таки накладно),
и да, это будет уже совсем другой пользователь!

Тем не менее, ничто не мешает:
нагенерировать миллиард TOXID'ов,
зарегистрировать миллиард email'ов,
а вот миллиард SIM-карт - уже вряд-ли накупишь...
Ведь их ещё и содержать надо, и продлевать срок действия их...
Но были, я помню, виртуальные номера...

Однако, в случае продаж контактных данных, вроде баз с теми же - номерами телефонов,
солгаситесь, пользователям зарегистрировавшимся,
не очень хотелось бы видеть - всякие рекламные SMS-ки от всяких мудил,
купивших базы с номерами, даже в своих тилибонах,
не то что в закриптованном p2p - TOX'e.

Но телефон, и TOX - это разве что варианты прямой связи с клиентами,
ведь термин KYC, дословно переводится как know your customer,
то есть Знай своего клиента.
Другими словами - имей возможность связаться с клиентом своим,
и запросить дополнительную проверку у него,
какую-нибудь фотку у него, или видео, или селфи с паспортом в руке,
чтобы убедиться, что это не бот какой-то, и не мульт,
и не подставное лицо, а реальный чел, причём тот самый, который ИЗНАЧАЛЬНО был зареглен,
а не тот, кто в последствии уже - спёр пароли и ключи доступа,
и что-то хочет ещё, после всего этого...
Всё, на благо клиента, а не чтобы заскамить его, и не дать вывести, на скамной недобирже - ЕГО ЖЕ БАБЛО - без KYC.

Кстати, в том же TOX'e возможно проведение и видеотрансляции,
не говоря уже о том, что можно скинуть и фотку там, в виде файла.  

Но, добавлю, что я ненавижу KYC за то, что это открывает пути для манипуляций и всяких спекуляций - оффлайн.
Например, ничто не мешает УСПЕШНО применять
методы социальной инженерии
к человеку, тихо сидящему ВОН В ТОМ БАРЧИКЕ,
и у которого чуть ли не на лбу написано "100 BTC".

Так, короче:

Конкретно из подписи кривой secp256k1 можно извлечь публичный ключ НО:

Это считается плохим способом, так как не все даже эллиптические кривые (не то, что алгоритмы ассиметричного шифрования) позволяют такое проворачивать.

Поэтому, фундаментально, прав я - без публичного ключа (который отсылается/публикуется отдельно) - никак.
Но конкретно к Биткоину и Эфиру это не особо важно, так как конкретно у них можно извлекать публичный ключ (а следовательно и адрес) из подписи

Поэтому, когда мы предоставляем address + signature + message, то это скорее для удобства восприятия, чтобы не нужно было самому сравнивать адреса.


Вот оно, сверка по адресам. По тому, который предоставил человек и по тому, который высчитала функция из подписи.

Точка Q это никакой не сертификат (ну додуматься же можно, хех), это обычная точка (чем кстати тот же публичный ключ и является - точкой отложенной от второй точки, приватного ключа на некую константу G ), которая используется в функции для вычисления публичного ключа из подписи


Тоесть, это внутрипрограммный код, не более. Сертификат это вообще другое. Вот -Сертификат

То, что цифровые подписи можно использовать для аутентификации, это понятно, но разве что - интуитивно.
Конечно же, интересуют схемы или реализации, а лучше - код.
Пока, на данный момент, лучшее что я нашёл - это WAVES AUTH API,
которое работает при попытке подвязать WAVES-адрес на кране H2OX.io
Конечно подойдут. Только там, в википедии - одна строчка лишь.

---

А теперь, смотри сюда...

Вот в этой строке, можно видеть, что в параметры функции проверки подписи,
помимо самой подписи и текста сообщения - входит address подписанта:
Но этот адрес нужен лишь для сравнения с другим адресом - addr:
При этом, вторая переменная addr, с которым сравнивается указанный address,
она получается из публичного ключа public_key:
А он, в свою очередь - вычисляется из некоей точки Q
высчитываемой из параметров r (от которого зависит inv_r) и s:
Сами же эти параметры r, s (и order) - они уже содержатся в самой цифровой подписи sig:

Точка Q, очень похожа, на описанный тобой сертификат,
так как при получении публичного ключа public_key,
из неё - указывается не только алгоритм ecdsa,
но и сама эллиптическая кривая SECP256k1 (ну потому что их куча там, этих кривых).

Таким образом, public_key, а значит и addr (как ripemd160 sha256-хэша pub) -
они уже содержится в цифровой подписи sig, правда - косвенно, и передаются - вместе с ней.
Поэтому, public_key и addr, они могут быть извлечены - только лишь из неё, из подписи sig.
Сам же address подписанта сообщения (даже не pub) - он передаётся отдельно, в теле сообщения,
и нужен разве что - только для сравнения с ним, вычисленного из подписи sig - значения addr.
Но если не указать address, в теле сообщения,
то проверка всё-равно может пройти
(в том смысле, что public_key - всё-равно извлекается из подписи sig).

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

А DSA и RSA видимо не подойдут?

Вот, даже на Вики в статье один из возможных способов применения - Click


Все понятно, как я и говорил:
Идет получение публичного ключа (с приватного можно получить публичный, наоборот - нельзя)
Собственно вот подпись сообщения, как можно заметить, аргументами здесь выступает некая строка, message

Дальше там указывается адрес, и в принципе все. Вот тебе более короткий и понятный код:

Идет генерация закрытого ключа sk (signing key), с него получаем открытый ключ vk (verifying key), проводим подпись sig с помощью закрытого ключа а верифицируем с помощью открытого.

Открытый ключ всегда передается отдельно, сертификатом где помимо ключа указано какой алгоритм (ECDSA, RSA, DSA или что-то другое) использовался.


Как можно заметить выше - нет. Да это и по логике видно, подпись == шифрование. Если ты зашифруешь что-то ключиком который только закрывает, то получить это что-то без ключика который открывает нельзя. А если ты этот ключик который открывает положил в сундучок, а потом закрыл ключом который закрывает, то все.

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

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

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

Такие социальные метки, как лайки, количество друзей, количество участников в теме и прочие не должны отображаться. На Вас не должно оказываться психологического воздействия. Можно использовать микропожертвования, когда Вы ставите лайк и он виден только Вам и хозяину темы, а человеку пересылается определенная небольшая сумма.

Именно уже из такого формата взаимодействия пользователей, надо и думать, как упорядовачивать и представлять информацию.




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

Если хозяин темы хочет поддерживать актуальность темы, то он будет держать сервер включенным круглые сутки. Вон сайты есть на серверах и работают круглые сутки, проблем нет. Так и здесь, можно у себя, а можно на сервере.

Ему пересылаются все ответы пользователей и там вносятся изменения в исходный файл, можно использовать режим премодерации или пост модерацию уже написанных ответов.

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



Понятно, что это лишь один из основных форматов взаимодействия. Если мы возьмем обсуждения видео или музыки, то там что-то должно быть другое, плюс защита авторских прав (вернее метка первоначального появления). Но обязательно должна быть синергия дискуссий, а не разъединять пользователей по своим страничкам и группам.

Авторизация по цифровой подписи - отличная идея! Имхо, очевидная (тоже к этому давненько пришёл) и необходимая для децентрализованной среды.

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

Также в блокчейне (любом, в том числе биткоина) можно регистрировать и идентификаторы пользователя (вида [email protected], например) с привязкой к цифровой подписи. Ссылаться на такие идентификаторы и оставлять в качестве контактов намного удобнее чем строки формата биткоин адреса.


В каком виде по вашему должна выкладываться такая информация? На мой взгляд простое и универсальное решение - это набор xml файлов, в которых данные представлены в едином формате и доступны для парсинга любыми программами. Профайлы пользователей можно например описывать в онтологии FOAF.



Если каждый свои статьи/посты будет размещать на своём компьютере, то при ситуации когда общение идёт между сотнями и тысячами людей - существенная часть данных (постов) будет недоступна в конкретный момент времени, так как не могут все пользовательские компьютеры быть всегда доступными. А держать каждому у себя на компьютеры все данные сети - практически нереально, также как хранить весь интернет. Поэтому классический принцип постоянно доступных серверов с данными более практичен.

Ну, потому что мы в крипте. А внутренний ресурс сайта, могут в любой момент - подменить.

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

Я где-то видел авторизацию через MetaMask, по-моему на https://idex.market/ .
Там, короче, такая схема:
1. Ставишь разширение к браузеру, под названием MetaMask.
2. Вводишь туда приватный ключ, шифруешь его паролем, расширение получает из приватного ключа адрес эфира,
и проверяет баланс эфира и токено на сайте https://etherscan.io/ через API.
3. Балансы эти оно выводит и через это расширение можно перевести токены и эфир,
и при этом - расширение подписывает транзакции зашифрованным внутри - приватным ключём.
4. Подпись доступна не только для транзакций, но и для сообщений.
5. Когда я заходил на https://idex.market там можно было просто импортировать privkey чтобы зайти,
но это стрёмно как-то импортировать ключ в сторонний сайт,
а можно было ещё - просто выбрать MetaMask, и покуда privkey уже есть там,
и хранится он локально, в зашифрванном виде, то так - безопаснее.
Безопаснее, в том плане, что этот privkey не надо вводить никуда, а значит - никто его не стыбрит,
никакой админчег централизованного сервера, хотя сама биржа https://idex.market/ - это DEX, походу.
Да, так оно и есть:
Но дело не в этом, а в том, что там авторизация работает через цифровые подписи.
И когда я в чате вводил ник там - в браузере всплывало окно с просьбой подтвердить подписание сообщения от биржи - через MetaMask,
либо отклонить это действие.
Как только подписываешь это сообщение - оно отправляется на сервер, сервер проверяет подпись,
и тогда вводится никнейм (если он уникальный и не зарезервирован никем, в чате).
И тогда уже - можно постить в чат что угодно, и этот ник привязан к адресу.

Ну, а что касается анонимности...
Где-то, у какого-то альткоина, я ещё видел block-explorer, где в разделе richlist - просто адреса.
Так вот, там можно было задать никнейм для адреса - схема та же:
1. Сервер генерирует рандом, шлёт его и просит подписать.
2. Подписываешь, вводишь подпись цифровую, сервер проверяет её и сравнивает с адресом.
Достаточно было просто ввести строку цифровой подписи, чтобы она была проверена,
и только тогда к адресу в rich-list'е - цеплялся введённый пользоватеем никнейм.
Можно с лёгкостью понять что происходило на стороне сервера:
Сервер проверял подпись, извлекал с неё адрес (а это всё есть в открытом исходнике монеты),
дальше, если адрес соответствует адресу из рич-листа, к которому цепляется никнейм,
значит этот владелец адреса подписал сообщение.
Более того, у него есть приватный ключ, он живой, и вот он - хочет ввести никнейм.
Действие - производится успешно. Никто другой, кроме владельца, не смог бы ввести никнейм, и просто висел бы анонимный адрес.

Идём дальше...
Зайдём-ка на https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7#comments
Там можно оставить коммент, но требуется авторизация через различные централизованные сервисы.
А я, где-то видел подобное, но на приватных ключах. Не помню какой альткоин. Что-то вроде анонимной соцсети.
Там были имена, привязанные к адресам, и после цифровой подписи - можно было постить комменты от имени,
или вроде-как там была система, позволяющая оставлять голоса "круто" или "фигня", и коммент.

Теперь по другим цитатам, быстро пробегусь:
Интересно. Дай ссылку на исходники, где используется - именно ECDSA.

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

Вот тут глянь, передаётся ли в самой строке подписи public-key, или адрес подписанта. А то там не очень понятно как-то.
Скорее всего, они уже включены в подпись, но я чё-то не вижу где.

Ничего. На самом сервере сайта можно же - что угодно подменить.

Если там, в подписи pub, а не адрес, то да, ECDH тут как нигде кстати.
Это затруднило, если не исключило бы подобную MITM-атаку, которую ты описал здесь.

Очевидно что. Но тогда зачем нам именно авторизация через криптовалюты, а не через внутренний ресурс сайта?
Как раз таки такое не вводят потому, что анонимность и есть возможность клепать мультов пачками.



Хорошо, опять вопрос: зачем тогда здесь криптовалюты? Аутентификация на основе ключевых пар и так давно уже придумана была, где то в конце 80х, ты немного опоздал.

Или тебе кажется что здесь сидят главы Гугл, Амазон и прочих, и ты такой "А давайте делать так" и мы такие "Ну давай" и сразу все поменялось?



А теперь впихни эту подпись сюда, например: https://reinproject.org/bitcoin-signature-tool/ и получишь "Message verified to be from (address wasn't specified)"

А здесь и здесь вообще надо адрес и само тело сообщения (ну тело по сути не нужно, чтобы узнать кто подписывал)
- https://btc.coin.space/messages/verify
- https://github.com/gregorvolkmann/coinig.com

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

Поэтому, сама ЕЦП чаще всего не содержит никакой информации, кроме (по сути) зашифрованного (читай подписаного) сообщения. А вот какая хэш функция использовалась (ты же должен знать каким алгоритмом расшифровывать) и необходимый ключ чаще всего рассылает отдельно. И называется сертификат


Что мешает генерировать клиент сайд?
Что мешает подменить публичный адрес и также обломать тебе работу на сайте?

Мы здесь вроде бы не говорим о финансовых организациях, там все равно без паспорта и морды никакой другой аутентификации не будет. А вроде бы говорим об обычных сайтах.


Опять таки, клиент сайд генерация и нет проблем.


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

Я так изначально и предполагал, поэтому я и написал внизу первого поста о том,
что сами биткоины - не нужны для использования цифровой подписи.
Биткоин-адрес, именно от кошелька bitcoin-core - тоже как таковой не нужен. Не нужно его дампить и куда-то вводить.
Это может быть любой альткоин-адрес. Да и это не обязательно.
Ведь в адресе, важна здесь - сама уникальность его, как идентификатора для пользователя (он же и есть адрес),
ну и соответствие идентификатора - какому-то пользователю (по ассоциативной хэш-таблице, на сервере, например).
И альткоин для этого отдельный, делать не надо. Вообще блокчейн не нужен. Даже Base58Check не обязательно, и WIF-формат.
Просто работает ECDSA.

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

Ну вот смотри, тут адрес не указан:
Однако если вставить это сообщение сюда, то адрес - он извлекается из цифровой подписи.


Ну, я уже писал, что не обязательно использовать приватные ключи и адреса именно биткоина,
и именно те, на которых что-то лежит. Монеты держать на адресах вообще не обязательно.
Не обязательно вообще использовать WIF и кодировку Base58Check.
Ведь приватные и публичные ключи - это функционал алгоритма ECDSA.
Но так как мы на bitcointalk, и так как многие используют биткоин,
то наверняка какого-нибудь скрипта или либы, вроде bitcoinsig.js
было бы достаточно для реализации такой авторизации,
более того, если бы повсеместно она использвалась,
то прикинь какой пиар был бы - для самого биткоина

А вот это глупо.
Во-первых, сервер будет знать приватный ключ, а значит, наверняка, и админчег сервака, и/или хацкеры залезшие туда, байты подменять.
Во-вторых, при передаче возможен перехват этих данных третьей стороной,
в частности, может быть реализована MITM-атака, даже в случае использования HTTPS.
Ключ должен знать только клиент, и если он его потеряет, то всё.

---

В идеале, схему регистрации-авторизации я представляю себе так...
Есть две кнопки "Регистрация", и "Вход в аккаунт".

Регистрация - генерация аккаунта.
1. Юзер впервые заходит на сайт и нажимает кнопку "Регистрация".
2. Там - два варианта. Либо "Создать новый аккаунт" (генерация), либо "Импортирвать существующий" (импорт).
3. Юзер выбирает первый вариант - "генерацию".
4. Сервер вгружает ему скрипты для генерации адреса и подписи сообщений.
5. Юзер вводит username/password. При вводе username - сервер проверяет username на уникальность.
Если username уникальный, и такого нет на сервере, то проверяется пароль. Ну, чтобы криптостойкий был.
username - отправляется на сервер, и сохраняется на сервере, в ответ, сервер генерирует рандом для подписи, и тоже его сохраняет.
6. Затем даётся команда на локальную генерацию ключа и адреса, на стороне клиента.
При этом, скрипт генерирует ему private key, получает с него адрес,
тут же - конвертирует privkey в seed (здесь есть легко-запоминающаяся кодировка "poetry"), и просит пользователя записать seed.
Seed этот - сохраняется в LocalStorage, в браузере клиента - и шифруется криптостойким паролем.
7. После этого, опять же, локально, на стороне клиента - подписывается рандом, выданный сервером,
и подписанное сообщение - отправляется на сервер. Сервер проверяет подпись, сравнивает рандом в тексте подписанного сообщения со сгенерированным рандомом, и выданным клиенту. В случае успешной проверки цифровой подписи,
сервер на выходе имеет сгенерированный адрес клиента.
Этот адрес сервер пишет - в ассоциативную хэш-таблицу, связывая его с username.

Авторизация.
1. Юзер пытается войти, и нажимает кнопку "Вход в аккаунт".
2. В cookies висит его username, в LocalStorage - зашифрованный паролем seed.
3. Юзер просто вводит пароль, и входит в аккаунт. После ввода пароля - расшифровывается seed,
и юзер уже может, через цифровую подпись и проверку её - может работать с сервером от имени его usernamе,
привязаному на сервере - к адресу подписанта сообщений.

Импорт аккаунта.
1. Предположим, юзер зачистил cookies и LocalStorage.
2. Юзер пытается зарегистрировать аккаунт снова. Он нажимает "Регистрация", но вместо генерации аккаунта - "Импортирвать существующий".
3. Сервер выгружает всё те же скрипты для генерации адреса.
4. Но вместо генерации, он просто вводит записанный у него ранее, seed, и импортирует существующий аккаунт.

Этот же вариант может быть доступен, если юзер вводит username,
но этот username - не уникален, и на сервере уже есть ассоциативная запись его с каким-либо адресом.
Тогда, сервер может показать ему огрызок адреса, ассоциированного с username (или даже весь адрес),
и возможно юзер сразу же вспомнит о том, где лежит его seed от этого адреса.

Иначе - можно регистрировать только другой username. И если seed утерян, то доступ к старому - утерян навсегда.

---

Вообще, всё это уже реализовано в waves-client и waves-lite-client.
Но как оно работает - мало кто знает,
и вряд-ли сможет реализовать подобное у себя на сайте,
а уж тем более стандартизировать всё это дело - для повсеместного внедрения.
Поэтому лепят всякие формы c кучей полей, и просят потом KYC, телефоны подвязывать,
мордой на камеру светить, и всякое такое,
даже где-то видел верификацию адреса,
где письмо по реальной почте приходит и надо код потом ввести с бумаги...

Просто чудесно, где то на уровне трамваев на Эфире и сисек на блокчейне.
Объясняю:


Здесь две проблемы: лень и безопастность. И они взаимосвязанны.
Не будешь же ты вводить приватный ключ в поле, которое любезно предоставит сайт, правда? Значит надо лезть в Core/Electrum/blockchain.info чтобы это сообщение подписать, а это лишний геммор. Это если мы не говорим что у человека аппаратный кошелек, тогда уровень геммора "достать из заначки Трезор - подключить его к компу - подписать сообщение" вообще зашкаливает.
Соответствовать полной безопастности даже мне лень будет (ради говно авторизации на сайте), следовательно, зачем пляски с блокчейном, если сайт может сделать так:

1. Сгенерировать ключ для пользователя, попросить его сохранить, так как это важно
2. Попросить подписать сообщение.

Ну типа зачем здесь биткоин или очередной говно форк, если можно это делать внутренними силами сайта?


Клиенту лень и клиент посылает сервер нахуй.


Что? Пока клиент не предоставит публичный ключ/адрес подпись ты никак не проверишь по сути. Приватный ключ шифрует (суть ЕЦП), и шифр без публичного ключа не имеет никакого смысла.



То еще новшество. Думаю это сделает революцию в интернет аутентификации, бегом получать патент.

Ага, очень "простая". Зачем здесь именно биткоин, если серверу проще самому генерировать ключевую пару и выдавать ее клиенту?

У TOX'a нет центрального сервера, это p2p сеть.
Но есть сервисы ToxDNS, вроде https://toxme.io/
Да, такие сервисы - имеют центр, в виде серверов,
но они имеют открытый исходник, и могут быть подняты на любом хосте.
Нужны они для того, чтобы длинный ToxID контакта - кодировать коротким,
уникальным и легко-запоминающемся именем, вроде user_vasya.

Да ZeroNet интересен, спасибо. А вот TOX не помню чем не понравился, как минимум он у меня глючил, но там все равно структура использующая центральный сервер есть.


Ну раз хотите такие сайты, то попробуйте. Я Вот помню такое решение делал для них https://bitcointalksearch.org/topic/m.19796533

неплохо было бы сделать демо в которой все работает в 1 клик.