Timeline for Storing weakness level of passwords
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 18, 2022 at 17:33 | history | edited | Brian | CC BY-SA 4.0 |
added 167 characters in body
|
| Apr 18, 2022 at 15:57 | comment | added | Brian | @BenVoigt I agree completely - I have edited to hopefully clarify that there is a somewhat "safer" means to store the info if you are overridden, but I would still vigorously oppose storing that information if I could, since one should ALWAYS assume that any attacker can read and correctly interpret ALL your source code and not just your hashed password list. | |
| Apr 18, 2022 at 15:48 | history | edited | Brian | CC BY-SA 4.0 |
added 298 characters in body
|
| Apr 14, 2022 at 19:03 | comment | added | Ben Voigt | "store a flag indicating the user has bypassed the pwned password warning " is exactly what you mustn't do, other answers adequately explain why, but in summary, that flag becomes a "break this account first" beacon to attackers | |
| S Apr 13, 2022 at 17:50 | review | First answers | |||
| Apr 13, 2022 at 20:16 | |||||
| S Apr 13, 2022 at 17:50 | history | answered | Brian | CC BY-SA 4.0 |