Concerns about requiring Captcha for login

[ThatOneCalculator]

I feel requiring either reCaptcha or hCaptcha for login is a bad idea. While Captchas can be great (and I already used them on my instance for signing up), forcing them for login poses three big downsides:

• Breaks login for third party clients
• Forces users to rely on non-free network services
• Gives admins less choice

If Misskey had some sort of built-in Captcha solution I could maybe understand this decision, but as of right now it really doesn't seem like a good idea.

[Johann150]

I also think that requiring a captcha for signin is a bit too much. I am not sure what problem is being solved by this. Maybe proper rate limiting should be implemented for signing in instead, if this is a concern.

But I am not sure if "breaking 3rd party login" is a concern with this since they should use 3rd party app authentication and not native login?

[tamaina]

I agree with what you say that we should not rely on outside software for critical areas of Misskey.

Breaks login for third party clients

Entering username and password in the UI of a 3rd party client is the same thing as phishing. I think it not a very good implementation.

Forces users to rely on non-free network services some sort of built-in Captcha solution

I do not know of any open source or built-in Captcha solutions

Gives admins less choice

It is possible for the administrator not to set bot protection.

[Johann150]

I would like to add that the change to use CAPTCHA for signin is a breaking change and should probably not be taken this lightly.

[ThatOneCalculator]

Entering username and password in the UI of a 3rd party client is the same thing as phishing. I think it not a very good implementation.

I could see the problems, but I don't quite think it's the "same thing as phishing".

I do not know of any open source or built-in Captcha solutions

Nor do I, which is all the more reason why sign-in with captcha should be optional.

It is possible for the administrator not to set bot protection.

As an admin, I would rather have the choice to make sign-up require captcha but sign-in not require captcha, like it was before.

[tamaina]

Why bot protection is needed for sign-in: lots of login attempts can break through passwords. This could be solved with rate limiting, but until rate limiting can be implemented, I don't see the need for the ability to disable the "login only" captcha.

[ThatOneCalculator]

This is why there's 2FA and hardware keys... also any password that's randomly generated with letters+numbers+symbols and is at least 8-ish characters has an extremely small chance of being brute-forced.

See https://random-ize.com/how-long-to-hack-pass/

[tamaina]

syuilo says the implementation does not ask for CAPTCHA for login when 2fa is enabled.

https://github.com/misskey-dev/misskey/commit/02a43a310f6ad0cc9e9beccc26e51ab5b339e15f

[ThatOneCalculator]

But why not have it be optional? I don't see the need to have this be forced on users and admins.

[tamaina]

This is because CAPTCHA protects users from brute force attacks.

Administrators can disable CAPTCHA and users will not see CAPTCHA at login if they enable 2fa.

[Johann150]

until rate limiting can be implemented

I think this is a bad argument, Misskey already has built in rate limiting, which should be adaptible for this use case. https://github.com/misskey-dev/misskey/blob/3dae18b93cc2a219087c4e1a8acc763ff064b71d/packages/backend/src/server/api/limiter.ts#L10 It should be adapted to use something else instead of the user, for example the IP address (special configuration of the reverse proxy would also be required) or just the user name (which will be known when trying to sign in).

[ThatOneCalculator]

This is because CAPTCHA protects users from brute force attacks.

There are multiple ways to brute-force Captchas, both reCaptcha and hCaptcha are vunrable to publicly available machine learning attacks.

[futchitwo]

Breaks login for third party clients

As far as I know, Misskey has one log-in token tied to each username/password pair. The log-in token comes with all permissions and should be treated with the utmost strictness. Allowing a third party to log in using a username and password is the same as handing all permissions to the third party.

[Johann150]

The native login token gives special privileges due to the secure flag on some endpoints. This includes for example: 2FA setup, data import & export, app authentication, miauth, account deletion.

https://github.com/misskey-dev/misskey/blob/3dae18b93cc2a219087c4e1a8acc763ff064b71d/packages/backend/src/server/api/endpoints.ts#L690-L694

But these capabilities may be desired for alternative front ends, and it seems Kaiteki which is linked above is (going to be) such an alternative frontend?

[ThatOneCalculator]

and it seems Kaiteki which is linked above is (going to be) such an alternative frontend?

Yep!

[ishowta]

FYI OWASP - Blocking Brute Force Attacks https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

[tamaina]

I agree that captcha should be used as little as possible, besides requiring external dependencies, because it places a heavy burden on the user to solve the problem.