HN 用户提问：去中心化身份验证，用于信息交换？
2 分•作者: vxsz•1 天前
我有一个媒体服务器项目想要开发。但我卡在一个问题上，即便利性与隐私之间的权衡。<p>由于这个项目是关于搭建自己的服务器（媒体服务器），我希望有一种更流畅的方式来实现一个简单的账户系统，用户只需输入电子邮件和密码，就能获取服务器/IP列表（从那里开始的所有操作都在实际的服务器上完成）。例如，一个用户可以被邀请到两个服务器，并在同一个页面上看到它们，这使得事情更直接，也更容易。<p>现在，我对此思考了很多，最终得出的结论是，集中化是最合理的选择。数据本身归结为：电子邮件、加密密码、加密IP列表（通过密钥交换）。有没有什么方法可以去中心化地实现呢？我搜索过，甚至问过大型语言模型，但没有找到任何可靠的方案（最好的建议是Nostr），但这种方法会让电子邮件、密码重置变得痛苦或几乎不可能。我对这个话题了解不多，所以这很有挑战性。<p>为什么要这样做/为什么不直接使用URL？为了便利性。我知道，但让父母输入一个URL是很糟糕的，即使对于一些技术朋友来说，沟通起来也需要费一番功夫。我想尽可能地减少摩擦。此外，如果集中化，用户就不需要购买域名、设置Let's Encrypt等等，这会花费金钱和时间（特别是对于简单/新的自托管用户来说）；这样会更好、更流畅，并且在某种程度上提供了更好的开箱即用的隐私保护。<p>注意，这个项目甚至还没有开始。但我很快就会着手开发。我大学时只上过一门加密课程，虽然我理解并且擅长它，但我仍然需要审计/验证我的方法。
它基本上是：
1. 用不同的算法对密码+盐进行哈希处理，保存私钥，并将公钥发送到中央服务器
2. （媒体服务器所有者想要邀请）媒体服务器检查公钥，加密包含所有详细信息（IP、状态、端口等）的消息，并将加密后的消息发送到中央服务器。
3. 客户端稍后检查是否有新消息，解密来自服务器的IP/信息并连接。<p>每个设备都可以通过这种方式登录并安全地获取服务器列表信息。将来会有一种在电视等设备上“快速连接”的方式，以及更改密码的功能，但现在我不想操之过急。我不认为IP/服务器信息加密会受到任何重大问题的困扰，但这是总体的核心原则。我可能（很可能？）遗漏了一些东西。<p>我唯一可能想到的问题是，“集中化”的URL/域名会一直显示，而不是服务器所有者的域名。注意，它将被设计成允许你将用户定向到你自己的URL/域名等。<p>总之，请告诉我什么方案是最好的。顺便说一句，我并不富有，但这样一个简单的“身份验证”服务器可能每月花费5美元+2x5美元用于冗余，应该不会太糟。
查看原文
I have a media server project that I want to work on. But I'm stuck on one thing, convenience vs privacy.<p>As the project is about spinning your own server (media server), I want to have a smoother way to have a simple account system where the user just enters an email and a password, and get the server/ip list (everything from there is done on the actual server). For example, a user could be invited to 2 servers, and would see them in the same page, which makes things more straight-forward and a lot easier.<p>Now, I thought a lot about it, and mostly came down to the conclusion that centralizing it is the most sane option. The data itself comes down to: email, encrypted password, encrypted IP(s) list (via key exchanges).Is there any-way to do it decentralized? I searched, even asked LLMs, but nothing felt solid (best was a Nostr suggestion) but such method would make emails, password resets painful or almost impossible. I don't know a lot regarding this topic so its quite the challenge.<p>What's the point/why not just use URL? convenience. I know, but it SUCKS having to give a parent a URL, even with some techy friends it takes a bit communicating it. I want to eliminate as much friction as possible. Also, if centralized, this has the ability that users don't need to buy a domain, setup lets encrypt and all that which costs money and time (especially for simple/new selfhosters); its a lot nicer and smoother and in a way provide better privacy out-of-the-box.<p>Note, This project doesn't even exist yet. But I'm pursuing quite soon. I also only took 1 encryption course back in college days, while I understood and was good at it, I still need to audit/verify my method.
It basically is:
1. hash the password+salt in a different algorithm, save the private key from it and send the public key to the central server
2. (media server owner wants to invite) the media server checks for a public key, encrypts the message containing all the details (IP, status, ports etc), and sends the encrypted message to the central server.
3. The client later checks, if there's a new message, it decrypts the ip/info from the server and connect.<p>Every device can login in this way and grab server list info securely. There's gonna be some sort of way to "quick connect" on TVs and such, and change passwords, but I don't want to get ahead of myself for now. I don't think the IP/server-info encryption suffers from any major things, but that's the general core principle. I maybe (probably?) have missed something.<p>The only issues I can maybe think of, is a "centralized" URL/domain would be showing up all the time instead of the owner. Note, it would be designed in a way that would allow you to instead send them to your own URL/domain and such.<p>Anyways, let me know what would be best. btw I'm not rich but such simple "auth" server would probably cost like $5/m + 2x5/m for redundancies, shouldn't be too bad.