Quote from: johhnyUA on August 03, 2019, 12:15:06 PM

Quote from: crypto_trader#43xzEXrP on July 28, 2019, 04:15:05 PM

1. Владельцем адреса биткоина - является владелец приватного ключа, соответствующего этому адресу.
2. Владелец, как клиент - заходит на сервер.
3. Сервер генерирует ему какое-то значение, и просит его подписать.

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

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

Quote from: johhnyUA on August 03, 2019, 12:15:06 PM

Quote from: crypto_trader#43xzEXrP on July 28, 2019, 04:15:05 PM

4. Клиент, как владелец приватного ключа - подписывает это значение, как сообщение, своим приватным ключём.
5. Клиент - отправляет подписанное сообщение на сервер.

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

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

Quote from: johhnyUA on August 03, 2019, 12:15:06 PM

Quote from: crypto_trader#43xzEXrP on July 28, 2019, 04:15:05 PM

7. Так как сообщение проверено на сервере, серверу доступен адрес подписанта

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

Ну вот смотри, тут адрес не указан:

Code:

-----BEGIN BITCOIN MESSAGE-----
Comment: Signed by Bitcoin Armory v0.93.1

G+Nsln9uxFzy0320TCUS7StLw91Q/k18/XPTun7gP7DsWhlVHluT4rF2ITZJNLdy
Bdef2Jb7wN1WHLSZ7L1W5iRUaGlzIGlzIGFuIGV4YW1wbGUgb2YgYSBzaWduZWQg
bWVzc2FnZS4=
=VoOD
-----END BITCOIN MESSAGE-----

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

Quote

Message verified to be from 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (address wasn't specified)

Quote from: johhnyUA on August 03, 2019, 12:15:06 PM

Quote from: crypto_trader#43xzEXrP on July 28, 2019, 04:15:05 PM

8. Сервер использует адрес подписанта - как уникальный идентификатор (username).

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

Quote from: crypto_trader#43xzEXrP on July 28, 2019, 04:15:05 PM

Плюсы: Очень простая аутентификация. Можно реализовать на нескольких скриптах.

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

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

Quote from: johhnyUA on August 03, 2019, 12:15:06 PM

серверу проще самому генерировать ключевую пару и выдавать ее клиенту

А вот это глупо.
Во-первых, сервер будет знать приватный ключ, а значит, наверняка, и админчег сервака, и/или хацкеры залезшие туда, байты подменять.
Во-вторых, при передаче возможен перехват этих данных третьей стороной,
в частности, может быть реализована 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, телефоны подвязывать,
мордой на камеру светить, и всякое такое,
даже где-то видел верификацию адреса,
где письмо по реальной почте приходит и надо код потом ввести с бумаги...