Cap*_*oad 5 c# security web-services active-directory
我正在创建一些Web服务,我想使用自定义(即非WS-Secure等)方法来保护它.目前我的计划是有一个方法,它采用活动目录用户名和密码(当然是通过HTTPS)来验证用户.然后,此方法将获取该用户的帐户SID,并使用安全但可逆的方法对其进行加密,并将其作为安全令牌传回.
在此之后,调用者将加密的令牌作为参数传递给每个Web方法,作为确保调用者经过身份验证的方法.然后可以解密该令牌并将其转回到目录条目中(并因此确认其真实性)相当简单.这有额外的好处,允许方法绝对识别经过身份验证的调用者.
但是,使用帐户中的SID(通常只是内部的),让我有点担心.这样安全吗？
编辑:正如我在评论中所述,我已经意识到令牌需要"会话化" - 即它需要到期以减少令牌重用的可能性.这可能是通过将客户端会话保持为令牌的一部分来处理的.
对,这里有 - 这是一个很长的答案......
执行此操作的问题是,如果您需要代表他们执行操作(即冒充该用户),那么持久保存SID并不足以能够重新验证用户 - 因为您需要提供操作系统安全令牌.如果您只有SID,那么在这种情况下您仍需要密码 - 除非您在AD商店中使用可逆加密,我非常怀疑这种情况 - 并且当然希望它不是!
除此之外,还有一个问题是,一旦加密该SID并将其发回,它就可能是安全的线上(只要我们假设HTTPS始终是安全的),但不是一旦它在客户端机器上.
有人可以窃取加密的SID并开始发出请求,就好像他们是那个用户一样.
在我看来,如果您使用AD作为后端身份验证存储,那么您应该仅使用Negotiate或Kerberos身份验证.然后,它产生的票据可用于在需要时模拟用户; 而且我不相信它们会被盗(尽管在安全领域,几乎所有技术都可能被盗).
但是,您可能会使您的Web服务非常难以使用 - 我当然不会考虑为这些协议编写自己的客户端.
在我说出我可能会做的事情之前,如果我面对这个问题,我首先要说的是它并不是真正安全的 - 对于有人捣乱的同时还要从实际用户中删除令牌的关联(背后的模式)有点棘手加密信息是黑客最好的朋友).之后我还列出了其他警告:
使用AD作为身份验证方法,但不再需要,单独跟踪身份验证会话,并为他们提供与AD SID无关的唯一密钥 - guid或类似的东西.这样,每次用户进行身份验证时,他们都会获得不同的核心会话ID.
我会在每个会话中创建它创建的时间以及加密安全的唯一随机盐(一个随机数 - 虽然它在这里没有像维基百科描述的那样使用.为此使用RNGCryptoServiceProvider).我还会在其中包含一些(但不是全部)有关客户端(ip,用户代理)的信息.
那我就先构造一个标记为一字符串结合所有的信息在一起,然后用也许加密它至少在Rijndael算法 SymmetricAlgorithm实现了128位IV和256位密钥(这两者必须保持非常安全的,应该是随机生成再次使用RNG!).
您将此发送回客户端,然后他们在请求中使用它(直到它过期 - 它绝对必须这样做).
当您收到令牌时
认证会话永远不应该是开放式的 - 它们应该具有到期时间以防止能够使用非常旧的令牌.
当然,一直使用HTTP也是不言而喻的.
所有这一切 - 您选择的身份验证等应该与传输的数据类型和人们可以做的事情成比例.如果黑客不会对您的服务感兴趣; 或者如果环境完全是内部的,那么就用你原来的想法来破解.
(那是无限的力量)
虽然我已经提出了这个解决方案,但由于很多原因它并不安全,如果涉及任何真正的秘密,我就不会使用它.
它依赖于HTTPS来验证服务器到客户端 - 这在客户端移交用户名和密码组合之前非常重要.拿走它然后它会中断,如果你操纵客户端计算机上的证书链也可以完全避开.它还依赖于HTTPS通道来保护传输中的用户名/密码组合.
我们应该更进一步,在请求上引入消息编号和签名,以确保客户端仍然是他们自己的人,因为IP地址和头文件很容易被欺骗.我们也应该考虑使用大型素数的非对称加密和所有用于密码传输的爵士乐,甚至在考虑HTTP之前.
所以,基本上,如果它是安全关键 - 忽略我并咨询专家 - 不要试图自己动手,因为你会弄错.
如果你只是被一个12岁的怪人攻击,而不是因为这是12岁的孩子所做的,那么我的解决方案可能太沉重了你也可以选择你的想法.
无论哪种方式 - 我不保证会发生什么/可能会发生什么,我想在某种程度上这个现在非常长的答案实际上是说你们都听我说话而忽视了我的危险:)