Topic: Авторизация на сайтах, при помощи биткоин (Read 476 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 клик.

Изначально, речь шла о авторизации на сайтах. Сайты - хостятся на сервере. Потому что архитектура «Клиент — сервер».

Глянь, как устроен и уже давно работает - ZeroNet.
Там сайты на жестких дисках хранятся, доступ к сайту осуществляется по адресу, подобному адресу биткоина.

Глянь, как устроен и уже давно работает - TOX.
Он - p2p и можно общаться без интернета - даже в LAN.
Там тоже генерируются два ключа - приватный и публичный.
Из приватного ключа - получается публичный. Шифрование - асимметричное, при помощи библиотеки NaCl (libsodium).
При этом, в идентификатор пользователя TOX, в его ToxID - входит, отчасти - публичный ключ
(наряду с неким значением NoSpam, которое не знает контакт, которого добавил этот пользователь, и XOR-checksum).
Вот тут можешь потыкать либу js-nacl.

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

Я же говорю Вы думаете старыми категориями. Сервер в идеале нам не нужен, общение должно быть p2p.

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

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

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

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

А что там их писать, эти скрипты?
Работа с цифровыми подписями - уже написана на JavaScript тут исходник.
Это вкладки Sign и Verify в brainwallet.
При этом, для подписи сообщений и проверки цифровой подписи - не нужно держать монеты на балансе.
Просто работает алгоритм ECDSA. Он может работать локально, и без Интернета.

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

---

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

Как вариант, для решения проблемы мультов - могло бы использоваться то же 2FA (двухфакторная аутентификация),
в котором 2FA Security Key - динамический,
и зависит от значения ( hash(client_address) XOR hash(server_privkey) ).
Но это уже отдельный модуль, и да, на стороне сервера.

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

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

По поводу шифрования - не знаю как реализовать, но уже на уме вертится обычное AES-шифрование через SSL/TLS.
Я слышал, есть вроде ещё и ECC, но как оно работает - не колупал.
Там, вроде, точками эллиптической кривой данные кодируются, и из-за этого появляется информационная избыточность.

А вот что касается обмена ключами, да. Идея годная. И её можно реализовать с помощью эллиптической кривой биткоина.
Даже скрипт есть ECDH (Elliptic-Curve Diffie-Hellman): https://github.com/username1565/ECDH
А вот тут, всё это дело доступно онлайн: https://username1565.github.io/ECDH/

Как видишь:
1. Сначала генерируются приватные ключи.
2. Затем - вычисляются публичные ключи, из этих - приватных.
3. После чего, перекрёстное умножение приватного ключа одной стороны на публичный ключ другой стороны -
даёт одну и ту же точку на эллиптической кривой.
4. И эта точка, в последствии, может быть закодирована в hexadecimal value
а дальше уже - использоваться как ключ для симметричного шифрования (например, того же AES).

А вот здесь не совсем понятно. Что значит "среда существования пользователей"?
Как вы хотели бы её изменить?
Для того чтобы каждый пользователь мог банить кого-то, или удалять что-то,
и что-либо читать, а что-либо нет, данные должны выгружаться ему на жёсткий диск, флешку или куда там,
и там уже чтобы он мог распоряжаться этими данными так, как он захочет.
Яркий пример - НАНОБОРДА.
Там выгружаются все посты, а потом каждый из нанонов может их у себя - либо оставлять, либо удалять.

Идея хорошая, плюс ещё и шифрование можно добавить. Ведь такая авторизация позволяет безопасно обмениваться ключами шифрования.

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

1. Владельцем адреса биткоина - является владелец приватного ключа, соответствующего этому адресу.
2. Владелец, как клиент - заходит на сервер.
3. Сервер генерирует ему какое-то значение, и просит его подписать.
4. Клиент, как владелец приватного ключа - подписывает это значение, как сообщение, своим приватным ключём.
5. Клиент - отправляет подписанное сообщение на сервер.
6. Сервер - проверяет цифровую подпись сообщения.
7. Так как сообщение проверено на сервере, серверу доступен адрес подписанта,
более того, сервер уверен в том, что у подписанта этого - есть приватный ключ от этого адреса,
так как значение соответствует отправленому значению.
8. Сервер использует адрес подписанта - как уникальный идентификатор (username).

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

Плюсы: Очень простая аутентификация. Можно реализовать на нескольких скриптах.
Никаких личных данных не нужно вводить в формы всякие, достаточно privkey в LocalStorage прописать,
а цифровую подпись вычислять client-side.

Более того, у WAVES, в waves-lite-client (тут исходник), этот seed гененируется однократно,
а хранится он - в зашифрованном виде, в LocalStorage, и шифруется паролем.
Из него, получается приватный ключ. А это уже, своеобразная защита от мультиаккаунтов.
К тому же, у них есть AUTH-API,
работу которого можно протестировать на сайте https://h2ox.io/ при подвязке WAVES-адреса (если не слать токены им).
Там надо быть залогинненным здесь: https://client.wavesplatform.com/#!/dex-demo

Не, ну реально, надоели эти старые системы регистрации и авторизации,
с кучей полей, всякими галочками (лишь бы пропустило), телефонами, SMS,
требованием зайти в GMAIL, VK, ФСБук (где обычный аноним никогда и не регистрировался).
Email вводить ещё надо, подтверждать на каждом сайте...
А потом ещё могут тупо забанить акк и потребовать KYC.
Почему бы для связи - не использовать вместо email'a - TOX,
Взяв PRIVkey от адреса в качестве privkey NaCl для генерации ToxID,
а связь - проводить онлайн через TOX? Есть же echo-bot на https://toxme.io/
Вот такие боты могли бы туда, в TOX - ссылки слать, как на email.
А всё это дело в одном приложении запилить, возможно даже на JavaScript,
чтобы с сервера прям выдавались скрипты, и на клиенте работали client-side, без всяких утечек данных.

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