我正在努力使网络服务安全 它不适用于银行或类似的任何东西，但使用它的组织可能会失去一些钱，如果该服务将由未经授权的人使用（很难确切地知道多少......）。
目的不是允许未经授权的应用程序使用任何方法（“GetChallenge”除外。对于用户身份验证，有一种不同的机制可以检查用户名和密码。我实际上将两者合并，但它们有不同的用途）：
所以这就是我的所作所为：
我发送一个（ASP.NET）会话密钥（供大家阅读.ASP.NET的会话是15个随机生成的字节，除非延长，否则它将持续20分钟，如果没有它，ASP.NET将不会收到任何请求）。
在我的SignIn方法中，除了用户名和密码（任何人都可以获取，因为它是公共站点的一部分），我收到第三个参数 - 会话密钥由md5算法散列，6个字节为盐。
并且只有当哈希值正确时（我正在哈希并在服务器端进行比较） - 我让用户登录。
从那时起，我会检查用户是否已登录。
已添加：用户名和密码以明文形式发送，而则不是问题（不是我至少要解决的问题）。问题是某人（我们正在合作的公司除外）编写使用我的网络服务的应用程序。网络服务只能由授权的应用程序使用
此外，会话ID与每个请求和响应一起来回发送（作为ASP.NET会话机制的一部分。这就是ASP.NET知道如何“跟踪”特定于用户的会话）。很抱歉没有从头开始澄清。
（非理性地认为这是显而易见的）。
安全策略有多强大和有效？
感谢。
答案 0 :(得分：1)
根据您的编辑和评论更新
它非常安全，与Google，Facebook和其他人用于API密钥的方法非常相似。除了...
会话ID纯文本潜在问题
我建议不要使用会话ID作为安全机制的一部分。
一个问题是通过网络以纯文本传递会话密钥。这可能会打开一些会话劫持和其他攻击。
SessionID在服务器和浏览器之间以明文形式发送，可以是cookie，也可以是URL。因此，不需要的源可以通过获取SessionID值并将其包含在对服务器的请求中来访问另一个用户的会话。如果您在会话状态中存储私人或敏感信息，建议您使用SSL加密浏览器和包含SessionID的服务器之间的任何通信。
当您使用会话ID作为安全机制的一部分时，我会说这是敏感数据。
确保某人无法获取会话密钥的一种方法是在HTTPS上运行您的服务。就个人而言，我会避免以这种方式使用会话ID，而是生成一个不相关的值。
推荐的更改
更密切地关注Google等使用的模型。为每个应用程序生成新的GUID，将GUID存储在服务器上的数据库中，将每个请求中的GUID从客户端传递到服务器。
Benfits：
我仍会在HTTPS上运行该服务，因为它易于设置，并且可以保护您发送到服务的任何其他数据。
答案 1 :(得分：0)
加密的目的不是为了 允许未经授权的应用程序使 任何方法
错误。加密它的目的是为了防止在传输或存储时理解数据。它可以防止那些无法解密的数据“可用”。
您所描述的内容类似于公钥/私钥系统。您正在向所有人提供会话密钥。然后，只有在他们使用正确的盐（根据您的服务器端比较）md5后，您才会信任该来源。
除了用户名和密码，您在此处没有身份验证。此外，您的数据在传输过程中未加密。我没有看到这是多么安全。
我认为您最好的选择是使用SSL证书（因此您的Web服务通过HTTPS运行）以及用户名和密码。如果您想要加倍安全，您可能需要沿着检查源IP范围和登录位置的路线作为附加检查。在消费者将凭据传递给第三方+审核Web服务实际使用方式的情况下，强制密码更改间隔可能会有所帮助。
作为旁注，如果你想要哈希，不要使用MD5，its broken。
答案 2 :(得分：0)
从Web服务的角度来看，使用身份验证或为您的服务提供安全性的理想方式是：Web Service Authentication（Token和MD5 Hashing加密密码）。
答案 3 :(得分：0)
你描述它的方式，它似乎根本不安全。
如果会话密钥是公开的（“供所有人阅读”），让SignIn方法接受散列会话密钥有什么意义？
Plus：“在每种方法中，我都会检查用户是否已登录。”您如何检查？
一种常见（且相当安全）的策略是生成（唯一的，足够长且随机的）会话ID服务器端，并在经过身份验证后将其发送到客户端。然后检查每个客户端请求，只有在包含会话ID时才接受它。要做到这一点，要么将ID嵌入到每个页面的所有链接中，要么将其设置为cookie，具体取决于您更容易。 注销时，只需删除服务器上的会话ID即可。
这样，没有有效会话，没有人可以调用任何方法。