【问题标题】:Understating use of Salt with AES256 , and sending the data over the network了解 Salt 与 AES256 的使用,并通过网络发送数据
【发布时间】:2016-04-06 05:29:57
【问题描述】:

我正在尝试加密一个 NSString 内容并将其发送到服务器。

AES 密钥,不应是简单的纯文本。 例如:“密码$5”。

应该添加盐,所以它就像 randomData + Password$5。

此密钥将用于加密。

所以,我将向服务器发送这样的 JSON

{
 password:"Encrypted Password with AES256"
}

现在,我的问题是密钥是随机的,因为盐是随机的,那么我将如何解密 AES256 接收到的加密字符串?

虽然我知道密钥(密码$5),但我不知道盐?

我是否必须将盐发送到服务器(最好的位置是什么,应该在标头中还是在响应本身中),它安全吗?

{
password: "Encrypted Password with AES256",
salt: "Random Hex bytes used"
}

另外,有什么方法可以使用 Spring Restful 服务来处理这个问题?

【问题讨论】:

标签: servlets encryption spring-security aes salt


【解决方案1】:

如果您的目标是对通过网络发送的数据进行加密,则应使用安全连接进行处理。这是在服务器之间,而不是由您的应用程序代码处理。

如果您应该对数据本身进行加密,那么您希望在服务器端处理盐的生成、加密。

对于密码,您需要散列而不是加密。永远不应该有解密密码的理由。您始终可以对提供的密码进行哈希处理并比较哈希值。

【讨论】:

  • 所以,这是否意味着我必须发送加密数据以及盐
  • 不仅仅是加密数据。服务器会在你的应用程序代码得到它之前对其进行解密,然后你可以用你的盐对其进行哈希并检查它
  • 这意味着我可以在服务器和客户端有不同的盐(相同长度,PBKDF2),但哈希结果将是相同的。
  • 不,一点也不。您需要每次都使用相同的盐。
【解决方案2】:

只需使用https,所有数据和查询字符串都被加密。添加证书固定,甚至缓解 MITM 攻击。你的加密也不会更好。

如果您决定自己进行加密,请使用RNCryptor。不熟悉密码学的人几乎不可能获得正确的安全性。

在服务器上不要保存密码,通过 PBKDF2 使用 salt 运行它并保存 salt、迭代次数和哈希密码。

【讨论】:

  • 哦,所以如果使用 HTTPS 将用户密码发送到服务器,我不必担心使用 AES256。这给我带来了另一个问题,为什么人们仍然使用 AES256?
  • 没错。为什么不使用AES(高级加密标准),它是当前的对称加密标准。 https 使用 AES(或其他密码)加密数据。
  • RNCryptor 做对的可能性很小:openwall.com/lists/oss-security/2016/01/24/10
猜你喜欢
  • 2018-07-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-02-03
  • 2015-06-29
  • 2011-04-06
相关资源
最近更新 更多