ARI crypt password performance

Asterisk Asterisk APIs
1

Hi,

I’m currently running Asterisk 13* on a resource constrained system. Whilst investigating a performance issue I noticed libbcrypt was using a significant amount of CPU time, and digging a bit deeper it was a combination of many ARI requests and a hashed password in ari.conf

Rather than calling libbcrypt on every occasion is it possible to cache the hash? It’s Basic HTTP authentication so I don’t think it needs to decrypt the password every time in theory.

* I’m prioritising getting it upgraded ASAP, but it doesn’t look like there’s been any significant changes to the ARI authentication part.

Thanks

2

It’s not decrypting the password every time, it’s crypting the plain text password from the HTTP request so it can be validated against the crypted value. That’s not something you can overcome if using a crypted value.

3

Thanks for the quick response, and understood on the asterisk not having direct visibility of the unhashed password to cache.

However thinking about it some more, when a client successfully authenticates for the first time it could cache the result?

e.g

Plain text: username:password
base64: dXNlcm5hbWU6cGFzc3dvcmQ=

On a new login asterisk checks it against the hash, and then caches either the plain or b64 encoded login as “authenticated” so it doesn’t have to check the hash again.

Thanks

4

They’re individual HTTP requests, which may or may not have connection reuse, and each request is itself authenticated. There is no “login” of them.

5

Right, so as its basic authentication every request contains an Authorization header containing the same string.

So Asterisk just needs to know “I’ve seen this string before, and it previously matched the hash. Therefore I can assume it still matches the hash, without checking”

6

It’s not “just” that. You’re now adding state management, lifecycle to that, maximum storage count of such information, as well as invalidation if configuration changes.

Can you hack it in for your usage? Probably.

7

Okay understood on additional overhead side of managing such a thing, thanks for the guidance.

8

If this is implementing the Unix crypt password hash, that is deliberately designed to be CPU intensive, to limit the speed of brute force attacks.

9

Password-encryption algorithms like brcypt2 are designed to be slow. Computing hashes over and over does seem to be a suboptimal use of them.

This is why HTTP cookies were invented. Is there any way for Asterisk to make use of them?

10

I think you have the order wrong. I’m pretty sure that cookies were invented to maintain state, for non-authentication purposes, then adopted for authentication because designers didn’t want a standard user interface (designers are always trying to make their site different, even if that causes difficulty for, especially older, users). To a large extent now, they have moved to being a means of tracking people across multiple sites.

11

Cookies don’t normally work across multiple sites.

12

That article is describing a counter measure to the fact that they were being heavily used, because they did work, as cookies were originally implemented.

13

So, is Asterisk likely to support session cookies? It looks like the easiest solution to the problem.

14

Another answer would be to (add the option to) abandon the use of password hashes and use fast cryptographic hashes instead. Yes, this will ease attacks if anybody gets hold of the encrypted hashes. Is an Asterisk server considered that sensitive?

15

Noone is actively working on cookies or anything like that probably because noone else has had problems presumably because most deployments just use the normal username and password, or are on systems where crypt performance isn’t really a problem for them.

16

I’d suggest clear text storage of passwords, if you are going to change it.