Is “alwaysauthreject=yes” actually secure?

[system]

Set “alwaysauthreject=yes” in your sip.conf file. This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage. Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.

Hi, I’m pretty new to Asterisk and just recently learned about this feature. One thing it makes me wonder is how securely this was actually implemented, if it wasn’t done correctly it could be security circus.

I don’t have the time to dig around the code trying to find the logic this applies to, but it must be kept in mind that any timing variance in the logic between “invalid username” and “bad authentication request” will leak extension information in the time to return.

For example

if( bad_username() || bad_authentication() ){
return the_same_information;
}

will leak if the username is correct in return time due to the short circuiting of ||. I have no idea how this was actually implemented, but I could easily see non-security oriented programmers making such a mistake.

Does anybody know if this is actually side channel secure (constant time)?

Also, just to preempt any potential claims that timing leaks are too small to be exploitable rdist.root.org/2010/01/07/timing … omparison/

[david55]

I think you can safely assume that no covert channel analysis has been done, and, in practice, none needs to be done as the average attacker is not going to go to the trouble of seeing whether rejections cluster around two different delays, given the uncertainties in packet transit times and scheduling delays.

I doubt that the path difference will be significant compared with other timing uncertainties.

People attack Asterisk for financial gain, not to gain access to a specific system.