The current implementation of the API application (inside the api folder) has at least two obvious security issues.
First, the protection against user enumeration is wrong. You assume that by hashing the password provided in a request with an invalid user you are going to take as much time as authenticating a user. That's an arbitrary and wrong assumption. Among other things, the time safe hash comparison is completely missing, meaning that in case of a wrong username your response will take less time than a response against an existing user.
Also, the whole point of the user enumeration is rendered completely partially moot by using a different language key depending on whether the password of an existing user is incorrect or the user doesn't exist at all. Even if the timing differences weren't there you are essentially delegating the site's security to the translators. All user authentication errors should use the same language key, e.g. JGLOBAL_AUTH_INVALID_PASS.
At least, unlike WordPress, Joomla doesn't seem to allow direct listing all users and / or leak their information such as email addresses without any authentication at all.
In any case, the discussion to this point is moot because usernames are not to be treated as secrets. They are more or less public information. If you have, for example, a forum you will most likely be able to see everyone's usernames there. That's why we have passwords and, most importantly, two factor authentication.
Therein lies the next and most serious attack vector. The basic API authentication plugin is effectively bypassing Two Step Authentication. This means that an attacker can very easily brute force the password of a user.
Now, you'll tell me, if I have the username and password I can't log into the site if the user has Two Step Authentication enabled.
The API lets me create, modify and delete users as long as I know the username and password of a Super User. Which I do, having brute forced the password with the ever so helpful API. Now I can very easily create a new Super User (or, if I am a sneaky s.o.b. subvert this Super User by disabling Two Step Verification and changing the password and email address). Then I can simply delete all other users on the site. The site has been pwned and none is the wiser as to how it happened.
In short, the way the API is implemented is a security nightmare. It does allow side-channel user enumeration despite assurances to the contrary, it allows brute forcing of the password and, even more scary, allows me to pwn a site with nothing but a Super User's username and password, TFA be damned!
APIs should not use usernames and passwords. They should use revokable tokens at worst. I am aware I've done the same mistake. It's one I'm in the process of fixing. Naturally, I looked into how Joomla addresses the challenge I had and found out it's even worse. Oh boy.
I would recommend scraping the api-authentication/basic plugin altogether and replacing it with a token implementation. Writing a user plugin to create / regenerate a per-user token isn't that hard. It also has the added benefit of essentially making the API inoperable unless one or more users explicitly go ahead and create tokens for themselves. This will protect the bulk of innocent users who don't need or even know about the API.
As I obliquely mentioned before, Joomla is not alone in this mess. WordPress' API shares the same design mistakes and it is being used to enumerate users and leak information. But just because someone does something wrong doesn't mean you should too. Am I right?
The current implementation of the API application (inside the
apifolder) has at least two obvious security issues.First, the protection against user enumeration is wrong. You assume that by hashing the password provided in a request with an invalid user you are going to take as much time as authenticating a user. That's an arbitrary and wrong assumption. Among other things, the time safe hash comparison is completely missing, meaning that in case of a wrong username your response will take less time than a response against an existing user.
Also, the whole point of the user enumeration is rendered completely partially moot by using a different language key depending on whether the password of an existing user is incorrect or the user doesn't exist at all. Even if the timing differences weren't there you are essentially delegating the site's security to the translators. All user authentication errors should use the same language key, e.g. JGLOBAL_AUTH_INVALID_PASS.
At least, unlike WordPress, Joomla doesn't seem to allow direct listing all users and / or leak their information such as email addresses without any authentication at all.
In any case, the discussion to this point is moot because usernames are not to be treated as secrets. They are more or less public information. If you have, for example, a forum you will most likely be able to see everyone's usernames there. That's why we have passwords and, most importantly, two factor authentication.
Therein lies the next and most serious attack vector. The basic API authentication plugin is effectively bypassing Two Step Authentication. This means that an attacker can very easily brute force the password of a user.
Now, you'll tell me, if I have the username and password I can't log into the site if the user has Two Step Authentication enabled.
The API lets me create, modify and delete users as long as I know the username and password of a Super User. Which I do, having brute forced the password with the ever so helpful API. Now I can very easily create a new Super User (or, if I am a sneaky s.o.b. subvert this Super User by disabling Two Step Verification and changing the password and email address). Then I can simply delete all other users on the site. The site has been pwned and none is the wiser as to how it happened.
In short, the way the API is implemented is a security nightmare. It does allow side-channel user enumeration despite assurances to the contrary, it allows brute forcing of the password and, even more scary, allows me to pwn a site with nothing but a Super User's username and password, TFA be damned!
APIs should not use usernames and passwords. They should use revokable tokens at worst. I am aware I've done the same mistake. It's one I'm in the process of fixing. Naturally, I looked into how Joomla addresses the challenge I had and found out it's even worse. Oh boy.
I would recommend scraping the api-authentication/basic plugin altogether and replacing it with a token implementation. Writing a user plugin to create / regenerate a per-user token isn't that hard. It also has the added benefit of essentially making the API inoperable unless one or more users explicitly go ahead and create tokens for themselves. This will protect the bulk of innocent users who don't need or even know about the API.
As I obliquely mentioned before, Joomla is not alone in this mess. WordPress' API shares the same design mistakes and it is being used to enumerate users and leak information. But just because someone does something wrong doesn't mean you should too. Am I right?