使用我自己的散列算法而不是流行的散列算法有什么缺点? [英] What are the downsides of using my own hashing algorithm instead of popular ones available?

查看:200
本文介绍了使用我自己的散列算法而不是流行的散列算法有什么缺点?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是算法的小白,并不是很聪明。但我脑海中有一个问题。有很多哈希算法可用,这些算法可能比我写的要复杂10倍,但几乎所有这些算法都可以预测。最近,我读到写我自己的哈希函数不是一个好主意。但为什么?我想知道一个程序/程序员如何破坏我的逻辑(例如)为每个字符串创建一个独特的哈希,其步骤为5 +以上。假设某人在我的服务器中成功注入了SQL查询并获取了所有的哈希值。程序(如hashcat)如何帮助他解密这些哈希?在这种情况下,我可以看到我自己的算法的一个强大的一面,即没有人知道它,黑客也不知道它是如何实现的。另一方面,众所周知的算法(如sha-1)不再是不可预测的。有可用的网站非常有资格有效地打破这些哈希。所以,我的一个简单问题是,为什么聪明人不推荐使用自写散列算法?

解决方案

默默无闻的安全性可能是一项优势,但您绝对不应该依赖它。您只要知道代码保持秘密(共享主机,备份,源代码管理等等),存储的密码已不再安全就可以了。

发明一种新的安全算法极其困难,即使对于密码学家而言。有很多要考虑的要点,比如正确的盐渍键拉伸,确保类似的输出不允许得出有关输入相似性的结论等等。只有经过多年来被其他密码学家攻击的算法才算安全。通过发明一种算法,你实际上为散列(你的代码)增加了一个秘密,只有在了解这些代码的情况下,攻击者才能开始暴力破解密码。添加秘密的更好方法是:使用已知的经过验证的算法(BCrypt,SCrypt,PBKDF2)对密码进行哈希处理。 >

  • 使用秘密的服务器端密钥(双向加密)对生成的哈希进行加密。

    你也可以添加一个秘密(服务器端的密钥)。只有攻击者在服务器上拥有特权才能知道密钥,在这种情况下,他也会知道你的算法。这个方案还允许在必要时交换密钥,交换哈希算法会困难得多。

    I am a noob in algorithms and not really so smart. But I have a question in my mind. There are a lot of hashing algorithms available and those might be 10 times more complex than what I wrote, but almost all of them are predictable these days. Recently, I read that writing my own hashing function is not a good idea. But why? I was wondering how a program/programmer can break my logic that (for example) creates a unique hash for each string in 5+ steps. Suppose someone successfully injected a SQL query in my server and got all the hashes stored. How a program (like hashcat) may help him to decrypt those hashes? I can see a strong side of my own algorithm in this case, that it is known by no one and the hacker has no idea how it was implemented. On the other hand, well-known algorithms (like sha-1) are not unpredictable anymore. There are websites available that are highly eligible to efficiently break those hashes. So, my simple question is, why smart people do not recommend to use self-written hashing algorithms?

    解决方案

    Security by obscurity can be an advantage, but you should never rely on it. You rely on the fact that your code stays secret, as soon as it becomes known (shared hosting, backups, source-control, ...) the stored passwords are propably not safe anymore.

    Inventing a new safe algorithm is extremely difficult, even for cryptographers. There are many points to consider like correct salting or key-stretching, making sure that similar output does not allow to draw conclusions about the similarity of the input, and so on... Only algorithms withstanding years of attacks by other cryptographers are regarded as safe.

    There is a better alternative to inventing your own scheme. With inventing an algorithm you actually add a secret to the hashing (your code), only with the knowledge of this code an attacker can start brute-forcing the passwords. A better way to add a secret is:

    1. Hash the passwords with a known proven algorithm (BCrypt, SCrypt, PBKDF2).
    2. Encrypt the resulting hash with a secret server-side key (two-way encryption).

    This way you can also add a secret (the server side key). Only if the attacker has privileges on the server he can know the key, in this case (s)he would also know your algorithm. This scheme also allows to exchange the key when necessary, exchanging the hash algorithm would be much more difficult.

    这篇关于使用我自己的散列算法而不是流行的散列算法有什么缺点?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆