显而易见的答案是散列。我正在考虑使用 SHA512 来散列加盐密码。
我的问题是：我应该在哪里散列密码？
我想到了两种方法：
(1) 我在应用程序中散列它。这将意味着散列被传输到服务器。然后服务器根据存储的哈希检查它，如果哈希匹配，则登录用户。
(2) 我在服务器上散列它。以同样的方式检查哈希。
我的问题是我觉得密码很可能被截获。在（1）中，可以通过中间人攻击提取哈希。攻击者现在可以简单地使用该哈希来访问用户的信息。
在（2）中，攻击者可以截获明文密码，并使用该密码获取用户帐户的访问权限。
我需要在双方都散列的解决方案吗？用盐在客户端散列，然后在服务器端再次散列？
我不确定如何继续。我不希望用户的信息被访问。
如果您也能指出您的建议的好处，我将不胜感激。
【问题讨论】：
标签： android security hash passwords
只需使用 SSL 并以纯文本形式传递密码。说真的，只需使用 HTTPS。
在服务器上散列密码。
如果您在客户端对其进行哈希处理，您很容易受到称为“重放攻击”的攻击，攻击者可以在其中拦截请求，窃取“盐 + 哈希”，然后使用它进行身份验证。
在（2）中，攻击者可以截获明文密码，并使用该密码获取用户帐户的访问权限。
如果攻击者能够通过 MITM 攻击 SSL，那么一切都会丢失无论如何。他们可以造成比仅仅拦截密码更大的损害。 （而且可能性要小得多）
但是，请考虑使用联合身份验证（例如 OAuth2 或 Google+ Sign-in）来为您处理此问题。
【讨论】：
https://... 而不是 http://... 调用它
让我们从头开始。
可以在对密码进行加盐和散列之前在服务器端生成盐（以确保其唯一性）然后发送到客户端吗？
您绝对应该在服务器端执行加盐，以确保您可以最大程度地控制此过程。绝不允许用户、客户端或设备自己制作盐。
salt 和 hash 是否可以用来访问用户的帐户？加密通道是否旨在防止任何中间人攻击？
如果有人可以访问所有存储的哈希和盐，他们可以尝试进行暴力/字典攻击以尝试获取匹配的哈希，但他们只能非常缓慢地进行，因为每个哈希都有不同的盐。
请记住，如果一个人的密码短或弱，他们的密码仍然可以很快被破解。
如果它们都含有相同的盐，那么当它们破解一种盐时，它们基本上会破解所有盐。
加密通道是为了防止人们监听客户端和服务器之间的通信。它不能保证它会阻止 MITM 攻击，但它应该增加一层保护，因为 MITM 无法验证自己是您/您的组织。
如何确保我的 android 应用和 Google App Engine 之间的通道是安全的？
这取决于，是通过网络吗？使用 HTTPS 并使用 SSL 证书验证您的应用程序，如果在您的预算范围内，请使用扩展验证。
【讨论】：