[Feature] 微软账户登录添加《临时登录》选项 about hmcl HOT 42 OPEN

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

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

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

from hmcl.

那，加密的密钥存哪

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

from hmcl.

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

from hmcl.

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

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

from hmcl.

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

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

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

from hmcl.

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

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

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

from hmcl.

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

明文内存约等于沙滩写字

from hmcl.

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

from hmcl.

这会导致频繁的重新登录的，根据 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

from hmcl.

这会导致频繁的重新登录的，根据 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 那差不多直接算把你号盗了

from hmcl.

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

from hmcl.

这会导致频繁的重新登录的，根据 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 导致不被受理乃至完全销号）

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

from hmcl.

这会导致频繁的重新登录的，根据 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 导致不被受理乃至完全销号）

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

from hmcl.

这会导致频繁的重新登录的，根据 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 的话，这在微软的风控系统看来就算是频繁登录了）

from hmcl.

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

from hmcl.

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

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

from hmcl.

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

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

from hmcl.

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

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

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

from hmcl.

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

from hmcl.

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

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

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

from hmcl.

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

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

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

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

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

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

from hmcl.

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

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

我对此表示怀疑态度）

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

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

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

from hmcl.

那，加密的密钥存哪

from hmcl.

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

from hmcl.

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

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

from hmcl.

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

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

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

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

from hmcl.

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

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

from hmcl.

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

from hmcl.

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

赞成

from hmcl.

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

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

from hmcl.

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

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

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

from hmcl.

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

from hmcl.

明文内存约等于沙滩写字

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

from hmcl.

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

from hmcl.

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

代码开源，没有意义

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

from hmcl.

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

from hmcl.

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

from hmcl.

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

from hmcl.

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

from hmcl.

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

from hmcl.

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

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

from hmcl.

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

from hmcl.