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

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

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

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