用户身份验证是否会成为Centralized Server的性能瓶颈?

时间:2015-08-06 13:15:38

标签: asynchronous instant-messaging ddos

为了解释上下文,让我们举一个单线程聊天服务器的例子,该服务器利用异步事件通知(例如epoll等)来处理IO,并在用户身份验证和注册过程中广泛使用PKI和其他加密工具在当地处理和完成。虽然消息间接(从源到目的地)是一个温和的CPU数据密集型过程,但很少有使用RSA密钥签名消息的加密过程在计算上很重,并且可能成为整个IO循环中的慢速路径。

攻击者是否可以通过在短时间内提出过多的注册请求来利用这种缓慢的路径来大幅降低服务器的性能?如果是,那么减少影响的方法是什么?如果这是一个真正的威胁,那么大型服务提供商如何管理呢?

让我们扩展讨论以涵盖Federated XMPP服务器。

1 个答案:

答案 0 :(得分:1)

真的不是这方面的专家,但以下是常识性的反思可能会回答你的问题。

注册太多

这就是大多数注册表单使用captcha s。

的原因

认证太多

认证在计算上并不重要;它们通常涉及(盐渍)哈希的比较。 正如@SergeBallesta指出的那样,这是完全错误的;密码散列在设计上似乎很慢,以防止暴力攻击。实际上,this post提到了DDoS易受攻击的问题,并建议将知识产权禁令作为对策(参见下文并参见this thread建议的BCrypt轮数)。

通过使用会话参数限制认证试验的次数,拒绝与现有会话无关的认证请求似乎不合理。

可能会在短时间内监控来自同一IP的大量身份验证请求,并暂时禁止IP。这通常涉及独立于应用程序代码本身的监视进程。

消息太多

我在这里并不完全确定,如果遇到这种情况,我可能会测试一下我要说的话。我认为在更糟糕的情况下,由于低级加密(例如SSL)导致的开销与应用程序处理时间相当,所以我不担心这一点。

关于邮件路由,每次经过身份验证的用户发送N条消息时,您可能会生成新的令牌,在每次提交时更新令牌有效性,并在到期时触发更新。这可能会导致轻微的开销,但它允许限制每个用户的消息提交速率,从而控制由于消息路由而导致的整体服务器负载。

希望这有帮助。