You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for generic response messages. (pallets-eco#632)
The new SECURITY_RETURN_GENERIC_RESPONSES flag, if set to True will make Flask-Security consistent with the OWASP Authentication errors cheat-sheet recommendations.
This affects the /register, /login, /forgot, /confirm, /us-signin, /verify endpoints.
This adds new signal (user_not_registered), new email templates (welcome_existing, welcome_existing_username) to improve UX in the case of someone trying to register an already registered email/username.
closepallets-eco#585
How an application responds to API requests that contain identity or authentication information
124
+
can give would-be attackers insight into active users on the system. OWASP has a great `cheat-sheet`_ describing
125
+
this and useful ways to avoid it. Flask-Security supports this by setting the
126
+
:py:data:`SECURITY_RETURN_GENERIC_RESPONSES` configuration to ``True``. As documented in the cheat-sheet - this does
127
+
come with some usability concerns. The following endpoints are affected:
128
+
129
+
* :py:data:`SECURITY_REGISTER_URL` - The same response will be returned whether the email (or username) is already in the
130
+
system or not. JSON requests will ALWAYS return 200. If :py:data:`SECURITY_CONFIRMABLE` is set (it should be!), the
131
+
`SECURITY_MSG_CONFIRM_REGISTRATION` message will be flashed for both new and existing email addresses. Detailed errors will still
132
+
be returned for things like insufficient password complexity, etc.. In the case of trying to register an existing email, an email will be sent to that email address
133
+
explaining that they are already registered and displaying the associated username (if any) and provide a hint on how to reset their
134
+
password if they forgot it. In the case of a new email but an already registered username, an email will be sent saying that the
135
+
user must try registering again with a different username.
136
+
* :py:data:`SECURITY_LOGIN_URL` - For any errors (unknown username, inactive account, bad password) the `SECURITY_MSG_GENERIC_AUTHN_FAILED`
137
+
message will be returned.
138
+
* :py:data:`SECURITY_RESET_URL` - In all cases the `SECURITY_MSG_PASSWORD_RESET_REQUEST` message will be flashed. For JSON
139
+
a 200 will always be returned (whether an email was sent or not).
140
+
* :py:data:`SECURITY_CONFIRM_URL` - In all cases the `SECURITY_MSG_CONFIRMATION_REQUEST` message will be flashed. For JSON
141
+
a 200 will always be returned (whether an email was sent or not).
142
+
* :py:data:`SECURITY_US_SIGNIN_SEND_CODE_URL` - The `SECURITY_MSG_GENERIC_US_SIGNIN` message will be flashed in all cases -
143
+
whether a selected method is setup for the user or not.
144
+
* :py:data:`SECURITY_US_SIGNIN_URL` - For any errors (unknown username, inactive account, bad passcode) the `SECURITY_MSG_GENERIC_AUTHN_FAILED`
145
+
message will be returned.
146
+
* :py:data:`SECURITY_US_VERIFY_LINK_URL` - For any errors (unknown username, inactive account, bad passcode) the `SECURITY_MSG_GENERIC_AUTHN_FAILED`
147
+
message will be returned.
148
+
149
+
150
+
In the case of an application using a ``username`` as an identity it should be noted that it is possible for a bad-actor to enumerate usernames, albeit slowly,
151
+
by parsing emails.
152
+
153
+
Note also that :py:data:`SECURITY_REQUIRES_CONFIRMATION_ERROR_VIEW` is ignored in these cases. If your application is using WebAuthn, be sure
154
+
to set :py:data:`SECURITY_WAN_ALLOW_USER_HINTS` to ``False``.
0 commit comments