英文:
How can I secure a server authentication password securely on client side?
问题
在我的应用程序中，客户端通过 SSLSocket 连接服务器。为了对服务器进行身份验证，服务器发送盐（salt），客户端使用给定的盐对密码进行加密后再发送给服务器。
实际上，我不想让用户每次都输入密码，但另一方面，我又不想存在安全问题。
我了解了一下密钥库（keystore），但它们安全吗？而且就我理解，用户似乎仍然需要输入一个密码。
什么样的解决方案既安全又方便用户呢？
英文:
In my application a client connects to a server via SSLSocket. To authenticate the server sends the salt and the client sends the password encrypted with the given salt.
I actually do not want to have the user type his password every time, but on the other hand I do not want to have a security issue.
I read about keystores, but are they secure? And also for my understanding, the user still has to type a password.
What would be a secure and user-comfortable solution?
答案1
得分: 0
如果我理解正确，您当前的协议如下所示：
服务器 -> 客户端：随机 nonce
服务器 <- 客户端：加密密码
服务器 <- 客户端：加密密码
客户端不需要一遍又一遍地发送密码，我建议您在协议中使用访问令牌。访问令牌（"认证令牌"、"会话 ID"）是服务器返回的一个大的随机值，作为认证响应：
服务器 <- 客户端：加密密码
服务器 -> 客户端：256 位访问令牌
服务器 <- 客户端：256 位访问令牌
服务器 <- 客户端：256 位访问令牌
这是一个会话管理机制。NIST 对会话管理提供了建议：https://pages.nist.gov/800-63-3/sp800-63b.html#sec7
与持续呈现凭证相比，会话管理更可取，因为持续呈现的差劲可用性往往会产生对诸如缓存解锁凭证的变通方案的激励，从而使认证事件的新鲜度降低。
客户端将访问令牌保存在内存中，并代替密码使用它。如果您希望在应用程序启动之间保留访问令牌，那么您必须安全地存储它，这取决于客户端的操作系统：
- Android：KeyStore。
- iOS：钥匙串（keychain）。
- Linux/Windows/MacOS：在这里比较困难 - 只需尽可能长时间地保持令牌在内存中，不要存入文件，尽量让应用程序运行得更久。
无论哪种方式，访问令牌在一段时间后都必须过期，即使由于某种原因泄漏了，客户端也会在一段时间后获得新的访问令牌。请参阅NIST 中有关重新认证的部分。
英文:
If I correctly understand, your current protocol looks like the following:
server -> client: random nonce
server <- client: encrypted password
server <- client: encrypted password
Client doesn't have to send his password again and again, and I would recommend you to leverage an access token in your protocol. Access token ("authentication token", "session id") is a big random value which server returns as an authentication response:
server <- client: encrypted password
server -> client: 256-bit access token
server <- client: 256-bit access token
server <- client: 256-bit access token
It is a session management. NIST provides recommendations about session management: https://pages.nist.gov/800-63-3/sp800-63b.html#sec7
>Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as cached unlocking credentials, negating the freshness of the authentication event.
Client holds the access token in the memory and uses it instead of the password.
If you want to preserve the access token between application launches then you have to store it safely and it depends on client's OS:
- Android: KeyStore.
- iOS: keychain.
- Linux/Windows/MacOS: it is hard here - just hold the token in the memory as long as possible, don't put into file, make application to run as long as possible.
Either way, access token has to expire after a while, and even if it leaked by some reason, the client would get a new one after a while. See the part about re-authentication in NIST.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论