Potential abuse via login failure messages?

[qlp-mathias]

https://github.com/meteor/meteor/blob/e5d2166bf7aff3b7b9a7e372e591f16fcbd3df00/packages/accounts-password/password_server.js#L192

Apparently, the server reacts differently depending on whether a user exists or not.

This behaviour could be abused by an attacker to gather intelligence for phishing or brute- force login attacks.

Example Websocket message:

["{\"msg\":\"connect\",\"session\":\"sTaPiWiRJoKrfxaAS\",\"version\":\"1\",
\"support\":
[\"1\",\"pre2\",\"pre1\"]}","{\"msg\":\"method\",\"id\":\"1\",\"method\":\"
login\",\"params\":[{\"user\":
{\"email\":\"some-email@provider.com\"},\"password\":
{\"digest\":\"5723360ef11043a879520412e9ad897e0ebcb99cc820ec363bfecc9d751a1
a99\",\"algorithm\":\"sha-256\"}}]}"]

[leonardoventurini]

@qlp-mathias What version of Meteor are you on?

[StorytellerCZ]

If you set ambiguousErrorMessages option in Account to true, then it will be fixed for you.

In Meteor 3 the default for ambiguous messages is set to true: https://github.com/meteor/meteor/pull/12996

13194 will make it easier to set from settings.json

[qlp-mathias]

Hey guys, sorry for the late reply. We're currently running on 2.11 and plan to update to 2.16 soon.

We're using a third party auth provider and have implemented a custom handler for this, but still rely on the accounts-base package. I was going to remove the accounts-password handler manually to get rid of the error messages.

But I'd like to give your method a shot as well @StorytellerCZ . Is that also supported by Meteor 2.x?

[StorytellerCZ]

I don't recall at which version this option got introduced, but I think it has been a while, so if you set it to true you should be fine. In 3.0 the difference is that unless set otherwise it will be set to true in production to enhance default security.

[StorytellerCZ]

I'm closing this issue for now, but feel free to re-open if more discussion is needed.