一种无需密码的开放协议登录方式

互联网上到处需要密码,为了方便记忆人们喜欢用同一个密码,一个网站被黑客攻破后你的密码就泄露,其他网站也关联被攻破造成更多隐私泄露。

后来出现了 OAuth 登录方式,但这种方式是一种中心化的登录方式,中心平台决定了用户信息的提供,比如微信决定给开发者提供什么样的权限,而且随时可以以各种借口屏蔽、限制开发者或用户的账号,从而造成服务的中断。
这就使得用了 OAuth 登录的网站或 APP 为了双层保障又让用户重新填写提供邮箱、手机和密码。

于是,我在思考,有没有一个更好的方式来解决这个问题。

受到比特币去中心化方式的启发,我们都知道比特币最重要的是它的开放协议,不同的客户端有不同的实现方式,但它们都遵守同一协议,它们就可以实现通信。
所以,我就在想,我们是否能实现一个这样的标准化登录协议,接入协议的无论是网站、开发者、用户,就能实现统一的登录方式,因为是开放的协议,所以就不再受制于任何一个平台。

具体实现:
1,用户要登录网站时,网站生成一个登录码(其实是一个 api 接口),任何实现了登录协议的客户端收到接口后都可以向接口发送加密数据(包括登录、授权信息读取、退出、永久注销等等功能)。
2,本地客户端收到登录码后从本地选择一个账户或生成一个新的账户私钥,通过一定的方式生成加密数据发送给网站,网站收到数据后解析出公钥、登录有效时间等信息完成登录。
3,各个网站的登录私钥、以统一的格式保存在本地客户端。
4,用户可以随时加密导出私钥数据包,导入到其他客户端。
———————————————————————————

整个登录过程,用户不再需要提供密码,各个网站的登录信息,用户自行保管。

我们唯一需要留意的是客户端的安全,通过社区开源、社区鉴别等方式能让用户自由选择一个安全可信赖的客户端。
而且,因为是去中心化的,即使某个用户的终端被黑客攻破,不会对其他用户产生影响,不会出现大面积的数据泄露的情况。

相关文章

41 thoughts on “一种无需密码的开放协议登录方式

  1. 基本上就是,把我们去密码管理器里输入主密码,找到网站的用户名密码,再填到网站的过程,这部分由一个客户端自动生成保存密钥,并这个客户端有和各服务网站对接,或者反过来,服务网站提供这个渠道登录。

    但是这个就引申出一个问题,如果保障用户使用不同设备时登录相同的账号,这就意味着需要一个同步盘来同步这个客户端对接的数据库。

    从上面这个角度来说,我感觉苹果的生态最容易无缝迁移的实现这个标准和功能

  2. 这不就是类似把 SSH 密码转成 SSH key 验证么。对一般用户来说 key 的管理方便程度并不会更低,要么就是像#1 说的依赖某个生态比较完全的厂商,这反而更加中心化了吧……

  3. 其实没必要那么麻烦
    其实就算是 1Password 或者 lastpass 这种也可以做到去中心化
    因为他们无非就是把用户的所有数据加密存在自己的数据中心
    那么把整个数据中心存储变成 ipfs 类似的去中心化的存储方案不就解决了
    只要客户端连接到这个中心化的存储 加上账号+主密钥+主密码 来解开就好了
    只要“账号+主密钥+主密码”不泄漏 那么就算你的加密数据是公开的 也没有关系啊
    反过来如果“账号+主密钥+主密码”泄漏 不管数据是公开的还是私密的 中心化的还是去中心化的 都没救了啊

  4. 如果去中心化是为了安全的话,那这个反而更不安全,51%攻击或者局部的 51%攻击可预见是一定会发生的

  5. @sean10 #1
    同步的确是一个问题,但并不是太大的问题。
    我们可以手动生成数据包,导入到其他设备即可。当然我们也可以借助社区服务器传输数据包,因为数据包是加密的,也不用担心中间服务器读取你的信息。

  6. @yyfearth #3
    重点并不在于去中心,而是把整个系统变成一种协议,类似于 TCP/IP,只要遵守协议任何开发者都可以开发出他们合适的客户端,而且数据通用,不依赖于任何第三方。

    我具体没用过 1password,但我想它只是一个产品而不是协议,这样你就无法得知产品背后的人会不会作恶偷偷保存你的密码信息,而且你不能把它的数据倒入到其他同类型的客户端。

  7. @fengchang #8
    看来我是孤陋寡闻了,我大概查了一下 fido 的介绍,觉得他们那一套都是做了底层的身份认证,是不是有些过于复杂了,估计也就只有大厂们会去对接。

  8. @weitch 这个在消费者产品中很多大厂都在开始做了
    而且很多企业内部基本上都在用 2FA 所以 FIDO 这种还是很有应用前景的

  9. @weitch 很正常…你可以基于 FIDO 的协议写你设想的那个本地客户端,但是没有硬件加密谁敢用

  10. WebAuthn 就是无密码协议,已经进入 W3C 规范了,楼上说的 fido 有实现。直接使用硬件设备存储凭证

  11. 想开小号怎么办?手机或电脑等丢失或被盗怎么办?登录密码与支付密码等权限等级不同的情况怎么办?

  12. @cmdOptionKana 这些都是可以解决的
    首先网站肯定任然会提供密码登陆的方式 也可以使用扫码登陆的方式

    用 fido 的话 也是可以的
    fido 硬件设备不一定是用来打开应用或者网站的设备
    说白了 fido 硬件就只是一个有线或蓝牙(可以支持 NFC)的键盘 用来动态生成和输入密码
    你用别人的设备 只要插上或者配对上你的 fido 硬件 任然可以正常使用
    比如在公司或者图书馆用公共 PC
    只要你用 fido 设备插入 USB 或者 NFC 蓝牙配对 就可以登陆了
    这样也就解决了多用户或者小号的情况

    对于 fido 设备被盗丢失 很简单 你任然可以用其他途径 就像忘记密码一样 来禁用被盗或者都是的 fido 设备

  13. ca 行业表示总感觉自己做的内容也没啥新意千篇一律很老套,为什么还总有客户需要我们给他们设计呢?听到 fido 、ifaa 之类的感觉和一直在搞的没太多区别,只是方案级的整合而已,听到零信任感觉也只是个概念也没提出什么新技术啊,为什么客户会对这些兴趣昂然呢?

    搞久点才知道,原来是因为这个圈子比较封闭,圈外人听这些就会觉得很新鲜,殊不知一些新名词对应的技术早用了二三十年

  14. 基于 password 的认证和密钥协商 本身才是很小的一部分,计算机或者信息系统里大部分认证登录密钥协商密钥分发本身就不用 password 的。

    自己系统里存的私钥证书临时会话密钥等等本身就可以随便导出。

    至于服务器端,自我阉割中心的问题本身就不是个技术问题。
    我为啥要要在我提供的服务里去掉我自己的中心呢???我又不靠去中心化融资骗钱。

    密码学研究了认证和密钥协商几十年,依然认为基于口令的加密不够安全,但行业根本抛弃不了,还不是因为它便捷易用。

  15. 看到这个帖子,我就想到了胎死腹中的 eid 。

    公安部强制要求网站支持。用户无需注册无需密码。网站除了获得用户登录成功之外,获得不了用户的任何其他信息。
    当年也没有这么强烈的被监管的抵触情绪,依然推广不成。

    归根结底的原因就是一个便利性。 无论是当初分发的 usb 版 eid,还是依托工行的数字证书版,都不如账号口令来得便捷。

    任何想要替代口令登录却达不到相同便捷性的方式,都不可能成功替代口令。

  16. @cmdOptionKana #13
    的确,这是个很大问题。
    正如同比特币一样,如果丢失了私钥,那就丢了币。当我们把掌握私钥的权力下放时,就得要求用户有更多自我保护的能力。感觉这是无法调和的矛盾,依赖于中心时我们就失去很多权力,而当我们自己独立时又会失去很多不便。

  17. 有没有觉得抛开去中心化这一点,电信运营商提供的手机号一键授权登录 api 已经做到了楼主想做的事情。

  18. @shynome #16
    哈哈,看样子似乎我们想到一块了,而我还停留在想,你已经开始动手做了,加油。

  19. @weitch 其实这个东西已经有人在做了,叫做 “DIF 认证”,但要推广起来感觉遥遥无期,至少还得 5 年,10 年吧

  20. 关键词好像是 DID auth,我搞不清了,是以前卡在做用户登录的时候找到的

    现在我登陆的解决方案是用户名+密码注册,后续的话需要 TOTP 验证通过才能使用,避免用户账号被爆破盗用

  21. 有了密码学账号的个体
    如何在网络空间活动?

    直接给答案:当然是使用密钥签名一条消息,然后发送给目标

    这里我选择使用 json 作为组装消息的格式

    使用测试账号:
    Address:o8Tjmes6iAukirYrBosSY9ntC5ahqz9ztK
    PublicKey:0203411B7B6FA68C59DE640CA6E4648A60BFFA17020BAD5B47C7CDE58431D70D43

    先构造基础消息
    {
    “Action”:201,
    “Content”:”Hello world…”,
    “PublicKey”:”0203411B7B6FA68C59DE640CA6E4648A60BFFA17020BAD5B47C7CDE58431D70D43″
    }

    Action 是消息类型(为什么用 Action 不用 Type,因为消息是个体在网络空间的活动)
    Content 是消息内容
    PublicKey 是消息生成账号 o8Tjmes6iAukirYrBosSY9ntC5ahqz9ztK 的公钥

    使用账号 o8Tjmes6iAukirYrBosSY9ntC5ahqz9ztK 的密钥对消息签名
    Signature:3044022018C52C995C094392113EC322E270EFAD854219701C53C6DEA791B0B139129A9E02203DF614DC1671A1E939B77AA840CE847E2DC39971FE2C9212A9C35C40A29283D0

    对基础消息增加签名,可以得到
    {
    “Action”:201,
    “Content”:”Hello world…”,
    “PublicKey”:”0203411B7B6FA68C59DE640CA6E4648A60BFFA17020BAD5B47C7CDE58431D70D43″,
    “Signature”:”3044022018C52C995C094392113EC322E270EFAD854219701C53C6DEA791B0B139129A9E02203DF614DC1671A1E939B77AA840CE847E2DC39971FE2C9212A9C35C40A29283D0″
    }

    可以使用 0.1.0 版的 oxo-chat-client 右小角的<校验 Json>对这条消息进行校验

    前面提到用公钥可以算出账号地址,
    其次校验签名需要的三个参数是:基础消息、公钥、签名

    因此在基础消息中加入公钥,第一可以表明消息的生成账号,第二可以用于后续的签名校验,是必要的

    加入签名后的消息,修改任意一个字符都无法通过校验,
    (这在数学上是可以被证明的,可以被证明的才是可信的,因此我信仰数学 [In Math, I believe] )
    由其不可改变的特性,我称其为原子消息。

    使用这条原子消息,个体可以实现了“使用账号 o8Tjmes6iAukirYrBosSY9ntC5ahqz9ztK 在网络空间上进行了一次活动 /操作”,其他个体无法使用账号 o8Tjmes6iAukirYrBosSY9ntC5ahqz9ztK 做出操作。

    ========================================================
    作者:o5rdqyAP36HG6HTCHbiTNh1GJ7kvKk4Z5m
    序号:4
    https://oxo-chat-server.com/bulletin/25CDE89E60E8E7E2AF66F344502D22E8

  22. @lvybupt #21
    唉,的确是很难,如果想提高便利性,就得从设备端底层提供支持,比如浏览器、手机厂商内置等。然而这些恰好都掌控在大厂手里,而使用密码登录最大的受益者其实又是他们,他们自然不会蠢到进行自我革命。

    人们把信任越是集中到那些大厂身上,他们的优势就越加明显,就更能提供更加便利的服务,人们就越加得依赖,这时他们再设置各种关卡收费(比如微信收你的认证费用,苹果收你的苹果税等等),你就拿他没有任何办法。

    总的来说,人类社会自下而上的变革太过罕见,人们的习惯性思维很难接受。

  23. @weitch 其实有一些替代口令的的方案得到了推广,比如指纹。 归根结底还是是不是足够便利。
    去中心化几乎是不可能的。

  24. 关键的一点 你的证书掉了,你就没机会修复了。 其实你的证书也是很容易被盗取的。比密码更安全,但是并没有更好。本质就是你把一个公钥放在一个服务器端了。

  25. 我有预感楼上各位聊的都不太可能被推广,毕竟大部分人都喜欢“运营商号码一键登陆”和“运营商验证码登陆”这种反安全的玩意

  26. @yujiang
    说的没错,大部分人其实就是适应环境活着而已。
    改变世界的肯定是极…极少的个别人。

    ========================================================
    作者:o22Zhy8MzQYemARcftajENtfikjbhTNiqg
    序号:49

发表评论

电子邮件地址不会被公开。 必填项已用*标注