WCF 身份验证/WCF REST 身份验证..不同的方法？
我制作了一个 WCF REST 服务，它使用 OLAP 数据库中的数据，这不是 Microsoft 技术，最终，我想将许多其他 OLAP 数据库连接到一个平台。
经过大量阅读后，WCF REST 的安全性非常令人沮丧，总之，我有 2 个选择，一种是使用基本身份验证，通过网络公开用户名和密码，或者可能更好一点，使用基本身份验证SSL，现在我需要从网络服务器获取不同的证书。或者使用摘要式身份验证，它使用加密的密码并对数据库进行身份验证，这是最好的选择，但就我而言，这是不可能的，因为我没有使用 Microsoft 技术，安全性位于不同的平台上，我无法加密我的密码使用MD5，因为数据库无法读取加密后的密码。
由此得出的结论是，我只能使用 SSL 的基本身份验证，但这是正确的方法吗？我看到很多产品都在做与我类似的事情，当他们登录时，我看不到 https，而只有 http，它们不安全且容易被黑客攻击吗？
我并不是想制作一个防弹网站，而是一个简单的网站，使用基本身份验证太简单了，或者实际上几乎就像泄露了密码，但是使用 https，这是大材小用吗？
因此，在 REST 令人沮丧之后，我们不要使用 REST，而使用普通的 WCF，根据我的阅读，他们有同样的问题。
请给我一些指导。我想我已经输了。
非常感谢
PlayKid
I have made a WCF REST service which consumes data from an OLAP database and it is not Microsoft technology, ultimately, I would like to connect many other OLAP database to a single platform.
And after a lot of reading, the security for WCF REST is very discouraging, in summary, I have 2 choices, one is to use the Basic Authentication which expose username and password over the wire, or maybe a bit better, using Basic Authentication with SSL, now I need to get different certificates from the webserver. Or using Digest Authentication, which use an encrypted password and authenticate against the database, that's the best option, but in my case, it is not possible as I am not using Microsoft technology, the security is on different platform and I cannot encrypt my password using MD5 because the database cannot read the encrypted password.
That concludes me only be able to use Basic Authentication with SSL, but is this the correct way of doing? I see many products out there doing something similar to what I do, when they login, I do not see https, but only http, are they not secure and easy to hack?
I am not trying to make a bullet proof website, but a simple website, using Basic Authentication is too simple, or in fact it's almost like giving away the password, but using https, is that overkill?
So, after REST being that discouraging, let's not use REST, use the normal WCF, from what I have read, they shares the same problem.
Please give me some guidance. I think I have lost.
Many Thanks
PlayKid
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，基本身份验证用于常规网站，是的，如果与 http 一起使用，用户名和密码通常会越过可读行。 https 已经更好了，因为信息是通过线路加密发送的。但实际上，您只会在商业或银行应用程序中看到这种情况。你不能使用MD5，这很遗憾，因为那是一种中间方法。
因此，根据您将公开的应用程序，为了简单起见，使用 http ，或者使用复杂性和安全性更高的 https。
顺便说一句，重大的安全问题通常与 SQL 注入或黑客能够在您的网站上获得一些管理员级别的权限有关。这样，如果您采取必要的预防措施和应对措施，他们就可以获得大量信息，而嗅探您的线路并获取单个用户密码组合相对是无害的。
Often, basic authentication is used for regular websites and yes, the username and password often go over the line readable if used with http. Https is already better, because the information is send encrypted over the line. But in practice, you only see this in place for commercial or banking applications. You cannot use MD5, which is a pitty, because that would be sort of middle-of-the-road approach.
So, depending on the application you will expose, use http for simplicity or https with a bit more complexity and safety.
By the way, big safety problems often have to do with SQL injection or a hacker being able to get some admin level privileges on your site. That way they get acess to a lot of info, while sniffing your line and getting a single user password combination is relatively harmless, if you take the needed precautions and counter measures.
基本上，使用 SSL 的基本身份验证确实非常安全，如果要暴露给外界，则应使用它。
我以前见过的一种最简单的黑客方法，如果您只想对已知的一组客户端使用的客户端进行身份验证（而不是授权端点）：
这将提供访问服务的用户名，如果有效用户正在访问服务，并且在每个请求中添加用户需要作为请求的一部分发送的加密密钥。这样您就可以从请求中知道用户名和加密密钥。
您还可以将其与基本身份验证一起使用，以确保其不安全。
Basically, Basic authentication with SSL is really very secure and shoul be used if its going to be exposed to outside world.
One easiest hack approach I have seen before and if you just want to authenticate (not authorize a endpoint) clients which are known set of clients use:
This will provide username accessing the service, Authenticate this usern with your DB or AD using LDAP if a valid user is accessing the service and with every request add a encrypted key that user needs to send as part of request. This way you know the username and encrypted key from the request.
You can also use this along with Basic authentication to be sure its not insecure.