Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication end with first plugin that has the user but auth fails; should continue with next plugin [CORE5225] #5505

Closed
firebird-automations opened this issue May 1, 2016 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @mrotteveel

Votes: 1

Currently when a user exists for multiple authentication plugins, authentication ends with the first plugin that has the user when authentication fails. Instead it should continue with the next plugin.

A user is identified by username and password, if one of these values is wrong then the user should be considered to not exist. Ending authentication early will leak existence of the user for that plugin, from a security standpoint such a leak of information is not acceptable.

The behavior is also confusing, because some valid usernames + passwords will allow authentication (eg a user that only exists in Legacy_Auth, or only in Srp), while other valid usernames + password will unexpectedly be rejected. This will make it look like you are using the wrong username or password. When a user exists in Srp and Legacy_Auth and you use the Legacy_Auth, the password will be rejected by the Srp plugin ending authentication.

This is especially relevant during transition from Firebird 2.5 compatible apps + drivers, but even if we live in a Firebird 3 only world, it would still be necessary (consider third party authentication plugins that support an alternative mode of authentication).

Commits: e560f6e a742e7d

@firebird-automations
Copy link
Collaborator Author

Modified by: @mrotteveel

description: Currently when a user exists for multiple authentication plugins, authentication ends with the first plugin that has the user when authentication fails. Instead it should continue with the next plugin.

A user is identified by username and password, if a one of the values is wrong then the user should be considered to not exist. Ending authentication early will leak existence of the user for that plugin, from a security standpoint such a leak of information is not acceptable.

The behavior is also confusing, because some valid usernames + passwords will allow authentication (eg a user that only exists in Legacy_Auth, or only in Srp), while other valid usernames + password will unexpectedly be rejected. This will make it look like you are using the wrong username or password. When a user exists in Srp and Legacy_Auth and you use the Legacy_Auth, the password will be rejected by the Srp plugin ending authentication.

This is especially relevant during transition from Firebird 2.5 compatible apps + drivers, but even if we live in a Firebird 3 only world, it would still be necessary (consider third party authentication plugins that support an alternative mode of authentication).

=>

Currently when a user exists for multiple authentication plugins, authentication ends with the first plugin that has the user when authentication fails. Instead it should continue with the next plugin.

A user is identified by username and password, if one of these values is wrong then the user should be considered to not exist. Ending authentication early will leak existence of the user for that plugin, from a security standpoint such a leak of information is not acceptable.

The behavior is also confusing, because some valid usernames + passwords will allow authentication (eg a user that only exists in Legacy_Auth, or only in Srp), while other valid usernames + password will unexpectedly be rejected. This will make it look like you are using the wrong username or password. When a user exists in Srp and Legacy_Auth and you use the Legacy_Auth, the password will be rejected by the Srp plugin ending authentication.

This is especially relevant during transition from Firebird 2.5 compatible apps + drivers, but even if we live in a Firebird 3 only world, it would still be necessary (consider third party authentication plugins that support an alternative mode of authentication).

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.1 [ 10730 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Done successfully

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment