您如何确保小数据的数据安全性？ [英] How Do You Ensure Data Security of Small Data?

问题描述

我的问题：

确保小数据的数据安全的最佳方法是什么？下面，我提出了有关对称和非对称加密的问题。我很好奇，是否有一种方法可以对小数据进行非对称加密，而这种加密相当于某种盐化以使其真正安全？如果是这样，您如何选择盐并正确实施呢？ 还是有更好的方法来解决这个问题？

What is the Best Approach to Ensure Data Security of Small Data? Below I present a concern around symmetric and asymmetric encryption. I'm curious if there is a way to do asymmetric encryption on small data with an equivalent of some sort of "salting" to actually make it secure? If so, how do you pick a "salt" and implement it properly? Or is there a better way to handle this?

我的关注的解释：

在加密具有大量特征的内容时，在我看来，非对称加密方法非常安全。我担心的是如果我的数据字段很小，例如数据库中的信用卡号，密码或社会保险号。然后，要加密的数据具有固定的长度和表示形式。话虽这么说，黑客可能会尝试使用公共密钥加密每个可能的社会安全号码（10 ^ 9排列）并将其与数据库中存储的值进行比较。一旦找到匹配项，他们就会知道真实数字。可以对其他数据类型进行类似的攻击。因此，我决定避免使用对称方法，例如mysql的 AES_ENCRYPT（）内置函数，但是现在我也质疑非对称方法。

When encrypting something that has "bulk" it seems to me that asymmetric encryption approaches are pretty secure. My concern is around if I have a small field of data, say a credit card number, password, or social security number in a database. Then the data being encrypted is of fixed length and presentation. That being said, a hacker could attempt to encrypt every possible social security numbers (10^9 permutations) with the public key and compare it to values stored in the db. Once they find a match, they know the real number. Similar attacks can be done for the other data types. Because of this, I decided to avoid symmetric methods like mysql's AES_ENCRYPT() built in function, however now I'm questioning asymmetric as well.

如何正确保护小数据？

Salting通常用于哈希算法，但我需要之后能够取回数据。我考虑过也许有一些基本批量文本，然后将敏感数据附加到末尾。在该串联上进行加密。解密将通过解密然后剥离基本批量文本来逆转该过程。如果黑客能弄清基本的批量文本，那么我看不出它将如何增加任何额外的安全性。

Salting is normally used for hash algorithms, but I need to be able to get the data back after. I thought about maybe having some "base bulk text", then append the sensitive data to the end. Do the encrypt on that concatenation. Decryption would reverse the process, by decrypting then stripping off the "base bulk text". If the hacker can figure out the base bulk text then I don't see how this would add any additional security.

选择其他数据作为加密的一部分，以帮助就像从数据库中其他字段派生的盐值（或这些字段的哈希值，或它们的组合产生相同的问题）一样，似乎也很容易受到攻击。由于黑客可能会遇到与上述攻击类似的组合，以尝试执行更智能的蛮力形式。话虽这么说，但我不确定如何正确保护小数据，而我的Google并没有帮助我。

Picking other data to include as part of encryption, to help act like a salt value derived from other fields in the database(or hash values of those fields, or combination there of yields the same issue) also seems like it is vulnerable. As hackers could be run through combinations similar to the attack mentioned above to try to perform a more intelligent form of "brute force". That being said, I'm unsure of how to properly secure the small data and my googles have not helped me.

什么是确保数据的最佳方法？小数据的安全性？

推荐答案

当我加密短消息时，我会在它们之前添加一个较长的随机盐加密。 编辑其他人建议在有效载荷之前加盐。

When I encrypt short messages, I add a relatively long random salt to them before encryption. Edit others suggest prepending the salt to the payload.

例如，如果我加密了伪造的信用卡号 4242 4242 4242 4242 。我实际加密的是

So, for example, if I encrypt the fake credit card number 4242 4242 4242 4242. what I actually encrypt is

   tOH_AN2oi4MkLC3lmxxRWaNqh6--m42424242424242424

第一次，并且

   iQe5xOZPIMjVWfrDDip244ZGhCy2U142424242424242424

第二次，依此类推。

这种随机撒盐会严重阻碍您描述的查找表方法。许多操作系统都提供高质量随机数的来源，例如* nix / dev / rand 和Windows的 RNGCryptoServiceProvider 模块。

This random salting significantly discourages the lookup table approach you describe. Many operating systems furnish sources of high-quality random numbers like *nix /dev/rand and Windows' RNGCryptoServiceProvider module.

在没有深度防御和PCI数据安全认证的情况下，以这种方式保存支付卡数据仍然不可行。

It's still not OK to hold payment card data in that way without defense in depth and PCI data security certification.

Edit ：某些加密方案将这种盐化作为其正常功能的一部分进行处理。

Edit: Some encryption schemes handle this salting as part of their normal functioning.

这篇关于您如何确保小数据的数据安全性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！