基于证书的身份验证与用户名和密码身份验证

#1 楼

1.用户很笨

密码是一种适合用户记忆的东西，用户可以选择它。由于身份验证是关于远程验证用户的物理身份（从验证者的角度来看），因此该过程中必然涉及用户行为-但是，密码依赖于用户部分，这在处理安全性方面最为糟糕，即他的大脑。用户根本不了解密码熵的含义。我不是在为此责怪他们：这是一个技术主题，一个专业，很快就无法现实地变成“常识”。另一方面，物理令牌的安全性更“有形”，并且普通用户可以非常熟练地使用它。进化论者会说，在过去的一百万年中，人类一直是人类的积极选择，因为那些无法握住火石工具的人无法生存下来，无法生育后代。用户如何思考密码的模型-如果仅仅是因为这些用户也去看电影。大敌人总是有一个短密码，只是喜欢吹牛，并尽可能地散布线索。而且，英国秘密特工总是会及时猜出密码，以停用植入在女王最喜欢的花坛下的聚变炸弹。电影投射出扭曲，夸张的现实，但它们仍然代表了普通用户操作的心理基线：他们将密码设想为通过比攻击者更“机智”来提供安全性。而且，大多数情况都是这样。

可以通过强制性规则（至少八个字符，至少两个数字，至少一个大写字母和一个小写字母...）来改善“密码强度”，但是这些规则被用户视为负担，有时甚至是对其固有的自由施加了无法忍受的限制-因此，用户开始以传统的方式在粘贴纸上写下密码，以极大的创造力来与规则抗争。

相反，密码增强通常会适得其反。

另一方面，用户证书暗指一个存储系统，如果该系统是用户随身携带的房屋或汽车的物理设备，密钥，然后安全性（部分）取决于普通用户对物理对象安全性的管理程度，他们通常会做得很好。至少比选择正确的密码要好。因此，这是证书的一大优势。

2。证书使用非对称加密

“不对称”是关于角色分离。使用密码，任何验证密码的人都会在某个时候知道密码或等同于密码的数据（当然，对于PAKE协议，这并不完全正确）。对于用户证书，证书由证书颁发机构颁发，证书颁发机构保证物理身份和加密公钥之间的链接。验证者可以是一个独立的实体，可以验证这样的链接并将其用于对用户进行身份验证，而不必冒充用户。

总而言之，证书的重点是：将定义用户数字身份的用户（即，进行从物理身份到计算机世界的映射的实体）与对用户进行身份验证的用户区分开来。

这为带来不可否认性的数字签名开辟了道路。这尤其使从在线客户那里获得金融订单的银行感兴趣：他们需要对客户进行身份验证（这是我们正在谈论的钱，这是非常严重的事情），但他们希望对订单有令人信服的追踪-从某种意义上说：法官将被说服。仅凭身份验证，银行就可以确保它正在与正确的客户进行对话，但是不能向第三方证明这一点。银行可能会建立虚假的连接记录，因此对于声称由银行本身构成陷害的客户而言，这是没有武器的。即使用户拥有证书，数字签名也不会立即可用；但是，如果用户可以使用证书进行身份验证，那么大多数艰苦的工作就已经完成。

密码本身也容易受到网络钓鱼攻击，而用户证书则并非如此。正是由于不对称：证书使用从未涉及向对等方透露任何秘密数据，因此冒充服务器的攻击者无法以这种方式学习任何有价值的信息。

3。证书很复杂

部署用户证书很复杂，因此很昂贵：


颁发和管理证书完全是蠕虫，任何PKI供应商都可以告诉您（的确，我确实告诉过您）。特别是撤销管理。 PKI大约是5％的加密和95％的程序。可以做到，但不便宜。
用户证书意味着用户在其“专有访问”下以某种方式存储其私钥。这可以通过软件（现有的操作系​​统和/或Web浏览器可以做到）或使用专用硬件来完成，但是两种解决方案都有其自身的可用性问题。将会出现的两个主要问题是：1）用户丢失了密钥，并且2）攻击者获得了密钥的副本。软件存储使密钥丢失成为一个可能的问题（受故障硬盘的支配），并且在多个系统（例如台式计算机和iPad）之间共享密钥意味着一些手动操作，这些操作不太可能受到攻击者的良好保护。硬件令牌暗示着设备驱动程序的整个混乱局面，甚至可能更糟。
用户证书意味着客户端上相对复杂的数学运算；即使对于贫乏的奔腾II来说，这也不是问题，但是您将无法使用通用网站中某些Javascript的证书。证书需要客户端软件的积极配合，并且说，在这种情况下，该软件在人机工程学上往往不理想。一般用户通常可以学习使用客户端证书来建立与网站的HTTPS连接，但是以学习如何忽略偶尔的警告弹出窗口为代价，这使他们更容易受到某些攻击（例如，攻击者尝试进行的主动攻击）为其提供伪造的服务器证书。

另一方面，基于密码的身份验证真的很容易集成到任何地方。当然，搞砸同样容易。但至少并不一定涉及一些不可压缩的额外费用。

摘要

用户证书允许角色分开，而密码则不能。他们这样做是以增加大量实施和部署问题为代价的，这使它们变得昂贵。但是，密码由于适合人脑而保持便宜，这从本质上暗示了低安全性。密码的安全性问题可以通过一些技巧（最多包括PAKE协议）来缓解，并且最重要的是，在出现问题时归咎于用户（我们知道普通用户不能选择安全的密码，但是任何不幸的事情都会仍然是他的错-银行就是这样做的。）

#2 楼

用户名/密码


专业版：易于部署-只需一些代码和安全的数据存储。根据安全策略，可以自动生成密码或强制新用户创建密码。
专业版：易于管理-密码重置（对于某些安全策略）可以通过自动化工具完成
缺点：良好的安全性，密码应尽早且经常重置。用户忘记或无法更改密码既有安全风险，也有使用麻烦。 ：密码数据存储是一个弱点-如果入侵者获得了密码存储，他就会担负重任。
缺点：密码传输的所有部分都可能导致暴露-在本地存储密码以便于使用的网站，内部服务器以明文形式传输的组件，COTS产品中的日志文件以明文形式存储密码。由于秘密是传输的一部分，因此您的安全性仅与最弱的链接一样强-防止泄漏会花费很多精力，并且对用户和系统开发人员都要求。

证书：


专业版：不需要传输秘密。私钥证明不包含任何秘密信息-减轻了各种存储/传输薄弱点。
Pro：由受信方（CA）颁发，它允许集中管理系统来管理多个应用程序的状态。如果证书变坏，则可以将其吊销。除非使用共享ID，否则必须分别为每个系统修复密码破解问题。
优点：不可否认性更强-在大多数密码系统中，在创建帐户之前对用户进行初始身份验证的方式非常薄弱，密码重置机制可以提供另一个可能的可否认性。通过多种形式的证书发行，用户很难说不是他们。请注意-您仍然仅能满足CA的签发政策。
专业版：除了提供身份验证外，还可以提供更多目的-还可以提供完整性和机密性。
缺点：仍然需要密码/密码-几乎然后使用PIN解锁任何私钥对存储机制。智能卡可以具有防篡改和锁定功能以防止暴力破解，但这不能解决用户将其PIN写在插有卡的计算机旁边的便笺上的事实。有时，使用PKI会以较小的规模再次出现密码问题。
缺点：基础架构的复杂性-设置PKI并非易事，而且在部署和维护方面通常都非常昂贵，因此只能用于大型/昂贵的系统。
缺点：证书状态报告和更新并不容易-撤消已损坏的用户凭据，因为基础架构的规模和复杂性很麻烦。通常，CA生成可能会或可能不会在OCSP服务器中设置的CRL。然后，每个应用程序都应检查每个登录名的CRL或OCSP状态。这在报告PKI凭据被破坏的时间与依赖该凭据的系统实际开始拒绝访问的时间之间，给系统带来了各种时间延迟。可以加快状态更新的速度-但会增加系统复杂性的成本。

其他一些注意事项：

证书应具有较短的生存期，并且可以撤消，而在管理策略要求更改密码之前，密码的生存期将更长。它...

我不同意这个前提。在我支持密码和PKI的系统上，密码更新要求的策略比证书颁发的策略短得多。撤销是蠕虫的另一种方式-私钥泄露的可能性较小。由于私钥数据没有通过系统传输，因此通常认为暴露于此数据的风险远低于暴露密码的风险。出于实用目的，密码被认为具有较短的使用寿命。

我也很想知道密码容易受到什么攻击，例如到目前为止提到的是蛮力的，而证书却没有提及……XSRF呢？

你在这里混合苹果和橙子。蛮力攻击可能是对两种身份验证凭证的可行攻击-但是XSRF是对基础类型应用程序的攻击，无论身份验证机制如何，这种攻击都是可能的。除非您的意思是因为将使用某种文本界面输入用户名/密码，否则它们可能易于在该界面上进行跨站点脚本编写。

一般而言（很抱歉，我缺乏官方术语-我通常会查找典型的攻击术语，但是我的时间比较短）：密码更容易被暴力破解。但是，证书上足够小的密钥大小也是可以暴力破解的，而暴力破解攻击密钥的能力会随着CPU功能的增强而增长，从而迫使竞争者随着密钥大小的增加而竞争。
有根据的猜测-使用密码更容易将密钥空间缩小到合理的猜测范围，对于大多数非对称密钥算法而言，这并不明显，尽管RSA算法中存在较弱的密钥，所以在一定程度上取决于大小攻击者是一个加密书呆子。
社会工程-无论哪种方式都可行，尽管使用存储在硬件中的证书，您不仅需要控制用户的PIN，而且还必须控制存储其密钥的硬件。
内部攻击-从系统内部获取凭据，然后使用它们来模拟合法用户-取决于。如果密码存储不安全，那么对于基于密码的系统，这样做更为可行。但是，如果您可以控制CA，则可以向自己颁发合法证书，然后取决于访问的控制方式。
中间人-取决于-如果密码，中间人可以截取密码不会通过绕过他的加密机制在传输过程中进行加密。使用SSL / TLS可以做到这一点。但是，根据PKI的使用方式，中间的人也可以拦截PKI传输的某些部分。没有中间值或时间戳的PKI签名容易受到中间人的复制攻击-只要没有办法确定该消息是及时的还是唯一的，他就可以重新发送被拦截的消息。

#3 楼

我同意斯蒂芬的观点。您提出了一个很难研究的问题，因为该问题通常不是一个与另一个之间的比较。理解为什么两者同时存在且通常不相互评价的一个好方法是专注于用法。证书与机器级别的密钥库绑定，因此非常适合预先计划的特定机器之间的机器对机器认证。密码非常适合人们，因为我们是移动的，并且倾向于以难以预先预测的方式从众多系统进行身份验证。因此，证书是预先设计的基于硬件的身份验证的典型代表，而密码则适合基于移动湿件的身份验证。智能卡是将基于证书的身份验证添加到移动人员的一种很好的方法，也是流程的另一个因素。

#4 楼

用户名和密码
关于您所知道的一切。您正在提供一个密码字以通过该服务进行身份验证。
这意味着，如果它在流中被拦截，则可以使用它。使用加密使这种可能性很小，但仍然可以实现。有人可以在中间进行操作以获取密码或接管获得身份验证的计算机。

用户名和密码可以随时在任何计算机上使用。如果安全很重要，那么这是一件坏事，而可访问性则很重要。对于银行来说，这很糟糕。对于Facebook，这确实不重要。


证书

证书要复杂一些。服务器将数据发送到客户端，客户端对数据进行签名并发回。这意味着服务器在任何时候都不知道私钥，因此，当中间的人或服务器的接管者会导致他们获得访问权限时，他们就没有您的密钥。
使用证书很麻烦。您不记得它们了，它们可能会被盗。



最好的系统是组合。您在密钥上输入了密码，因此您可以进行两步验证。您知道的东西（密码）和您拥有的东西
（密钥）。但是，安全层越多，痛苦就越大。这是所有安全性的巨大折衷。

#5 楼

密码通常可以强制使用，也可以进行社会工程处理，因为正如密码所有者必须记住的那样，它通常比秘密密钥简单得多。 -对于RSA，则不能强制使用2048或4096位）。对需要基于公钥的身份验证的系统进行身份验证的唯一方法是，首先获取对其他计算机的访问权，以获取私钥。这给攻击带来了更高的复杂性。社会工程让一个人透露自己的密码将无济于事，因为该密码只会解密其私钥，而不是直接授予他对目标系统的访问权限。进行社会工程设计以使一个人将其私钥与密码一起泄露的可能性可能更大。

此外，密码是通过网络从用户的计算机传输到用户希望使用的系统的采用。私钥既不以明文形式也不以加密格式通过网络传输；而是只传输公钥。

#6 楼

您似乎忘记了网页可以同时使用证书和密码。
如果拥有证书的用户来了，门就会打开。
如果他没有证书，则必须使用名称登录和密码一如既往。

这样，有兴趣的用户将获得其证书，所有其他用户都将使用旧方法。

#7 楼

我想添加一个选项-一次性密码设备。我同意其他人对证书和密码的优缺点的看法-OTP设备需要一些后端组件才能运行，但我认为可以将它们集成在一起而没有很多麻烦（Active Directory有点不同，但是其他系统不太难）。

密码和一次性密码的组合非常有效。您可以使用更简单的解决方案，例如带有密码（需要USB或NFC连接）的Yubikey或显示的代码卡。

两个选项都易于添加到基于Linux的操作中。如果要在Active Directory中执行此操作，则需要购买软件来处理代码并将其安装在每台AD服务器上。然后，用户在密码字段的开头输入OTP，然后输入其通常的密码。可以为此开发自己的模块，但是从我所见的角度来看，成本过高。