身份认证服务 与 树洞API服务 分离为2个程序

[thuhole]

此issue是#20 的一部分。

为了优化后端数据安全与用户注册信息安全，现有一种优化方案是，将身份认证服务 与 树洞API服务 分离为2个程序。

目前，在pkg/route/route.go中，现有程序提供如下HTTP服务：

    r.POST("/api_xmcp/login/send_code", sendCode)
    r.POST("/api_xmcp/login/login", login)
    r.GET("/api_xmcp/hole/system_msg", systemMsg)
    r.GET("/services/thuhole/api.php", apiGet)
    r.POST("/services/thuhole/api.php", apiPost)

现考虑将/api_xmcp/*与/services/thuhole/api.php分离为2个程序：

1. 身份认证程序：提供3个接口
   • /api_xmcp/login/send_code, /api_xmcp/login/login与原先功能保持不变
   • 用户邮箱有关的的单向加密全部在此程序中完成，此程序中的salt或key应只存在于内存之中，salt或key由https://github.com/thuhole/shamir-key-sharing 生成，分发给管理员。超过半数持有shamir key share的管理员一起才可以解密出salt或key。
   • 此程序需要保持高可用，如非特殊情况不重启，重启服务需要超过半数持有shamir key share的管理员参与。
   • 用户邮箱的加密函数，视升级难度，可以考虑选为sha(salt+sha(email)), AES(email, key), AES(sha(salt+sha(email)), key)中的一种。
2. 树洞API程序：和原先/services/thuhole/api.php, /api_xmcp/hole/system_msg所提供的功能一致。

这2个程序不一定要在同一台服务器中运行，可以分离，分离后仍然最好共用SQL服务器中的user_info和banned表，如果不共用这两个SQL表，则需要多增加接口维护这两个表的同步。

目前可以想到的此方案主要困难在于，维护身份认证程序的高可用。因为，每次重启将会非常麻烦。这对程序的可靠性、服务器提供商的可靠性要求都非常高。

欢迎大家讨论。

[yzs981130]

motivation是不希望管理员能够从hash猜出/算出/碰出用户邮箱是吗

[thuhole]

motivation是不希望管理员能够从hash猜出/算出/碰出用户邮箱是吗

@yzs981130 是的，简而言之就是希望分权。因为看报道好像P大树洞后端采用了类似的技术。

[thuhole]

刚刚调整了目录结构，还差travis没跟进。

[thuhole]

部署成功。目前salt在服务器里只存在于内存当中，数据安全性得到提升。根据程序之后一段时间运行的稳定情况，未来方便时salt将通过shamir's key sharing生成并分发给管理员。