Summary:
- The order in which 2FA and user/password credentials are validated seems incorrect and provides an attacker more insight than what they should be privy to. Server response to a successful login using username/password but incorrect or empty token returns an odd response for a failed login suggesting that username/password validation is occurring before 2fa validation.
Recommended Improvement for Review:
The response when 2FA is enabled & Legitimate Credentials are provided should be "Logon Failed". Therefore, not confirming to an attacker that the original credentials used were correct. In addition, the second factor/token validation should occur before attempting to validate the user credentials. This would be a brute force mitigation attack against the initial factor.
I'm wondering if a better approach would be to:
- Perform token validation based on provided username + 2FA enabled/disabled radio box.
- Server checks if username has 2FA enabled. If True:
- Performs token validation challenge/response. If Success:
- Validate Username and Password. If True:
Login Successful
- If False: Return Login Failed to browser.
- If False: Return Login Failed to browser.
- For each of the different conditions, log on the server side whether it was a token validation or username/password issue. For Administrative troubleshooting but not available to the user of the web service.
Tests carried out:
Test 1:
- Action: Submit Username/Password and empty token.
Response: "Your session is invalid or expired." - Not Expected.
Risk: Can deduce that username and password is correct for use to attempt authenticated access via alternate ports/protocols exposed for mail services (POP3/IMAPS/Authenticated SMTP etc). Timing attacks likely still possible however.
Test 2:
- Action: Submit Username/Incorrect Password and empty token.
Response: "Login Failed" - Expected.
Test 3:
- Action: Submit Username/Password and incorrect token.
Response: Your session is invalid or expired. - Not expected. Should just be Login Failed.
Test 4:
- Action: Submit Username/Password and correct token.
Response: Successful login - Expected.
Test 5:
- Prevent /yubikey.js from loading in client browser once 2FA was activated and enforced server side for user account with correct username/password submitted.
- Response: "Your session is invalid or expired." - Refer test 1 recommendations for review.
Thoughts appreciated. I'm not really a developer but thought that the failure message was a little odd. Believe this is an issue worthy of raising/discussion.
Cheers,
A
Summary:
- The order in which 2FA and user/password credentials are validated seems incorrect and provides an attacker more insight than what they should be privy to. Server response to a successful login using username/password but incorrect or empty token returns an odd response for a failed login suggesting that username/password validation is occurring before 2fa validation.
Recommended Improvement for Review:
The response when 2FA is enabled & Legitimate Credentials are provided should be "Logon Failed". Therefore, not confirming to an attacker that the original credentials used were correct. In addition, the second factor/token validation should occur before attempting to validate the user credentials. This would be a brute force mitigation attack against the initial factor.
I'm wondering if a better approach would be to:
- Perform token validation based on provided username + 2FA enabled/disabled radio box.
- Server checks if username has 2FA enabled. If True:
- Performs token validation challenge/response. If Success:
- Validate Username and Password. If True:
Login Successful
- If False: Return Login Failed to browser.
- If False: Return Login Failed to browser.
- For each of the different conditions, log on the server side whether it was a token validation or username/password issue. For Administrative troubleshooting but not available to the user of the web service.
Tests carried out:
Test 1:
- Action: Submit Username/Password and empty token.
Response: "Your session is invalid or expired." - Not Expected.
Risk: Can deduce that username and password is correct for use to attempt authenticated access via alternate ports/protocols exposed for mail services (POP3/IMAPS/Authenticated SMTP etc). Timing attacks likely still possible however.
Test 2:
- Action: Submit Username/Incorrect Password and empty token.
Response: "Login Failed" - Expected.
Test 3:
- Action: Submit Username/Password and incorrect token.
Response: Your session is invalid or expired. - Not expected. Should just be Login Failed.
Test 4:
- Action: Submit Username/Password and correct token.
Response: Successful login - Expected.
Test 5:
- Prevent /yubikey.js from loading in client browser once 2FA was activated and enforced server side for user account with correct username/password submitted.
- Response: "Your session is invalid or expired." - Refer test 1 recommendations for review.
Thoughts appreciated. I'm not really a developer but thought that the failure message was a little odd. Believe this is an issue worthy of raising/discussion.
Cheers,
A