Timeline for Why do some sites enforce low-security passwords?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 20, 2020 at 21:01 | comment | added | rackandboneman | @dmuensterer in a way, displaying a plaintext password in a web app is, while not caterogically wrong, a strong "good reason or no reason" thing :) | |
| Oct 18, 2020 at 1:45 | comment | added | supercat | Using a hardware password storage module can mitigate the dangers of decryptable passwords, while allowing for the possibility that a company might acquire a system that stores passwords differently. If two companies that use hashed passwords merge and want to unify all of the accounts under one system, that may be difficult if both of the original systems use passwords that were hashed differently. | |
| Oct 17, 2020 at 19:27 | comment | added | ramatsu | Yeah, Legacy software was my #1 theory above. Very familiar with the issue, but still somewhat amazed that those systems haven't added front-end security layers in more modern frameworks. Would the middleware be vulnerable? | |
| Oct 17, 2020 at 16:07 | comment | added | dmuensterer |
@rackandboneman Well, any current system that stops you from using <script> in your password is clearly doing something wrong. There are methods in almost any programming language to convert HTML entities so there is really no excuse.
|
|
| Oct 17, 2020 at 5:10 | comment | added | l0b0 | @ToddWilcox Surely you wouldn't apply XSS injection checks to absolutely every field? You wouldn't be able to send basically any binary files to the website. | |
| Oct 17, 2020 at 4:09 | comment | added | Todd Wilcox | So one annoying problem with trying to use <script>alert('XSS!')</script> as your password is when the site has a filter for XSS, SQLi, etc. between the client and web servers/service that processes the password field in the form data the same way as the other fields. If you put anything that looks like XSS or SQLi in the password field, it can get rejected before the web server even sees it. BUT, that has nothing to do with the question at hand. | |
| Oct 17, 2020 at 3:12 | comment | added | rackandboneman | @dmuensterer semi-lazy programming - someone might simply have built a sanitation function that restricts the character set on any non-fulltext input severely. And applied it to the password too. Used to be not such a terrible practice in pre-Unicode times :) | |
| Oct 16, 2020 at 18:47 | comment | added | dmuensterer | +1 for "If I want my password to be <script>alert('XSS!'), what's the problem?</script>". | |
| Oct 16, 2020 at 18:45 | history | answered | ThoriumBR | CC BY-SA 4.0 |