Mobile App Login APIs bypass security features

[threefinger]

When using the Android app, and possibly other non-browser clients, the POST URL used to authorize a login is /api2/auth-token/ versus the web browser that uses /accounts/login/

The problem is that the /api2/auth-token/ URL does not trigger failed login attempts. I have the failed login attempts set to 5, and using a browser, it works exactly as expected and the account is marked Inactive after 5 failed attempts. I was able to submit 20+ consecutive failed login attempts from the Android app and it did not lock the account, which completely defeats the purpose of that feature, since anyone could just launch unlimited auth attempts against that API.

In addition to the above, if I locked the account by exceeding the login attempts in the browser, and go back to the Android app /api2/auth-token/ URL, another security problem is presented. When the account is Inactive and I submit a wrong password, the API responds with “Unable to login with provided credentials.”, but if I submitted the correct password, the API responds with “User account is disabled.”. That means even on an account marked Inactive, someone could continue submitted auth requests against the URL and determine whether or not the correct password was guessed.

Even though it’s an issue specifically I noticed with the Android app, it really applies to all of Seafile across the board, which negates having the failed login attempts feature. Any chance on a quick fix for this?

[r350178982]

Hi,
Thank you very much for the feedback.
As to the problems of triggering deactivate users after failing to login exceeding the login attemps by calling /api2/auth-token/, we will fix this as soon as possible.
Regarding to the message returned by login by using corret/wrong password, we do not think this could be an issue, and the similar features can also be found in other Apps.

Best regards,
Ran

[daniel.pan]

@threefinger

the API responds with “Unable to login with provided credentials.”, but if I submitted the correct password, the API responds with “User account is disabled.”. That means even on an account marked Inactive, someone could continue submitted auth requests against the URL and determine whether or not the correct password was guessed.

There are two concerns:

1. Without returning the exact reason, users will be confused about why they cannot login. There were some tickets about the issue before.
2. The API has rate limitation to restrict login attemp.

[threefinger]

From a security standpoint, “User account is disabled” should supercede “Unable to login with provided credentials.” Otherwise, any bad actor could continue guessing passwords until the right one is reached. That defeats half the purpose of locking an account. Or at the very least, make it an option that the account holder can choose.

[daniel.pan]

@threefinger

When the account is Inactive and I submit a wrong password, the API responds with “Unable to login with provided credentials.”, but if I submitted the correct password, the API responds with “User account is disabled.”. That means even on an account marked Inactive, someone could continue submitted auth requests against the URL and determine whether or not the correct password was guessed.

Thanks. I re-read the paragraph and get what you are meaning. The correct way is to always return “User account is disabled.” whenever the password is correct or not. In another words, the “disable” status should be checked first.

[threefinger]

Yep, exactly that