Discovery attack on login form

[Berbe]

Expected behaviour

When attempting to login, the use of bad credentials should provide a single and consistent error message saying credentials are invalid, without finer granularity.

Actual behaviour

When using an incorrect email address, the login form actually states the email is wrong, instead of the credentials pair.
That means email enumeration of registered users is possible ans consists itself in a form of discovery attack.

Steps to reproduce the problem

1. Reach the login form of any mastodon instance
2. Try to login with non-registered email address

Specifications

The instance that behavior has been noticed on was v2.6.1

[Gargron]

Which language? English or another? The messages should be identical

[mkljczk]

probably French
screenshot_20181127-162117
screenshot_20181127-162124

[Berbe]

Wow that is unexpected: how are translations able to tell one case (non-existent email) from the other (invalid credentials)?
Sounds like a design flaw.

Thanks for helping spot the problem anyway!

[nightpool]

ehhhhh either we should say that this is an issue and fix it in the code, not the translations, or we should just ignore it. I find discovery attacks to be pretty overblown.

[Berbe]

I'll set the personal opinion aside which, while dangerous, iss ill-placed in a bug report.

It is definitely a code bug to differentiate thoses error cases in any way, thus allowing to handle them differently in the translation engine. Would you be able to help spot where the problem comes from in the source code?
However, as a quick fix, I'd suggest to set the translated error message strictly identical in both cases for now.

[Gargron]

I've looked at the Devise code. If paranoid mode is active, it never uses the not_found_in_database locale. Paranoid mode is active for us:

https://github.com/tootsuite/mastodon/blob/master/config/initializers/devise.rb#L154

So, what the hell?

[nightpool]

@Berbe ...... having an opinion is dangerous? having an opinion on the priority/validity of a bug report is ill-placed? that's the entire point of triage.

[Berbe]

@nightpool Stop claiming your words for my own; Quibbling stops here & now.

@Gargron If I understand well, does that mean no Mastodon instance would be able to differentiate the error cases, ever?

[mkljczk]

What’s the instance where you encounter this problem? Maybe it has some custom changes related to authentication (for example to make sign in with username possible)

[Gargron]

I am still confused because @m4sk1n you were able to reproduce the issue, despite Devise.paranoid being set to true?

[Berbe]

I noticed that behavior on https://mastodon.xyz/

[mkljczk]

I noticed it on glitch.social (not dev. one), I think it has no auth-specific changes

[Gargron]

I have identified the issue. The devise-two-factor gem ignores the paranoid setting in its two_factor_authentication strategy and always throws "not_found_in_database". However, if the user record does exist, execution moves to the standard devise_authenticatable strategy, which correctly always throws "invalid" when paranoid mode is activated.

This would have been a larger issue if the keys weren't identical in almost all translations.

[Gargron]

Submitted fix: devise-two-factor/devise-two-factor#138

[Berbe]

Great catch!

Thanks a lot, crossing my fingers for upstream correction and integration of their new version into mastodon ASAP.

[trwnh]

fixed in upstream pr, i assume. if this is still happening then please comment here so it can be reopened