Questions tagged «brute-force»

首先，有一点背景知识：我正在为CodeIgniter实现auth + auth系统，这并不是什么秘密，到目前为止，我已经赢了（可以这么说）。但是我遇到了一个非常艰巨的挑战（大多数身份验证库都完全忽略了这一挑战，但是我坚持要正确处理）：如何智能地应对大规模，分布式，可变用户名的暴力攻击。 我知道所有常用的技巧： 限制每个IP /主机尝试失败的次数，并拒绝违规者访问（例如Fail2Ban）- 由于僵尸网络变得越来越聪明，这种访问不再有效 将上述内容与已知的“不良” IP /主机（例如DenyHosts）的黑名单相结合-依赖于僵尸网络排名第一的僵尸网络，它们越来越不会 IP /主机白名单与传统身份验证结合在一起（对于动态IP用户和大多数网站上的用户流失率非常低） 在整个N分钟/小时的时间内对失败尝试的次数设置站点范围的限制，并在此之后的几分钟/小时内限制（挂起）所有登录尝试（问题是DoS攻击您成为僵尸网络的玩法） 强制性数字签名（公钥证书）或RSA硬件令牌，适用于所有没有登录/密码选项的用户（毫无疑问是坚如磐石的解决方案，但仅适用于封闭的专用服务） 强制执行超强密码方案（例如，> 25个带有符号的废话字符-再次对临时用户来说太不切实际） 最后，CAPTCHA（在大多数情况下都可以使用，但是使用户烦恼，并且对于坚定的，足智多谋的攻击者几乎毫无用处） 现在，这些只是理论上可行的想法。有很多垃圾想法使站点大开眼界（例如，对琐碎的DoS攻击）。我想要的是更好的东西。更好的是，我的意思是： 它必须具有抵御DoS和暴力攻击的安全性（+），并且不得引入任何新的漏洞，而该漏洞可能会使稍稍偷偷摸摸的bot继续在雷达下运行 它必须是自动化的。如果它需要人工来验证每个登录名或监视可疑活动，那么它将无法在实际情况下工作 它对于主流Web使用必须是可行的（例如，非程序员可以进行的高流失，高流量和开放式注册） 它不会将用户体验阻止到使临时用户感到烦恼或沮丧（并有可能放弃该网站）的程度 除非小猫真的很安全，否则它不能涉及小猫 （+）“安全”是指至少与偏执狂用户对密码保密的能力一样安全 所以-让我们听听吧！你会怎么做？您知道我没有提到的最佳做法吗（哦，请说您同意）？我承认我确实有自己的想法（结合3和4的想法），但是在让自己尴尬之前，我会让真正的专家讲话；-)

151 security  authentication  brute-force 

在工作中，我们有两种相互竞争的盐理论。我从事的产品使用诸如用户名或电话号码之类的东西来加杂凑。从本质上讲，每个用户都有所不同，但我们可以随时使用。其他产品会为每个用户随机生成一个盐，并在用户每次更改密码时都会更改它。然后将盐在数据库中加密。 我的问题是第二种方法是否真的必要？从纯粹的理论角度我可以理解，它比第一种方法更安全，但是从实用性角度来看又如何呢？现在要对用户进行身份验证，必须对salt进行加密，并将其应用于登录信息。 在考虑之后，我只是看不到这种方法真正的安全性收益。即使在攻击者知道如何快速确定每个帐户的含义的情况下，一个帐户一个帐户地更改盐，仍然使某人尝试强行使用哈希算法仍然非常困难。假设密码足够强。（显然，找到一组均为两位数字的密码，正确的哈希值要比找到正确的8位密码的哈希值容易得多）。我的逻辑是否正确，或者我缺少什么？ 编辑：好的，这就是为什么我认为加密盐真的没有意义。（让我知道自己是否走对了路）。 对于以下说明，我们假设密码始终为8个字符，salt为5，并且所有密码均由小写字母组成（这使数学更容易了）。 每个条目具有不同的盐值意味着我不能使用相同的彩虹表（实际上，如果我有一个足够大的表，我可以使用，但是暂时暂时忽略它）。从我的理解中，这是盐的真正关键，因为要破解每个帐户，我都必须重新发明轮子，以便为每个帐户说话。现在，如果我知道如何对密码应用正确的盐来生成哈希，我会这样做，因为盐实际上只是在扩展哈希短语的长度/复杂度。因此，我将减少生成“知道”密码（从13 ^ 26到8 ^ 26的密码）所需的可能组合的数量，因为我知道盐是什么。现在，它变得更容易，但仍然非常困难。 因此就加密了盐。如果我知道盐是加密的，那么我不会尝试对其进行解密（假设我知道它具有足够的加密级别）。我会忽略它。回到上一个示例，而不是试图弄清楚如何解密它，我只会生成一个更大的Rainbow表，其中包含13 ^ 26的所有密钥。不知道加盐肯定会使我慢下来，但是我认为这不会增加尝试先破解加盐加密的艰巨任务。这就是为什么我认为这不值得。有什么想法吗？ 以下是描述在暴力攻击下密码将保留多长时间的链接：http : //www.lockdown.co.uk/? pg=combi

99 security  encryption  hash  brute-force