Repository navigation
自动获取口令/账密登录 #1186
Description
Activity
For now if we don't really trust about local "cookie" saving, we can try to extend the authorization code longer, like up to 24h instead of 30 minutes. So assuming someone usually play everyday they will not have to relogin again
Another attempt is using a AES-256 keys pair, one public one private. Like for logging the first time the user will get the authorization code but it is actually the certificate key pair. This key pair can be used to encrypt and decrypt requests, also if the request is modified by somehow, the server can simply return error. We should also consider HMAC, key diversity (one session use a seperate key), key invalidation (after 4/8/12/24h) (or key rotation can be used); timestamps also can be used so we can check if a request is being blocked and tampered
For now if we don't really trust about local "cookie" saving, we can try to extend the authorization code longer, like up to 24h instead of 30 minutes. So assuming someone usually play everyday they will not have to relogin again
Another attempt is using a AES-256 keys pair, one public one private. Like for logging the first time the user will get the authorization code but it is actually the certificate key pair. This key pair can be used to encrypt and decrypt requests, also if the request is modified by somehow, the server can simply return error. We should also consider HMAC, key diversity (one session use a seperate key), key invalidation (after 4/8/12/24h) (or key rotation can be used); timestamps also can be used so we can check if a request is being blocked and tampered
i guess you might want something like SSH key authentication. Client could generate a private key using something like
/dev/urandomfor signing process. The session should be always safe as long as the private key is not leaked. the server only need to log the public key for sessions, and can be easily invalidated by simply removing the record from database. I don't think HMAC or something else should be messed with as long as MITM is not effective with known signature algorithms.however user might be easily got phished to leak private keys. but i think developers should not be responsible for that, what they need to do is tell user to stay alerted and don't get phished. if these fails, user could receive an email which allows them to invalidate the session immediately, include a verify code or something else.
it is fine to use SSL for password transmission, or just implement a key exchange protocol framework which transmits AES key securely. but it is always important to hash the password (with salt if possible) before transmitting it.
现在登录太不方便了
获取的口令很快就会失效，基本每天玩的时候都要：
打开多人模式 - 点击获取口令 - 跳转浏览器 - 输入账号 - 输入密码 - 手动切回游戏 - 粘贴口令 - 连接服务器
但是如果游戏内保存账号密码登录就可以简化成：
第一次：
打开多人模式 - 输入账号和密码 - 连接服务器
以后：
打开多人模式 - 连接服务器
这样多人模式就会更容易进入，在线人数和活跃人数甚至用户数量都会变多
很爱铁壳，但是登录太难受了。改完以后甚至可能成为群友tetrio的替代品（？