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
{{ message }}
This repository has been archived by the owner on Jan 8, 2020. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
Thanks for this detailed report Andy. I’m limited by the interface provided by Roundcube - it’s not very well suited for 2FA. At first glance, this seems to be related to the fail() method. I’ll see what I can do.
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
The text was updated successfully, but these errors were encountered: