security -基于表单的网站身份验证的权威指南

Translate

网站的基于表单的身份验证

我们认为,堆栈溢出不仅应作为解决非常具体的技术问题的资源,而且还应作为解决常见问题的通用准则。 “基于表单的网站身份验证”应该是此类实验的一个不错的主题。

它应包括以下主题:

  • 如何登入
  • 如何登出
  • 如何保持登录状态
  • 管理Cookie(包括建议的设置)
  • SSL / HTTPS加密
  • 如何储存密码
  • 使用秘密问题
  • 忘记的用户名/密码功能
  • 用于随机数阻止跨站点伪造请求(CSRF)
  • OpenID
  • “记住我”复选框
  • 浏览器自动完成用户名和密码
  • 秘密网址(公开网址受摘要保护)
  • 检查密码强度
  • 电子邮件验证
  • 还有更多关于 基于表单的身份验证...

它不应包含以下内容:

  • 角色和授权
  • HTTP基本认证

请通过以下方式帮助我们:

  1. 建议子主题
  2. 提交有关此主题的好文章
  3. 编辑官方答案
This question and all comments follow the "Attribution Required."

所有的回答

Translate

第一部分:如何登录

我们假设您已经知道如何构建一个登录名+密码HTML表单,该表单将值发布到服务器端的脚本中以进行身份验证。以下各节将介绍合理的实用身份验证模式,以及如何避免最常见的安全陷阱。

要HTTPS还是不要HTTPS?

除非连接已经很安全(即使用SSL / TLS通过HTTPS进行隧道传输),否则您的登录表单值将以明文形式发送,这使任何窃听浏览器和Web服务器之间链接的人都可以在通过时读取登录信息通过。这类窃听通常由政府执行,但总的来说,我们不会说“拥有”的窃听器,而是说:仅使用HTTPS。

本质上,唯一实际的登录期间防止窃听/数据包嗅探的方法是使用HTTPS或其他基于证书的加密方案(例如,TLS)或经过验证的挑战响应方案(例如,迪菲·赫尔曼的SRP)。任何其他方法都可以轻松规避被窃听的攻击者。

当然,如果您有点不切实际,也可以采用某种形式的两因素身份验证方案(例如Google Authenticator应用,物理“冷战风格”密码本或RSA密钥生成器加密狗)。如果正确应用,即使在不安全的连接下也可以使用,但是很难想象开发人员愿意实施两因素身份验证而不是SSL。

(请勿)自行编写JavaScript加密/哈希

鉴于感知(尽管现在可避免的)的成本以及在您的网站上设置SSL证书的技术难度,一些开发人员倾向于使用自己的浏览器内哈希或加密方案,以避免通过不安全的网络传递明文登录信息。

尽管这是一种崇高的思想,但它实际上是无用的(并且可以是安全漏洞),除非将其与上述方法之一结合使用-也就是说,要么通过强力加密保护线路,要么使用久经考验的质询-响应机制(如果您不知道那是什么,那就知道那是一种最难证明,最难设计,最难实现的概念)。

哈希密码是正确的对...有效密码泄露,那么它很容易受到重放攻击,中间人攻击/劫持(如果攻击者可以在不安全的HTML页面到达浏览器之前向其注入一些字节,则他们可以简单地注释掉JavaScript中的哈希),或暴力攻击(因为您同时向攻击者提供了用户名,盐和哈希密码)。

CAPTCHAS反人类

验证码旨在挫败一类特定的攻击:无需人工操作的自动词典/蛮力试错法。毫无疑问,这是一个真正的威胁,但是,有许多方法可以无缝处理它,而不需要CAPTCHA(经过专门设计的服务器端登录限制方案),我们将在后面讨论。

知道CAPTCHA的实现不是完全一样的。它们通常不是人类可解决的,大多数实际上对机器人无效,而对于廉价的第三世界劳动力,它们全都无效(根据OWASP,目前的血汗工厂收费标准是每500个测试12美元),并且在某些国家/地区,某些实施在技术上可能是非法的(请参见OWASP认证备忘单)。如果您必须使用验证码,请使用Google的验证码,因为从定义上讲它是OCR硬性的(因为它使用了已经被OCR误分类的书本扫描),并且努力使用户友好。

就个人而言,我倾向于发现CAPTCHAS很烦人,并且仅在用户多次登录失败且限制延迟已达到最大时才将其用作最后的手段。这种情况很少发生,无法接受,并且会增强整个系统。

存储密码/验证登录名

在近年来发生了所有广为人知的黑客和用户数据泄漏之后,这可能最终成为常识,但必须指出:不要在数据库中以明文形式存储密码。用户数据库通常会通过SQL注入被黑客入侵,泄漏或收集,如果您存储的是原始的纯文本密码,那么这将为您的登录安全提供即时的解决方案。

因此,如果您无法存储密码,如何检查从登录表单发布的登录名和密码组合是否正确?答案是使用密钥推导功能。每当创建新用户或更改密码时,您都将获取密码并通过KDF(例如Argon2,bcrypt,scrypt或PBKDF2)运行它,将明文密码(“ correcthorsebatterystaple”)转换为长而随机的字符串,这样可以更安全地存储在数据库中。要验证登录名,请对输入的密码运行相同的哈希函数,这一次传入了salt并将结果哈希字符串与数据库中存储的值进行比较。 Argon2,bcrypt和scrypt已经将盐与哈希一起存储了。看看这个文章在sec.stackexchange上获得更多详细信息。

使用盐的原因是散列本身是不够的-您需要添加一个所谓的“盐”来保护散列免受彩虹桌。 Salt可以有效地防止将两个完全匹配的密码存储为相同的哈希值,从而防止在攻击者执行密码猜测攻击时一次扫描整个数据库。

密码哈希不能用于密码存储,因为用户选择的密码不够强(即通常不包含足够的熵),并且攻击者可以在较短时间内完成对哈希的访问,从而完成密码猜测攻击。这就是为什么使用KDF的原因-这些有效“伸展钥匙”,这意味着攻击者每次猜测密码都会导致哈希算法多次重复,例如10,000次,这会使攻击者将密码猜测速度慢10,000倍。

会话数据-“您以Spiderman69登录”

服务器针对用户数据库验证了登录名和密码并找到匹配项后,系统需要一种方式来记住浏览器已通过身份验证。这个事实只应该存储在会话数据的服务器端。

如果您不熟悉会话数据,请按以下说明进行操作:将一个随机生成的字符串存储在到期的cookie中,并用于引用存储在服务器上的数据集-会话数据。如果您使用的是MVC框架,那么无疑已经进行了处理。

如果有可能,请确保会话cookie在发送到浏览器时已设置了安全和HTTP Only标志。 HttpOnly标志为通过XSS攻击读取cookie提供了一些保护。安全标志可确保Cookie仅通过HTTPS发送回,因此可以防止网络嗅探攻击。 cookie的值不应是可预测的。如果提供了引用不存在的会话的Cookie,则应立即替换其值以防止会话固定.

第二部分:如何保持登录状态-臭名昭著的“记住我”复选框

永久登录Cookies(“记住我”功能)是一个危险区域。一方面,当用户了解如何处理它们时,它们与传统登录完全一样安全;另一方面,粗心的用户则面临巨大的安全风险,他们可能会在公用计算机上使用它们,却忘记了注销,并且可能不知道浏览器cookie是什么或如何删除它们。

就个人而言,我喜欢经常访问的网站的永久登录,但是我知道如何安全地处理它们。如果您确定用户知道相同的信息,则可以凭良心使用持久性登录。如果不是-很好,那么您可以订阅这样一种哲学,即粗心的登录凭据的用户会在被黑客入侵时将其带到自己身上。这也不像我们去用户家并撕下所有那些诱使Facepalm的Post-It便条,也就是他们在监视器边缘排列的密码。

当然,有些系统负担不起任何帐户被黑;对于此类系统,您无法证明拥有永久登录名是合理的。

如果您决定实施永久登录cookie,请按以下步骤进行:

  1. 首先,花一些时间阅读Paragon Initiative的文章就此主题而言。您需要正确处理一堆元素,并且本文在解释每个元素方面做得很好。

  2. 为了重申最常见的陷阱之一,请勿将持久性登录COOKIE(令牌)存储在您的数据库中,仅是一种哈希!登录令牌是等效的密码,因此,如果攻击者将您的手放在数据库上,他们可以使用令牌登录任何帐户,就像它们是明文登录密码组合一样。因此,请使用哈希(根据https://security.stackexchange.com/a/63438/5002在存储持久登录令牌时,弱散列就可以很好地实现此目的。

第三部分:使用秘密问题

不要实施“秘密问题”。 “秘密问题”功能是一种安全反模式。从必读列表中的链接编号4中阅读论文。您可以在Yahoo!之后询问Sarah Palin的问题。该电子邮件帐户在上次总统竞选期间遭到黑客入侵,原因是对她的安全问题的答案是“ Wasilla高中”!

即使有用户指定的问题,大多数用户也很可能会选择以下任一项:

  • “标准”秘密问题,例如母亲的娘家姓或喜欢的宠物

  • 一个简单的琐事,任何人都可以从他们的博客,LinkedIn个人资料或类似内容中获取

  • 任何比猜测密码容易回答的问题。对于任何体面的密码,这是您可以想象的每个问题

总而言之,安全性问题本质上在所有形式和变体上本质上都是不安全的,并且出于任何原因都不应在身份验证方案中使用。

甚至在野外还存在安全性问题的真正原因是,它们方便地节省了无法访问其电子邮件以获取重新激活码的用户的一些支持电话的费用。这是以牺牲安全性和萨拉·佩林的声誉为代价的。值得?可能不会。

第四部分:忘记的密码功能

我已经提到了为什么你应该从不使用安全性问题用于处理忘记/丢失的用户密码;不用说,您永远不要通过电子邮件向用户发送其实际密码。在此字段中,至少要避免两个非常常见的陷阱:

  1. 重启自动生成的强密码的忘记密码-众所周知,这种密码很难记住,这意味着用户必须更改密码或将其写下来-例如,在显示器边缘的亮黄色Post-It上。无需设置新密码,只需让用户立即选择一个新密码即可。 (这可能是一个例外,如果用户普遍使用密码管理器来存储/管理通常不记下来就无法记住的密码)。

  2. 始终对数据库中丢失的密码代码/令牌进行哈希处理。再次,此代码是等效密码的另一个示例,因此必须将其进行哈希处理,以防攻击者进入您的数据库。当要求输入丢失的密码代码时,请将纯文本代码发送到用户的电子邮件地址,然后对其进行哈希处理,然后将哈希表保存在数据库中,然后扔掉原来的。就像密码或永久登录令牌一样。

最后一点:请始终确保您输入“丢失的密码”的界面至少与登录表单本身一样安全,否则攻击者只会使用它来获取访问权限。确保您生成很长的“丢失的密码代码”(例如,区分大小写的16个字母数字字符)是一个不错的开始,但是请考虑添加与登录表单本身相同的限制方案。

第五部分:检查密码强度

首先,您需要阅读这篇小文章进行现实检查:500个最常用的密码

好吧,所以清单可能不是典范上最常用的密码列表任何系统任何地方,但这很好地表明了在没有实施强制策略的情况下人们选择密码的能力有多么差。此外,将该列表与最近对被盗密码进行公开分析相比,它看上去离家很近。

因此:在没有最低密码强度要求的情况下,2%的用户使用前20个最常用的密码之一。意思是:如果攻击者仅获得20次尝试,则您网站上50个帐户中的1个将是可破解的。

要阻止这种情况,需要计算密码的熵,然后应用阈值。美国国家标准技术研究院(NIST)特别出版物800-63有一组非常好的建议。当与字典和键盘布局分析结合使用时(例如,“ qwertyuiop”是一个错误的密码),可以拒绝所有错误选择的密码的99%以18位熵的水平只需计算密码强度和显示视觉强度计对用户来说是好的,但不足。除非强制执行,否则很多用户很可能会忽略它。

为了让用户更轻松地使用高熵密码,Randall Munroe的密码强度xkcd强烈建议。

利用Troy Hunt的我是否已经拥有API检查用户密码,以防公共数据泄露中泄露的密码。

第六部分:更多-或:防止快速射击登录尝试

首先,看看数字:密码恢复速度-您的密码可以保留多长时间

如果您没有时间浏览该链接中的表,请参见以下列表:

  1. 它需要几乎没有时间破解弱密码,即使您使用算盘破解密码也是如此

  2. 它需要几乎没有时间破解包含9个字母数字的密码不区分大小写

  3. 它需要几乎没有时间破解复杂的,符号,字母和数字,大小写密码少于8个字符(台式PC可以在几天甚至几小时内搜索整个键空间,最多7个字符)

  4. 但是,即使要破解6个字符的密码,也要花费大量时间,如果您每秒只能尝试一次!

那么我们可以从这些数字中学到什么呢?嗯,很多,但我们可以专注于最重要的部分:防止大量快速启动的连续登录尝试(即蛮力攻击)实际上并不那么困难。但是要防止它并不像看起来那么容易。

一般而言,您有三种选择都可以有效抵抗暴力攻击(和字典攻击,但是由于您已经在使用强密码策略,因此这不应该成为问题):

  • 呈现一个验证码N次尝试失败后(令人讨厌并且经常无效-但我在这里重复一遍)

  • 锁定账户并且在N次失败尝试后要求进行电子邮件验证(这是拒绝服务攻击等待发生)

  • 最后,登录限制:即,在N次失败尝试之后设置两次尝试之间的时间延迟(是的,DoS攻击仍然可能,但是至少它们发生的可能性要小得多,启动起来要复杂得多)。

最佳做法1:短时间延迟随失败尝试次数的增加而增加,例如:

  • 1次尝试失败=无延迟
  • 2次尝试失败= 2秒延迟
  • 3次失败尝试= 4秒延迟
  • 4次失败尝试= 8秒延迟
  • 5次失败尝试= 16秒延迟
  • 等等

DoS攻击此方案非常不切实际,因为最终的锁定时间比以前的锁定时间之和略大。

澄清一下:延迟是将响应返回到浏览器之前的延迟。这更像是超时或不应期,在此期间完全不会接受或评估对特定帐户或特定IP地址的登录尝试。也就是说,正确的凭据不会在成功登录后返回,并且错误的凭据也不会触发延迟增加。

最佳做法2:中等长度的时间延迟,在N次失败的尝试后生效,例如:

  • 1-4次失败尝试=无延迟
  • 5次尝试失败=延迟15-30分钟

DoS攻击此方案将是不切实际的,但肯定是可行的。同样,可能需要注意的是,如此长的延迟对于合法用户可能非常烦人。健忘的用户会不喜欢您。

最佳做法3:结合两种方法-固定的短时延,在N次失败的尝试后生效,例如:

  • 1-4次失败尝试=无延迟
  • 5次以上失败尝试= 20秒延迟

或者,随着固定上限的增加,延迟增加,例如:

  • 1次失败尝试= 5秒延迟
  • 2次尝试失败=延迟15秒
  • 3次以上尝试失败= 45秒延迟

该最终方案来自OWASP最佳实践建议(必读列表中的链接1),即使被认为是限制性的,也应被视为最佳实践。

根据经验,我会说:密码策略越强,对用户进行延迟的麻烦就越少。如果您需要强壮的(区分大小写的字母数字+所需的数字和符号)9个以上的字符密码,则可以在激活限制之前为用户提供2-4次无延迟的密码尝试。

DoS攻击这种最终的登录限制方案将是非常不切实际的。最后,始终允许持久(cookie)登录(和/或经过验证码验证的登录表单)通过,因此合法用户甚至都不会被延迟在攻击进行中。这样,非常不切实际的DoS攻击就变成了非常不切实际的攻击。

此外,对管理员帐户进行更积极的限制是很有意义的,因为这些是最有吸引力的切入点

第七部分:分布式蛮力攻击

顺便说一句,更高级的攻击者将尝试通过“传播其活动”来规避登录限制:

  • 在僵尸网络上分发尝试以防止IP地址标记

  • 他们不会选择一个用户并尝试使用50.000个最常用的密码(由于我们的限制而无法使用),而是选择最常见的密码并针对50.000个用户尝试使用。这样,它们不仅绕过了诸如CAPTCHAs和登录限制之类的最大尝试措施,而且成功的机会也增加了,因为最常见的数字1的可能性远大于49.995。

  • 间隔每个用户帐户的登录请求,例如相隔30秒,以潜入雷达

在这里,最佳做法是记录系统范围内失败的登录数,并以网站错误登录频率的运行平均值作为基础,然后对所有用户强加上限。

太抽象了?让我改一下:

假设您的网站在过去3个月中平均每天有120次错误登录。使用该值(运行平均值),您的系统可能会将全局限制设置为该值的3倍-即24小时内360次失败尝试。然后,如果所有帐户的失败尝试总数在一天之内超过该次数(甚至更好,监视加速速度并以计算出的阈值触发),它将激活系统范围的登录限制-这意味着所有用户的延迟很短(不过,除了Cookie登录名和/或备用CAPTCHA登录名之外)。

我还发布了一个问题有关如何避免棘手的pitfals的更多详细信息和非常好的讨论抵制分布式暴力攻击

第八部分:两方面身份验证和身份验证提供程序

凭据可能受到破坏,无论是利用漏洞,写下或丢失密码,笔记本电脑上的钥匙被盗,还是用户在登录网站时输入登录名。可以使用两因素身份验证进一步保护登录,该因素使用带外因素,例如从电话,SMS消息,应用程序或软件狗接收到的一次性代码。几个提供程序提供两因素身份验证服务。

身份验证可以完全委派给单点登录服务,其他提供商在该处处理收集凭据。这将问题推送到受信任的第三方。 Google和Twitter均提供基于标准的SSO服务,而Facebook提供类似的专有解决方案。

关于Web身份验证的必读链接

  1. OWASP身份验证指南/OWASP认证备忘单
  2. Web上客户端身份验证的注意事项(麻省理工学院的研究论文)
  3. 维基百科:HTTP cookie
  4. 用于后备身份验证的个人知识问题:Facebook时代的安全性问题(非常可读的伯克利研究论文)
来源
Translate

权威文章

发送凭证

唯一安全地发送凭据的实用方法是使用SSL协议。使用JavaScript哈希密码是不安全的。客户端密码哈希的常见陷阱:

  • 如果客户端和服务器之间的连接未加密,那么您所做的一切就是容易受到中间人攻击。攻击者可以替换传入的javascript来破坏哈希或将所有凭据发送到其服务器,他们可以侦听客户端的响应并完美地模拟用户等。等等。具有受信任证书颁发机构的SSL旨在防止MitM攻击。
  • 服务器收到的哈希密码为不那么安全如果您不执行其他额外的服务器工作。

还有另一种安全方法称为建议零售价,但已申请专利(尽管它是免费许可),几乎没有可用的良好实现。

储存密码

永远不要将密码以明文形式存储在数据库中。即使您不在乎自己网站的安全性,也不会。假设您的某些用户将重复使用其在线银行帐户的密码。因此,存储哈希密码,然后丢弃原始密码。并确保密码未显示在访问日志或应用程序日志中。 OWASP建议使用Argon2作为新应用程序的首选。如果此功能不可用,则应改用PBKDF2或scrypt。最后,如果以上都不可用,请使用bcrypt。

散列本身也不安全。例如,相同的密码意味着相同的哈希值-这使哈希查找表成为一次破解大量密码的有效方法。而是存储咸的哈希。盐是哈希之前附加在密码上的字符串-每个用户使用不同的(随机)盐。 salt是一个公共值,因此您可以将它们与哈希一起存储在数据库中。看到这里有关此的更多信息。

这意味着您无法向用户发送其忘记的密码(因为您只有哈希值)。除非您对用户进行了身份验证,否则请不要重置用户密码(用户必须证明他们能够阅读发送到已存储(并经过验证)的电子邮件地址的电子邮件。)

安全问题

安全问题是不安全的-避免使用它们。为什么?任何安全问题都可以解决,密码更好。读第三部分:使用秘密问题@Jens Roland答案在此Wiki中。

会话cookie

用户登录后,服务器向用户发送会话cookie。服务器可以从cookie中检索用户名或id,但是没有其他人可以生成这样的cookie(TODO解释机制)。

Cookies可以被劫持:它们仅与客户端计算机其余部分和其他通信一样安全。可以从磁盘读取它们,嗅探网络流量,通过跨站点脚本攻击解除攻击,从有毒的DNS钓鱼,因此客户端将cookie发送到错误的服务器。不要发送持久性cookie。 Cookies应该在客户端会话结束时关闭(浏览器关闭或离开您的域)。

如果您想自动登录用户,则可以设置一个持久性cookie,但是它应与全会话cookie不同。您可以设置用户已自动登录并需要真正登录才能进行敏感操作的其他标志。这在想要为您提供无缝的,个性化的购物体验但仍保护您的财务详细信息的购物网站中很受欢迎。例如,当您再次访问亚马逊时,他们会向您显示一个看起来像您已登录的页面,但是当您下订单(或更改您的送货地址,信用卡等)时,他们会要求您确认你的密码。

另一方面,诸如银行和信用卡之类的金融网站仅具有敏感数据,不应允许自动登录或低安全性模式。

外部资源清单

来源
Translate

首先,强烈警告此答案并非最适合此确切问题的答案。绝对不是最好的答案!

我会继续提及Mozilla的提议浏览器ID(或更准确地说,验证电子邮件协议),本着寻找将来升级到更好的身份验证方法的精神。

我将以这种方式总结一下:

  1. Mozilla是一家非营利组织,价值观与找到该问题的好的解决方案非常吻合。
  2. 当今的现实是,大多数网站都使用基于表单的身份验证
  3. 基于表单的身份验证有一个很大的缺点,那就是增加了以下风险:网络钓鱼。要求用户将敏感信息输入由远程实体控制的区域,而不是由其用户代理(浏览器)控制的区域。
  4. 由于浏览器是隐式信任的(用户代理的整个想法是代表用户执行操作),因此它们可以帮助改善这种情况。
  5. 阻碍进展的主要力量是部署僵局。解决方案必须分解为可自行提供一些增量收益的步骤。
  6. 表示互联网基础结构中内置的身份的最简单的分散方法是域名。
  7. 作为表示身份的第二层,每个域管理自己的一组帐户。
  8. 表格“帐户@“域”简明扼要,并得到各种协议和URI方案的支持。当然,这种标识符最普遍地被认为是电子邮件地址。
  9. 电子邮件提供商已经是事实上的在线主要身份提供商。如果可以证明您控制了该帐户的关联电子邮件地址,那么当前的密码重置流程通常可以让您控制一个帐户。
  10. 提出“已验证电子邮件协议”是为了提供一种基于公钥加密的安全方法,用于简化向域B证明您在域A上拥有帐户的过程。
  11. 对于不支持“已验证电子邮件协议”的浏览器(当前所有浏览器),Mozilla提供了一个垫片,该垫片在客户端JavaScript代码中实现该协议。
  12. 对于不支持“已验证电子邮件协议”的电子邮件服务,该协议允许第三方充当受信任的中介,声称他们已经验证了用户对帐户的所有权。拥有大量这样的第三方是不理想的;此功能仅旨在允许升级路径,并且电子邮件服务本身最好提供这些声明。
  13. Mozilla提供了自己的服务,像这样一个受信任的第三方一样工作。实施“已验证电子邮件协议”的服务提供商(即依赖方)可以选择是否信任Mozilla的主张。 Mozilla的服务使用传统的发送带有确认链接的电子邮件的方式来验证用户的帐户所有权。
  14. 当然,服务提供商除了可能希望提供的其他任何认证方法外,还可以选择提供此协议。
  15. 此处寻求的最大的用户界面好处是“身份选择器”。当用户访问网站并选择进行身份验证时,他们的浏览器会向他们显示选择的电子邮件地址(“个人”,“工作”,“政治活动”等),以供他们在该网站中使用自己的身份。
  16. 寻求这一工作的另一大用户界面优势是帮助浏览器更多地了解用户的会话-他们目前主要是谁登录的-因此它可能会在浏览器镶边中显示。
  17. 由于该系统的分布式性质,它避免了锁定到Facebook,Twitter,Google等主要网站的情况。任何人都可以拥有自己的域,因此可以充当自己的身份提供者。

这并不是严格的“网站基于表单的身份验证”。但是,这是从当前基于表单的身份验证规范过渡到更加安全的工作:浏览器支持的身份验证。

来源
Translate

我只是以为我会分享这个发现很好的解决方案。

我称之为虚拟领域(尽管我还没有发明这个,所以不要相信我)。

简而言之:您只需将其插入您的<form>并在验证时检查它是否为空:

<input type="text" name="email" style="display:none" />

诀窍是让机器人认为必须将数据插入必填字段,这就是为什么我将输入命名为“电子邮件”的原因。如果您已经有一个正在使用的名为email的字段,则应尝试为虚拟字段命名,例如“ company”,“ phone”或“ emailaddress”。只需选择一些您不需要的东西,听起来像人们通常会觉得合乎逻辑的东西可以填写到Web表单中。现在隐藏input使用CSS或JavaScript / jQuery的字段-最适合您的-设置输入typehidden否则,该机器人将不会为之迷。

在验证表单(客户端或服务器端)时,请检查您的伪字段是否已填写,以确定它是由人工发送的还是由机器人发送的。

例:

如果是人类:用户将看不到虚拟字段(在我的情况下为“电子邮件”),也不会尝试填充它。因此,发送表单后,虚拟字段的值仍应为空。

如果是机器人:机器人将看到一个类型为text和一个名字email(或您所谓的名称),并在逻辑上尝试用适当的数据填充它。不管您是否使用一些精美的CSS设置输入表单的样式,Web开发人员始终都会这样做。无论虚拟字段中的值是多少,只要它大于0字符。

我在留言簿上结合使用了这种方法验证码,此后我再也没有看到过垃圾邮件。我以前使用过仅CAPTCHA的解决方案,但最终,它每小时产生大约5封垃圾邮件。在表单中添加虚拟字段已停止(至少到现在为止)所有垃圾邮件的出现。

我相信这也可以用于登录/身份验证表单。

警告:当然,这种方法不是100%可靠的。可以将Bot编程为忽略具有以下样式的输入字段display:none适用于它。您还必须考虑使用某种形式的自动完成功能(例如大多数浏览器都内置了这些功能)来为他们自动填写所有表单字段的人。他们也可能会选择一个虚拟字段。

您还可以通过使虚拟字段可见但在屏幕边界之外来稍微改变一下,但这完全取决于您。

有创造力!

来源
Translate

我不认为上面的答案是“错误的”,但是有很多未涉及的身份验证(或者重点是“如何实现cookie会话”,而不是“可用的选项和交易方式”) -offs”。

我建议的修改/答案是

  • 问题更多在于帐户设置,而不是密码检查。
  • 使用双重身份验证比使用更聪明的密码加密方法安全得多
  • 请勿尝试实施自己的登录表单或密码存储在数据库中,除非所存储的数据在创建帐户和自行生成时即没有价值(例如,像Facebook,Flickr等)

    1. 摘要式身份验证是所有主要浏览器和服务器都支持的基于标准的方法,即使通过安全通道也不会发送密码。

这避免了任何“会话”或cookie的需要,因为浏览器本身每次都会重新加密通信。这是最“轻巧”的开发方法。

但是,除了公共的低价值服务外,我不建议这样做。这是上述其他一些答案的一个问题-不要尝试重新实现服务器端身份验证机制-大多数主要浏览器都已解决此问题,并支持该问题。不要使用cookie。不要将任何内容存储在您自己的手动数据库中。只需询问每个请求,该请求是否已通过身份验证。其他所有内容都应由配置和第三方可信软件支持。

所以...

首先,我们混淆了最初创建帐户(使用密码)与随后重新检查密码的混淆。如果我是Flickr,并且是第一次创建您的网站,则新用户可以访问零值(空白网站空间)。我真的不在乎创建帐户的人是否在撒谎。如果我要创建医院内部网/外部网的帐户,则该值存在于所有医疗记录中,因此我do关心帐户创建者的身份(*)。

这是非常非常困难的部分。的只要体面的解决方案是信任的网络。例如,您以医生身份加入医院。您创建一个网页,其中托管了您的照片,护照号码和公钥,并使用私钥对它们进行了哈希处理。然后,您访问医院,系统管理员查看您的护照,查看照片是否与您匹配,然后使用医院私钥对网页/照片哈希进行哈希处理。从现在开始,我们可以安全地交换密钥和令牌。信任医院的人也一样(有秘密调味料BTW)。系统管理员还可以给您一个RSA加密狗或其他两因素身份验证。

但这是一个很多麻烦,而且不是Web 2.0。但是,这是创建可以访问非自行创建的有价值信息的新帐户的唯一安全方法。

  1. Kerberos和SPNEGO-与受信任的第三方的单点登录机制-基本上,用户可以针对受信任的第三方进行验证。 (注意,这绝不是不值得信赖的OAuth)

  2. 建议零售价-无需受信任的第三方即可进行的巧妙密码验证。但是在这里,我们进入了“使用双重身份验证的安全性,即使这样更昂贵”

  3. SSL协议客户端-向客户端提供公钥证书(在所有主要浏览器中均受支持-但对客户端计算机的安全性提出了疑问)。

最后,这是一个权衡–安全漏洞的成本与实施更安全方法的成本是什么?有一天,我们可能会看到公钥基础设施被广泛接受,因此不再拥有滚动式身份验证表单和数据库。一天...

来源
Translate

进行哈希处理时,请勿使用MD5之类的快速哈希算法(存在许多硬件实现)。使用类似SHA-512的东西。对于密码,散列越慢越好。

创建散列的速度越快,任何暴力破解检查程序都可以越快地工作。较慢的哈希值将减慢蛮力。慢速哈希算法将使强行破解对于较长的密码(8位数字以上)不切实际

来源
Translate

关于现实的密码强度估计的好文章是:

Dropbox技术博客»博客存档»zxcvbn:现实的密码强度估算

来源
Translate

关于身份验证系统,我最喜欢的规则是:使用密码短语,而不是密码。容易记住,难以破解。更多信息:编码恐怖:密码与密码短语

来源
Yehudi Lee
Translate

基于深度防御,我想添加一个建议。对于管理员,您不需要具有与普通用户相同的auth&auth系统。您可以在单独的url上拥有单独的登录表单,以对授予高特权的请求执行单独的代码。这可能会给普通用户带来很多痛苦的选择。我曾经使用过的一种方法是实际上对管理员访问的登录URL进行加密,然后将新的URL发送给管理员。立即停止任何蛮力攻击,因为您的新URL可能非常困难(非常长的随机字符串),但是您的管理员用户唯一的不便便是关注其电子邮件中的链接。攻击者甚至不知道发布到哪里。

来源
Page Lee
Translate

我不知道最好是作为答案还是作为评论来回答。我选择了第一个选项。

关于poing第四部分:忘记的密码功能在第一个答案中,我将重点介绍定时攻击。

在里面记住密码表单,攻击者可能会检查电子邮件的完整列表,并检测哪些电子邮件已注册到系统(请参阅下面的链接)。

关于“忘记密码”表格,我想补充一点,这是一个很好的主意,它可以通过一些延迟功能来使成功查询与失败查询之间的时间相等。

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

来源
Translate

我想添加一个非常重要的评论:-

  • “在一个企业, 网络设置”,则上述大多数(如果不是全部)可能都不适用!

许多公司部署“仅供内部使用”的网站,这些网站实际上是恰好通过URL实现的“企业应用程序”。这些网址可以(据说...)仅在“公司内部网络”中解决。(哪个网络神奇地包含了所有连接VPN的“公路战士”。)

当用户忠实地连接到上述网络时,其身份(“身份验证”)已经[已经...]众所周知,并且得到他们的许可(“授权”)做某些事情……例如“访问本网站”。

可以通过多种不同的技术(例如LDAP)提供此“身份验证+授权”服务。(Microsoft OpenDirectory)或Kerberos。

从您的角度来看,您只是知道这一点:任何人合法结束您网站的人必须伴随[环境变量神奇地包含...]一个“令牌”。 (没有这样的令牌必须是404 Not Found.)

代币的价值对您来说毫无意义,但,如果需要,“适当的方式存在”,您的网站可以通过该方式“ [权威性地]向知道(LDAP等)的人询问”和每个(!)您可能有的问题。换句话说,你发挥自己的作用任何“本土逻辑”。取而代之的是,您查询“权威”并暗中信任其裁决。

嗯...是相当摆脱了“狂野而喧嚣的互联网”。

来源
Leo Lee
Translate

采用OpenID连接要么用户管理的访问.

因为没有什么比根本没有做更有效率。

来源