【问题标题】:What is the difference between Digest and Basic Authentication?摘要和基本身份验证有什么区别?
【发布时间】:2012-03-21 00:47:58
【问题描述】:

DigestBasic 身份验证有什么区别?

【问题讨论】:

    标签: http authentication https basic-authentication digest-authentication


    【解决方案1】:

    摘要式身份验证通过将哈希函数应用于以下内容,以加密形式传递凭据:用户名、密码、服务器提供的 nonce 值、HTTP 方法和请求的 URI。

    而基本身份验证使用 非加密 base64 编码。

    因此,基本身份验证通常只应在提供传输层安全性的情况下使用,例如 https。

    有关所有血腥细节,请参阅RFC-2617

    【讨论】:

    • 基本认证怎么不加密?我用这个网站来解码用户名和密码数据base64decode.org
    • 编码和加密不是一回事。您能够使用该站点对凭据进行解码这一事实表明它们未加密。
    • @Andy “解码凭据”是什么意思?无法解码散列凭据...
    • 对,基本身份验证不使用散列凭据,它们是 base64 编码的。
    • @DotFreelancer 简单来说,加密需要使用特定方法解密的密钥,而编码只需要该方法。如果收到加密消息的人没有密钥,则消息无法恢复(解密)。
    【解决方案2】:

    HTTP 基本访问身份验证

    • 第 1 步:客户端发出信息请求,以纯文本形式向服务器发送用户名和密码
    • 第 2 步:服务器响应所需信息或错误

    基本身份验证使用 base64 编码(非加密)来生成包含用户名和密码信息的加密字符串。 HTTP Basic 不需要通过 SSL 实现,但如果你不这样做,它根本不安全。所以我什至不会接受不使用它的想法。

    优点:

    • 它易于实现,因此您的客户端开发人员要做的工作更少,交付时间也更短,因此开发人员可能更愿意使用您的 API
    • 与 Digest 不同,您可以使用任何您喜欢的加密方法(例如 bcrypt)将密码存储在服务器上,从而使密码更加安全
    • 只需要调用一次服务器即可获取信息,这使得客户端比更复杂的身份验证方法稍快

    缺点:

    • SSL 的运行速度比基本 HTTP 慢,因此这会导致客户端稍慢
    • 如果您无法控制客户端,并且无法强制服务器使用 SSL,则开发人员可能不会使用 SSL,从而导致安全风险

    总结 – 如果您可以控制客户端,或者可以确保它们使用 SSL,那么 HTTP Basic 是一个不错的选择。 SSL的缓慢可以通过只发出一个请求的速度来抵消

    基本身份验证语法

    Value = username:password
    Encoded Value =  base64(Value)
    Authorization Value = Basic <Encoded Value> 
    //at last Authorization key/value map added to http header as follows
    Authorization: <Authorization Value>
    

    HTTP 摘要式访问身份验证
    摘要访问身份验证使用散列(即摘要意味着切成小块)方法来生成加密结果。 HTTP Digest 访问身份验证是一种更复杂的身份验证形式,其工作原理如下:

    • 第 1 步:客户端向服务器发送请求
    • STEP 2 : 服务器响应一个特殊代码(称为n数字仅使用一次),另一个字符串代表@ 987654322@(a hash) 并要求客户端进行身份验证
    • 第 3 步:客户端用这个随机数和用户名、密码和领域(哈希)的加密版本进行响应
    • 第 4 步:如果客户端哈希与他们自己的用户名、密码和领域哈希匹配,则服务器响应请求的信息,否则返回错误

    优点:

    • 没有用户名或密码以明文形式发送到服务器,使得非 SSL 连接比不通过 SSL 发送的 HTTP Basic 请求更安全。这意味着不需要 SSL,这使得每次调用都稍微快了一点

    缺点:

    • 对于需要的每个调用,客户端必须进行 2 次调用,这使得该过程比 HTTP Basic 稍慢
    • HTTP Digest 容易受到中间人安全攻击,这基本上意味着它可能会被黑客入侵
    • HTTP Digest 阻止使用强密码加密,这意味着存储在服务器上的密码可能会被黑客入侵

    总结,HTTP Digest 本质上容易受到至少两种攻击,而使用基于 SSL 的 HTTP Basic 对密码进行强加密的服务器不太可能共享这些漏洞。

    如果您无法控制您的客户端,但是他们可以尝试在没有 SSL 的情况下执行基本身份验证,这比 Digest 安全得多。

    RFC 2069 摘要式访问身份验证语法

    Hash1=MD5(username:realm:password)
    Hash2=MD5(method:digestURI)
    response=MD5(Hash1:nonce:Hash2)
    

    RFC 2617 摘要式访问身份验证语法

    Hash1=MD5(username:realm:password)
    Hash2=MD5(method:digestURI)
    response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
    //some additional parameters added 
    

    sourceexample

    在 Postman 中看起来如下:

    注意:

    • Basic 和 Digest 方案专用于使用用户名和密码进行身份验证。
    • 承载方案专用于使用令牌进行身份验证。

    【讨论】:

    • 在您的 Web 服务器上,即使您无法控制客户端,您是否也不能将所有 http 请求重定向到 https?
    • 更多我想得更多但是我明白你的意思。假设他们通过 http 提交凭据并访问您的网站,您可以重定向,但如果他们点击恶意网站,您将无能为力。
    • 为什么Digest不能在存入数据库前加密密码,取出时解密?
    • 虽然选择的答案更接近问题,但我喜欢这个答案,因为它为我们这些外行人提供了利弊。
    • 优秀的答案,准确并解释了利弊。
    【解决方案3】:

    让我们看看使用Wireshark(分析发送或接收的数据包的工具)两种HTTP身份验证的区别。

    1. Http基本认证

    一旦客户端按照 Web 服务器的要求输入正确的 用户名:密码,Web 服务器就会检查数据库中的凭据是否正确,并授予对资源。

    以下是数据包的发送和接收方式:

    在第一个数据包中,客户端使用资源 - lab/webapp/basicauthPOST 方法填充凭据。作为回报,服务器回复 http 响应代码 200 ok ,即用户名:密码正确。

    现在,在Authorization 标头中,它显示它是Basic 授权,后跟一些随机字符串。此字符串是凭据的编码(Base64) 版本admin:aadd(包括冒号)。

    2 。 Http 摘要身份验证(rfc 2069)

    到目前为止,我们已经看到基本身份验证通过网络以明文形式发送 username:password。但 Digest Auth 使用哈希算法发送密码的 HASH

    这里是显示客户端发出的请求和服务器响应的数据包。

    一旦客户端键入服务器请求的凭据,密码就会使用算法转换为response,然后发送到服务器,如果服务器数据库与客户端给出的响应相同,则服务器授予对资源的访问权限,否则会出现 401 错误。

    在上面的 Authorization 中,response 字符串是使用 Username,Realm,Password,http-method,URINonce 的值计算的,如图所示:

    (包括冒号)

    因此,我们可以看到摘要式身份验证更安全,因为它涉及哈希(MD5 加密),因此数据包嗅探器工具无法嗅探密码,尽管在基本身份验证中,Wireshark 上显示了确切的密码。

    【讨论】:

    • 这应该是公认的答案,因为它为图表提供了更多信息和荣誉。
    • 废话。基本身份验证仅适用于 HTTPS。因此,真正的比较是基于 HTTPS 的基本身份验证与基于 HTTP 的摘要式身份验证。鉴于现在网站正在加密所有流量,您不妨使用基于 HTTPS 的基本身份验证。
    • @Gili 您对加密和身份验证感到困惑。
    【解决方案4】:

    Basic Authentication 使用 base 64 Encoding 生成包含用户名和密码信息的加密字符串。

    摘要式访问身份验证使用散列方法生成加密结果

    【讨论】:

    • base 64 编码不是加密的。
    猜你喜欢
    • 2013-05-16
    • 2016-04-22
    • 2016-04-19
    • 1970-01-01
    • 2011-04-13
    • 1970-01-01
    • 1970-01-01
    • 2020-07-16
    • 2014-10-12
    相关资源
    最近更新 更多