Currently HipChat Server supports a failed login limit (and lockout when the limit is exceeded) when users are part of a local directory. However the limit does not apply if HCS is instead configured to use a Crowd directory.

The limit should be configurable, and should work with either species of directory.

Without this feature, a HipChat server with a Crowd integration AND external access (say for mobile devices) can present a security vulnerability.

A brute force attacker with a list of email addresses can lock each user out of the domain. How? By exceeding the login limit of the directory. Most directories impose a login limit and most directories lock out users that exceed the limit for a "cool off period" (e.g. ours locks users out for 15 minutes). HipChat doesn't impose a limit and neither does Crowd. The lockout outcome is clearly not as bad as compromised passwords, but allowing a means to lock a large swath of an IT organization out of the domain is unacceptable. And the lockout can recur whenever the attack resumes.

Without this feature our Nordstrom security group is unwilling to allow us to open HipChat up to mobile users. Without mobile support, a big part of HipChat's value proposition is unfulfilled (keeping team's in sync wherever they are).

Note that reverting to a local directory is not a viable option for most security-conscious enterprises. With 2000+ users, how can an enterprise easily and reliably deactivate users that leave the company? and easily reclaim the associated licenses? Enterprises depend on user state in the directory to control deactivation.

Note also that Jira and Confluence both support this feature in concert with Crowd.