Publish GHSA-chcr-x7hc-8fp8

advisories/github-reviewed/2024/01/GHSA-chcr-x7hc-8fp8/GHSA-chcr-x7hc-8fp8.json

@@ -1,14 +1,14 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-chcr-x7hc-8fp8",
-  "modified": "2024-03-19T22:33:56Z",
+  "modified": "2024-03-20T15:34:05Z",
   "published": "2024-01-12T15:13:05Z",
   "withdrawn": "2024-03-19T22:33:55Z",
   "aliases": [
     "CVE-2024-0227"
   ],
   "summary": "Devise-Two-Factor vulnerable to brute force attacks",
-  "details": "Devise-Two-Factor does not throttle or otherwise restrict login attempts at the server by default. When combined with the Time-based One Time Password algorithm's (TOTP) inherent entropy limitations, it's possible for an attacker to bypass the 2FA mechanism through brute-force attacks.\n\n### Impact\n\nIf a user's username and password have already been compromised an attacker would be able to try possible TOTP codes and see if they can hit a lucky collision to log in as that user. The user under attack would not necessarily know that their account has been compromised.\n\n### Patches\n\nDevise-Two-Factor has not released any fixes for this vulnerability. This library is open-ended by design and cannot solve this for all applications natively. It's recommended that any application leveraging Devise-Two-Factor implement controls at the application level to mitigate this threat. A non-exhaustive list of possible mitigations can be found below.\n\n#### Mitigations\n\n1. Use the `lockable` strategy from Devise to lock a user after a certain number of failed login attempts. See https://www.rubydoc.info/github/heartcombo/devise/main/Devise/Models/Lockable for more information.\n2. Configure a rate limit for your application, especially on the endpoints used to log in. One such library to accomplish this is [rack-attack](https://rubygems.org/gems/rack-attack).\n3. When displaying authentication errors hide whether validating a username/password combination failed or a two-factor code failed behind a more generic error message.\n\n### Acknowledgements\n\nChristian Reitter ([Radically Open Security](https://www.radicallyopensecurity.com/)) and Chris MacNaughton ([Centauri Solutions](https://centauri.solutions))",
+  "details": "### Advisory withdrawn\nThe backing CVE has been rejected\n\nDevise-Two-Factor does not throttle or otherwise restrict login attempts at the server by default. When combined with the Time-based One Time Password algorithm's (TOTP) inherent entropy limitations, it's possible for an attacker to bypass the 2FA mechanism through brute-force attacks.\n\n### Impact\n\nIf a user's username and password have already been compromised an attacker would be able to try possible TOTP codes and see if they can hit a lucky collision to log in as that user. The user under attack would not necessarily know that their account has been compromised.\n\n### Patches\n\nDevise-Two-Factor has not released any fixes for this vulnerability. This library is open-ended by design and cannot solve this for all applications natively. It's recommended that any application leveraging Devise-Two-Factor implement controls at the application level to mitigate this threat. A non-exhaustive list of possible mitigations can be found below.\n\n#### Mitigations\n\n1. Use the `lockable` strategy from Devise to lock a user after a certain number of failed login attempts. See https://www.rubydoc.info/github/heartcombo/devise/main/Devise/Models/Lockable for more information.\n2. Configure a rate limit for your application, especially on the endpoints used to log in. One such library to accomplish this is [rack-attack](https://rubygems.org/gems/rack-attack).\n3. When displaying authentication errors hide whether validating a username/password combination failed or a two-factor code failed behind a more generic error message.\n\n### Acknowledgements\n\nChristian Reitter ([Radically Open Security](https://www.radicallyopensecurity.com/)) and Chris MacNaughton ([Centauri Solutions](https://centauri.solutions))",
   "severity": [
     {
       "type": "CVSS_V3",