内联网 Web 应用程序的 http 或 https 身份验证
我正在开发一个 Intranet 应用程序，我想进行安全身份验证。
一种方法是使用“https”。问题是服务器没有受信任的证书，因此对客户端来说有点烦人，因为浏览器不信任证书并抱怨可怕的消息。
但它可以与“摘要式访问身份验证”结合使用
使用http会泄露用户密码， 思考？
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这些是（您）我们的选项：
如果您主要拥有 Windows 主机，您可以 分发证书
使用组策略连接到客户端计算机微软
文档
并以这种方式使用您自己的自签名证书。
经历安装的麻烦和警告
手动正确证书或允许自签名证书。
用户体验不佳。
您使用正确的域名、真实的证书和混乱的 DNS
配置，其中 www.mycompany.com 解析为外部站点，
但 wiki.mycompany.com 是一个内部站点（但是请不要将内部站点
外部可见的 DNS 记录中 wiki.mycompany.com 的地址！）
您根本不使用 HTTPS，而是使用 HTTP。可能通过发明你的
登录页面拥有自己的安全性（哎呀！）
它们都很糟糕。
特别是如果您想要分发企业级现场应用程序，并且您事先不知道客户的网络和 DNS 配置。
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
自 2015 年 11 月起，您可以'不购买内部域的证书，据我所知，唯一的选择是在客户端上预安装证书。这不是一个很好的解决方案。
如果您想保持内部域的私密性，另一种方法是创建一个公共域：mycompany.com，然后在内部运行您自己的 DNS 服务器来解析您的内部域：
accounting.internal.mycompany.com、hr.internal.mycompany.com等。那么我相信您可以使用mycompany.com的通配符证书。我还没有测试过这个解决方案。As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains:
accounting.internal.mycompany.com,hr.internal.mycompany.comand so on. Then I believe you can use a wildcard certificate formycompany.com. I haven't tested this solution.2023 更新
云供应商允许您自动为非公共域配置 SSL 证书（例如 AWS 证书管理器）。还有自托管的私有证书管理器，例如这个。
强烈建议使用用于 Intranet/内部云连接的 SSL，并且 PCI 和 SOC 2 认证可能需要 SSL。
2009答复
购买域名和可信证书？如果你货比三家的话，它们真的不再那么贵了。
话虽如此，摘要访问身份验证对于身份验证来说相当安全。使用 http 而不是 https，您通过网络发送的所有信息都将是纯文本，即使密码不是纯文本。任何可以将笔记本电脑插入运行 WireShark 等应用程序的 Intranet 的人都可以查看来回发送的所有信息。如果您关心信息不被泄露，http 将无法满足您的需求。
2023 Update
Cloud vendors allow you to automatically provision SSL certificates for non-public domains (e.g. AWS Certificate Manager). There are also self-hosted private certificate managers such as this one.
SSL for intranet/internal cloud connections is strongly recommended and may be required for PCI and SOC 2 certification.
2009 Answer
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
您有以下选择：
购买受信任的证书。
或者，生成您自己的根证书，将其安装在所有 Intranet 计算机上的浏览器中（您应该能够执行此操作，因为它是 Intranet），生成使用您自己的根证书签名的您自己的服务器证书。这实际上是公司经常做的事情。
注意：如果您想要表单身份验证（带有用户、密码的 HTML 表单、使用应用程序视觉样式的登录页面、更好的错误密码错误报告、可能的附加功能，例如“记住我”），摘要访问身份验证没有帮助或“忘记密码”）。
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
如果您需要完全安全，您应该购买 SSL 证书。
从您提供的 wiki 链接来看：
缺点
摘要式访问身份验证旨在作为一种安全权衡；它的目的是取代非常弱的未加密的 HTTP 基本访问身份验证。但是，它并不是要取代强身份验证协议，例如公钥或 Kerberos 身份验证。
我想这就是你的答案:)
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)