一种基于邮箱的用户付费系统构想

[OneLiteCore]

最近在鼓捣国内的付费系统，但是觉得传统的用户注册流程过于繁琐，对于小体量的小项目来说开发和维护一套这样的系统得不偿失。因此构想了一个基于邮箱的用户注册付费流程，大家帮忙看看有什么问题没有。

流程

1. APP 用户本地生成 UUID 并填写他的邮箱地址

2. 后台用邮箱地址和 UUID 计算出 MD5 ，并用后台私钥签名 MD5 ，然后发送给用户邮箱

3. 用户从邮箱中复制数据并回填到 APP 中

4. APP 本地计算出 MD5 然后和用户从邮箱复制过来的数据验签

5. 如果验证通过则说明用户确实持有这个邮箱地址，并将这个邮箱地址加密保存到 APP 本地，否则让用户重复上面的流程。

6. 后台检查数据库是否已存在邮箱对应的购买记录，不存在则生成订单信息并标记邮箱地址

7. APP 收到订单信息发起支付

8. 支付成功后，后台收到回调，将该邮箱的购买记录存入数据库

9. 后台以邮箱、UUID 、时间戳和设备等信息记录已付费邮箱的激活记录

10. 用户用本地认证的邮箱和 UUID 询问后台，如果激活记录小于 2 条则记录并允许激活

11. 如果激活记录 >= 2 则阻止激活，除非让旧设备注销，如果旧设备丢失可以以邮箱发送邮件申请人工注销。

可能存在的问题

• UUID 生成规则
  • 可以考虑别的生成算法比如雪花算法之类的
• MD5 不够可靠
  • 可以用 SHA3 或者 SHA256 摘要算法
• 发送到用户邮箱的数据可能太长
  • 可以考虑只将摘要算法计算出的散列的中间部分进行签名以缩短签名
• 用户本地 Hack 已认证邮箱
  • 用 AES 加密了扔进 MMKV 里面来增大难度
  • 用户难以知道其他已购买用户的邮箱
  • 保留用户从邮箱复制回填的签名数据并用作后续的认证
• 旧设备的注销可能繁琐
  • 丢失设备的情况下人工注销会比较麻烦，但是这个量级应该很少

[timethinker]

一种基于邮箱的用户付费系统构想 ❌

一种限制设备激活数量的方法 ✔

[ltaoo1o]

难评，看之前以为是通过邮箱来进行支付的方案，看完发现是基于邮箱的用户认证。

你把邮箱视为手机号，发邮件看作发验证码。而且邮箱认证已经有完善的方案，开源的有 next-auth ，不过它们都是基于 web 的，逻辑应该能复用到 APP 吧。

[importmeta]

国内注册必须使用能实名标识用户的方式, 方便监管, 手机号只是其一.
但是邮箱不一定, 除非只让 139 邮箱这种实名的手机号办的邮箱.
不然, 别人一举报一个准.

[OneLiteCore]

@importmeta 项目是小工具品类的，本身不提供任何与其他用户交互的能力，所以不存在比如舆论监管审核的问题。

[OneLiteCore]

@timethinker 哈哈哈，看了下面的回复才发现确实这个标题起的不是很好

[OneLiteCore]

@ltaoo1o 标题确实不太贴合内容，不好意思。主要还是想要了解下这套逻辑是否可行，是否存在着明显的漏洞问题之类的，如果熟悉这方面知识还望赐教。

[monkeyk]

推荐看看最新的 物联网协议 FIDO 中的 passkeys 机制； 直接用设备上已有的认证方式（如指纹，扫脸），会是更好的解决办法，安全性更高。

github 上也开始提供这种认证方式。

[ysy950803]

感觉就是用邮箱（视为唯一 ID ）收验证码来证明是本人？然后服务器存邮箱对应的激活次数？是这个意思吗？
其实国内的话，还有个办法是接入微信登录，就能免去传统的注册流程了，那样最简单，服务器存微信的开放 UID 就行。

[ysy950803]

补充一下：既然你都接入国内的支付系统了，说明你有开发者和收款资质，那直接把微信登录一起接了算了。

[geelaw]

单从密码学的角度考虑，不太理解 UUID 的作用是啥，是要绑定第一段邮箱验证，还是要绑定第二段激活？为什么要把 hash 算法（签名的实现细节）暴露在抽象的协议描述上？

从安全与易用性的角度考虑，UUID 需要保存吗？如何教育用户让他们保存？

[SenLief]

没必要吧，直接每次给 email 发验证码登录不就好了。你甚至可以不用发验证码，而是直接发登录链接的方式来登录。

[StinkyTofus]

你这个方案根本没有什么优势。
1. 邮箱不是必选项，就是一个邮箱接收验证码的流程， 换成手机号也完全可行。
2. 设备唯一性完全靠本地生成的 UUID ， 我只要拿到 UUID ， 并 HOOK 掉 UUID 的取值函数， 就完全可以无限复制设备， 你的设备数量激活限制也就无用了。