[Feature] 微软账户登录添加《临时登录》选项

[zkitefly]

描述 | Description

RT，当勾选时，不保存 refreshToken，当第二次启动 HMCL 时就会弹出弹窗要求重新登录，这样可以以防账户被盗？

但缺点也如此，第二次启动 HMCL 时，登录微软账户阶段会使用 refreshToken 刷新 accessToken，无论 accessToken 是否过期，这个可能需要优化下？

原因 | Reason

这样可以以防账户被盗？

[8MiYile]

虽说Minecraft不像Steam上的游戏有盗号风险，但网吧那种环境，懂的都懂，这个功能很有必要

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

[zkitefly]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

[FunnyShadow]

也许可以尝试在关闭 HMCL 时自动清理 refreshToken 或者添加 信任此电脑 相关按钮来保存 refreshToken？

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

甚至可能适得其反，在没有被人盗号的情况下被系统误判为存在风险，自动做出某些防止盗号的行为

[zkitefly]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

我觉得应该不会有人在短时间内频繁登录吧（

[FunnyShadow]

这会导致频繁的重新登录的，根据 Microsoft 官方文档来看，accessToken 默认生命周期在 60~90 分钟内，平均为 75 分钟，如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题 引用：

• https://learn.microsoft.com/zh-cn/entra/identity-platform/access-tokens
• https://learn.microsoft.com/zh-cn/entra/identity-platform/refresh-tokens

可是要是有人偷走了 refreshToken 那差不多直接算把你号盗了

但是这个频繁程度很可能会触发微软的风险控制机制，如果盗号的情况下官方客服还是支持的，但是这种很有可能会因为违反 ToS 导致不被受理乃至完全销号）

我觉得应该不会有人在短时间内频繁登录吧（

如果按照你这个设想，重启一次 HMCL 就需要重新登录，这个频次算下来，如果我测试一些 Mod 或者其他什么东西需要频繁重启 HMCL 的话，这在微软的风控系统看来就算是频繁登录了）

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

[zkitefly]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

HMCL因为是开源的，加密了等于没加密。黄鱼说的（

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

这样的话，所有使用了此账号的 HMCL 在尝试进行一次新的启动（乃至游戏内）都会被强行要求重新登录（游戏内应当会提示会话失效，并要求重新启动游戏或重启启动器）

[FunnyShadow]

而且这种东西不应当会加密存储吗，以及，如果微软账号那边取消授权了是可以立即让该应用的 accessToken 和 refreshToken 失效的，采用应用验证登录方式的启动器都有这个功能

HMCL因为是开源的，加密了等于没加密。黄鱼说的（

每个系统单独生成一个加密密钥不就好了）））

[FunnyShadow]

加密算法可以是开源的，但是密钥不一定得是啊）

就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密

这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

[zkitefly]

那我觉得可以在使用 refreshToken 前先检验 accessToken 是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。

[FunnyShadow]

那我觉得可以在使用 refreshToken 前先检验 accessToken 是否有效，如果失效了才进行刷新，所以我说如果加入这个功能就要把刷新机制调整下。

true，不过我还是建议先把 refreshToken 这种东西加密存储起来，不然仅仅只是 HMCL 这里做了一个判断，有心人还是可以从HMCL 的数据存储中找到 refreshToken

而且最好是加一个必须是官方构建这套加解密功能才能起效的东西，这种东西验证逻辑应该是比较简单的（指对 accessToken 验证是否有效的逻辑），否则如果有人已经被盗号，号主吊销了 accessToken，但是这个人利用一份修改版就可以变相绕开这个限制，直接解密得到 refreshToken

[zkitefly]

加密算法可以是开源的，但是密钥不一定得是啊）

就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密

这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279193675 https://github.com/huanghongxun/HMCL/issues/107#issuecomment-279344793

代码是开源的，加密有用？

不公开是不可能的，Java反编译随时都可以知道代码

[FunnyShadow]

加密算法可以是开源的，但是密钥不一定得是啊） 就类似于 E2E 加密这样，每个系统在第一次启动时自动生成一份加密密钥，然后对获取到的 refreshToken 进行加密存储，需要时在利用这个加密密钥进行解密 这样，源代码中只有加解密相关的内容，但除非我能得到这份加密密钥，不然我也没法子解密这个 refreshToken

#107 (comment) #107 (comment) 代码是开源的，加密有用？ 不公开是不可能的，Java反编译随时都可以知道代码

我对此表示怀疑态度）

加密算法大多也都是开源的（诸如 RSA 与 DSA 等），他们的加密原理都是众所周知的，但这并没有导致什么问题

加密的算法是所有人都知道的，代码也是，但是加密的密钥除非被泄漏，没有人能知道，只需要在第一次启动时生成密钥即可

不然你说像 AuthMe 这种登录插件怎么给密码加密的，他们也是完全开源的）

[zkitefly]

那，加密的密钥存哪

[FunnyShadow]

那，加密的密钥存哪

可以让用户自行决定，比如让他们自己生成 PGP 密钥或者自己选择保存位置，或者直接调用系统的 （Windows 的我不太清楚，Linux 的桌面环境有专门的 PGP 密钥保管库）

[FunnyShadow]

或者去看看别的一些需要加密但是开源的工具也不是不行）

[zkitefly]

或者去看看别的一些需要加密但是开源的工具也不是不行）

算是个大工程了吧， Glavo 当时尝试搞过但没弄好，就弄个全局账户和便携账户

[FunnyShadow]

或者去看看别的一些需要加密但是开源的工具也不是不行）

算是个大工程了吧， Glavo 当时尝试搞过但没弄好，就弄个了全局账户和便携账户

这种东西确实不算很简单（至少我的技术力实现不了），但是也不应该算是一个很难搞的东西

加密库都是现成的，直接引用就好了，使用教程网上应该也是一抓一大把，毕竟加密存储账户信息这个东西也不算是很冷门）

[FunnyShadow]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

[FunnyShadow]

我觉得这个东西应该去麻将官网使劲骂，这种东西完全是官方自己没做好的锅

据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因

[zkitefly]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

目前 HMCL 也是直接塞到一个 json 文件（

[FunnyShadow]

不过我还是要骂一句麻将，这种高安全性的东西为什么官方不做一个存储，甚至 tmd 官启都是直接塞进一个 json 文件的，就很抽象

目前 HMCL 也是直接塞到一个 json 文件（

HMCL 是为了符合官方标准，如果官方都重视，那自然也就没这么多事了） 所以 F**K U SHITJUMP

[burningtnt]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

[FunnyShadow]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

赞成

[zkitefly]

目前，HMCL 支持便携账户和全局账户。便携账户用于把游戏塞到 U 盘里，全局账户用于防止意外泄漏 Token 关于加密的事，或许可以为全局账户加密（密钥通过某些唯一识别码生成），便携账户可选是否开启加密，如果开启则在每次启动 HMCL 时要求手动输入密钥？

我觉得这样可以在一定程度上防止恶意盗号

[burningtnt]

据我了解，全球搞 Minecraft accessToken 加密的启动器总共就没几个，这也是为什么偷 refreshToken 的病毒会如此泛滥的原因

这个真救不了 退一万步说，如果你的电脑真中病毒了，那我直接感染 HMCL 本体，给启动的命令后面加上一个把 Token 写入特定文件的逻辑，不就拿到解密后的 Token 了……

加密能，且仅能拯救的是意外把带有微软便携账户的 HMCL.json 发给别人的情况，对于中病毒这种，没招

[Rovniced]

这个功能还是有用的 对于网吧等不安全地方，这个可以降低盗号风险。

如果不保存 refreshToken 会频繁需要重新登录，而且很可能会触发 Microsoft 官方的风险控制机制导致别的问题

只是不保存到本地，在hmcl的生命周期里面依旧是存在的。在网吧这类环境中基本上hmcl只启动一遍，不会出现频繁关闭和启动hmcl这样的过程。

[8MiYile]

为啥refreshToken不写在内存呢（？） 临时会话不就是全在内存执行嘛，关闭了就无了

[FunnyShadow]

为啥refreshToken不写在内存呢（？） 临时会话不就是全在内存执行嘛，关闭了就无了

明文内存约等于沙滩写字

[burningtnt]

明文内存约等于沙滩写字

这还是在 JVM 里写 byte[]，直接一个 Attach 上去，你的数据就没了，所以考虑同一台电脑上有病毒的情况没啥意义。

[FunnyShadow]

所以根本问题还是得加加密

[burningtnt]

所以根本问题还是得加加密

代码开源，没有意义

我们不能把防计算机病毒考虑在内，这是不可能的

[FunnyShadow]

设备端加密呗 OpenSSL那种也是开源的啊

[burningtnt]

是的，这就是我设想的方案

[Glavo]

即便是 Chrome 都会把密码库的秘钥明文存放在计算机上，所有软件都可以轻易窃取这些网站的密码。HMCL 没有很可靠的方式在保持易用性的同时去保护这些信息。

[FunnyShadow]

你可以生成一个密钥文件，然后让用户设定主密码对密钥文件进行加密，就和 Firefox 等软件加入主密码是一个道理 Chrome 是个例，同时他的解决方案也是行业内所唾弃的

[FunnyShadow]

或者可以尝调用 Windows 凭证存储或 Linux GPG 密码库进行存储

[burningtnt]

即便是 Chrome 都会把密码库的秘钥明文存放在计算机上，所有软件都可以轻易窃取这些网站的密码。HMCL 没有很可靠的方式在保持易用性的同时去保护这些信息。

是的，所以我们不考虑应对计算机病毒

[zkitefly]

所以，这种不加密的方案如何？

[burningtnt]

这个方案的适用范围也就是网吧等只用登录一次的场地？即 refreshToken 只保存在内存里

[liumingedwin]

即使保存在内存中，不做隔离，同等级或更高等级进程可通过注入获取内存中token 这是所有方案共有的bug

[LJS08]

即便是 Chrome 都会把密码库的秘钥明文存放在计算机上，所有软件都可以轻易窃取这些网站的密码。HMCL 没有很可靠的方式在保持易用性的同时去保护这些信息。

但是 Chrome 在尝试改变，就比如尝试用TPM等技术...

[LJS08]

即使保存在内存中，不做隔离，同等级或更高等级进程可通过注入获取内存中token 这是所有方案共有的bug

~使用TPM保存RT~

[FunnyShadow]

实际上这就是加一个主密码进行加密保存的问题）

[LJS08]

对于加密，尝试给每个HMCL生成一个密钥对用来加/解密（或者用对称加密？） ~甚至可以配合安全硬件（比如USB-Key）(但是没必要)~ 对于临时登录，建议不在任何地方保存RT（即使是非持久的），过期就得再次登录，由HMCL控制冷却登录。~(什么银行交易系统）~

~最后，如果考虑计算机病毒就没边了，鬼知道这计算机病毒能搞些什么，SYSTEM? 侧信道攻击？ 就算在TPM也不一定安全，因为谁知道TPM有没有被动手脚？就算TPM本身是安全的，主板电路也有可能被监听, HMCL 再厉害能防住宇宙射线翻转比特吗？能面对 IP 寄存器失效吗？能在逻辑语句有概率失效的情况下继续稳定运行吗？ 如果都能，估计 HMCL 能够登上火星了。~

就跟在 TeaCon 里有一次讨论对Mod进行保护时一样，这些手段也只能起到阻拦作用。

[LJS08]

实际上这就是加一个主密码进行加密保存的问题）

确实...

[zkitefly]

我当时测试微软登录问题测试登录了 30 多遍，除了邮箱有点满任何事都没有