Timeline for How to deal with password schemes that can produce weak passwords?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 9:49 | history | edited | CommunityBot | Commonmark migration | |
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot | replaced http://security.stackexchange.com/ with https://security.stackexchange.com/ | |
| Oct 31, 2014 at 23:18 | history | edited | perry | CC BY-SA 3.0 | added 138 characters in body |
| Oct 31, 2014 at 23:08 | history | edited | perry | CC BY-SA 3.0 | added 138 characters in body |
| Oct 31, 2014 at 22:19 | history | edited | perry | CC BY-SA 3.0 | added 625 characters in body |
| Oct 31, 2014 at 21:29 | comment | added | perry | To address the OPs "Additional example", one would simply generate another password if they rolled a 0000. I thought that was too obvious to mention. | |
| Oct 31, 2014 at 21:27 | comment | added | perry | So instead of addressing the real problem, which is using a web service that does nothing to thwart attacks, we are OK to turn a blind eye and keep touting "stronger passwords" as a solution. Seems a bit misguided to me. | |
| Oct 31, 2014 at 21:26 | comment | added | perry | Take Amazon Web Services as an example: These systems provide basic but important security measures such as distributed denial of service (DDoS) protection and password brute-force detection on AWS Accounts. | |
| Oct 31, 2014 at 21:26 | comment | added | perry | xkcd mentions 1000 guesses/sec as a plausible attack on a remote web service. I would hope any user reading this experiences a strange twitch in the eye brow. Why design or use a web service that is open to being massively flooded or brute forced? It's like using a public Wifi at Starbucks - maybe nobody will snoop your traffic on Tuesdays, but maybe that's because Joe bad guy doesn't get coffee on Tuesday. Regardless of how the day pans out, you're constantly at high risk. Users need to know this. Nobody has raised the issue. | |
| Oct 31, 2014 at 17:55 | comment | added | Chris Murray | I think your answer is useful, if the question was "How can I mitigate users picking bad passwords/losing their password". However, the OP is infact the user picking the password and not the developer mitigating the issue. | |
| Oct 31, 2014 at 17:51 | comment | added | perry | As a side note, I try not to give redundant answers that I know someone else has or will provide. I think my answer adds a lot of value to this question. | |
| Oct 31, 2014 at 17:46 | comment | added | perry | It's an alternative answer, but it definitely addresses the question, which was "How to practically deal with the fact that your properly generated password may actually be or become weak?" Practically all passwords are weak, live with it and optimize/mitigate elsewhere. Just because John the Ripper can't crack a 4 word password today doesn't mean it can't be engineered to crack those tomorrow. A 25-GPU array can perform 350 billion guesses per second and you know what? Tomorrow's GPUs will do twice that. Will tomorrow's passwords be twice as long to compensate? | |
| Oct 31, 2014 at 17:28 | history | edited | perry | CC BY-SA 3.0 | added 194 characters in body |
| Oct 31, 2014 at 17:02 | comment | added | Chris Murray | I don't think that this addresses the question the OP made. | |
| Oct 31, 2014 at 16:52 | history | edited | perry | CC BY-SA 3.0 | added 147 characters in body |
| Oct 31, 2014 at 16:13 | history | edited | perry | CC BY-SA 3.0 | added 12 characters in body |
| Oct 31, 2014 at 16:06 | review | First posts | |||
| Oct 31, 2014 at 16:19 | |||||
| Oct 31, 2014 at 16:04 | history | answered | perry | CC BY-SA 3.0 |