Авторизация на сайтах, при помощи биткоин

[crypto_trader#43xzEXrP]

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, без всяких утечек данных.

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

[1714032742]

1714032742

[1714032742]

1714032742

[imhoneer]

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

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

[crypto_trader#43xzEXrP]

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

По поводу шифрования - не знаю как реализовать, но уже на уме вертится обычное 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).

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

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

[imhoneer]

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

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

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

[tobby9061]

Идея хорошая НО для ее экплуатации надо написать Спецификации, организовать Демо, сделать либы на js и других языках
и тогда будет использоваться а пока что хорошая мысль и пока хватит!

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, без всяких утечек данных.

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

[crypto_trader#43xzEXrP]

Идея хорошая НО для ее экплуатации надо написать Спецификации, организовать Демо, сделать либы на js и других языках
и тогда будет использоваться а пока что хорошая мысль и пока хватит!

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

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


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

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

[imhoneer]

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

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

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

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

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

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

[crypto_trader#43xzEXrP]

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

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

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

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

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

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

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

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

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

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

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

[tobby9061]

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

[imhoneer]

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

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

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


Ну раз хотите такие сайты, то попробуйте. Я Вот помню такое решение делал для них https://bitcointalk.org/index.php?topic=1988115.msg19796533#msg19796533

[crypto_trader#43xzEXrP]

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

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

[johhnyUA]

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

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

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

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

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

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

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

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

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

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

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

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

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

[crypto_trader#43xzEXrP]

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

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

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

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

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

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

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

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

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

Code:

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

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

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

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

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

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

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

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

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

[johhnyUA]

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

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

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

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

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

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

Code:

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

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

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

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

А теперь впихни эту подпись сюда, например: 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

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

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

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

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

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

Во-вторых, при передаче возможен перехват этих данных третьей стороной,

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

в частности, может быть реализована MITM-атака, даже в случае использования HTTPS.
Ключ должен знать только клиент, и если он его потеряет, то всё.

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

[crypto_trader#43xzEXrP]

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

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

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

Я где-то видел авторизацию через 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, походу.
Да, так оно и есть:

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

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

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

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

Теперь по другим цитатам, быстро пробегусь:

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

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

Как раз таки такое не вводят потому, что анонимность и есть возможность клепать мультов пачками.

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

А теперь впихни эту подпись сюда, например: 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

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

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

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

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

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

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

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

[new_ethnos]

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

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

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

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

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

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

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

[imhoneer]

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

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

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

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

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

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

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

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

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

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

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



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

[johhnyUA]

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

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

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

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

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

Никак, поэтому и регистрация чаще всего по другому происходит.

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

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

Code:

public_key = private_key.get_verifying_key()

Собственно вот подпись сообщения, как можно заметить, аргументами здесь выступает некая строка, message

Code:

signature = private_key.sign_digest( Hash( msg_magic( [color=green]message[/color] ) ), sigencode = ecdsa.util.sigencode_string )

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

Code:

# SECP256k1 is the Bitcoin elliptic curve
sk = ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1) 
vk = sk.get_verifying_key()
sig = sk.sign(b"message")
vk.verify(sig, b"message") # True

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

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

Скорее всего, они уже включены в подпись, но я чё-то не вижу где.

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

[crypto_trader#43xzEXrP]

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

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

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

Конечно подойдут. Только там, в википедии - одна строчка лишь.

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

Скорее всего, они уже включены в подпись, но я чё-то не вижу где.

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

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

Вот в этой строке, можно видеть, что в параметры функции проверки подписи,
помимо самой подписи и текста сообщения - входит address подписанта:

Code:

def verify_message(address, signature, message):

Но этот адрес нужен лишь для сравнения с другим адресом - addr:

Code:

    if address == addr:
        return True

При этом, вторая переменная addr, с которым сравнивается указанный address,
она получается из публичного ключа public_key:

Code:

addr = public_key_to_bc_address(encode_point(public_key, compressed))

А он, в свою очередь - вычисляется из некоей точки Q

Code:

public_key = ecdsa.VerifyingKey.from_public_point( Q, curve = SECP256k1 )

высчитываемой из параметров r (от которого зависит inv_r) и s:

Code:

Q = inv_r * ( s * R + minus_e * G )

Сами же эти параметры r, s (и order) - они уже содержатся в самой цифровой подписи sig:

Code:

r,s = util.sigdecode_string(sig[1:], order)

Точка 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,
и просто выведен, в результате проверки - без какого-либо сравнения.

[johhnyUA]

Так, короче:

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

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

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

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

Code:

addr = public_key_to_bc_address(encode_point(public_key, compressed))
    if address == addr:
        return True
    else:
        return False

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

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

Code:

public_key = ecdsa.VerifyingKey.from_public_point( Q, curve = SECP256k1 )

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