Timeline for How can I prove this site has a huge security weakness?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2017 at 12:22 | comment | added | Out of Band | Here's a question with content somewhat related to the cracking idea (it points out the importance of "rules of engagement"): sqa.stackexchange.com/questions/27551/… | |
| Jun 3, 2017 at 7:38 | history | edited | Out of Band | CC BY-SA 3.0 | added 971 characters in body |
| Jun 3, 2017 at 7:23 | comment | added | Out of Band | @Chris: Panic users: Not really. Users don't know that their passwords aren't actually stored in plain text. So if they get an e-mail telling them that their password is deemed too weak, please change it, that won't panic them. Look at it like an "after-the-fact" password strength meter. As to getting fired: Anyone who has access to web app source code can change it to log passwords. That's even worse than logging cracked passwords, because it gets 100% of credentials. But: Nobody gets fired as long as they don't actually log passwords. Same thing. Don't log, don't get fired. | |
| Jun 3, 2017 at 7:19 | comment | added | Out of Band | @Zach, well put, I agree. | |
| Jun 3, 2017 at 0:00 | comment | added | Chris Hayes | The 'aside' just seems extremely likely to get somebody fired, or at the very least panic a bunch of your users (perhaps deservedly, but that's still not going to end well for most people). | |
| Jun 2, 2017 at 21:43 | comment | added | Zach | @Pascal, I find the Aside in this answer concerning. This is simply not a common practice when integrating with a less-secure system. Since you are advising someone who is admittedly new to security there is a significant risk that they will not have the domain knowledge to determine if this is an appropriate approach for them to take or not. Choosing wrong could be damaging to them (professional embarrassment, violation of the other party's TOS or trust, etc.) If I'm wrong and this practice is used in the wild. I would absolutely love if you could provide a source. | |
| Jun 2, 2017 at 20:51 | vote | accept | Daevin | ||
| Jun 2, 2017 at 18:59 | comment | added | user123931 | I meant every password the attacker knows the host tried can be skipped. An uncommon list minus a common list is much better than a common list though, so I was not thinking it through. | |
| Jun 2, 2017 at 18:40 | comment | added | Out of Band | Do you help the attacker with the self-cracking idea? Not really, because you don't keep the cracked passwords around for someone to find - the aim is to find weak passwords, not to keep them on record. So if the attacker isn't already on your cracking system (which doesn't need to be accessible from the internet), you should be fine. Is this idea used in practice? I don't know. I'd say it doesn't make sense with professional setups that use password hash functions such as bcrypt, because with them it would be a waste of time. But if I was forced to use weak hash functions, I'd implement it. | |
| Jun 2, 2017 at 16:56 | comment | added | user123931 | Is that automated self cracking idea used? It seems like a host wouldn't typically want to put in a significant fraction of the expected effort of an attacker, and if the fact of the self cracking was revealed it means that effort is given to the attacker. | |
| Jun 2, 2017 at 16:21 | history | edited | Out of Band | CC BY-SA 3.0 | added 464 characters in body |
| Jun 2, 2017 at 16:10 | history | edited | Out of Band | CC BY-SA 3.0 | added 771 characters in body |
| Jun 2, 2017 at 16:03 | history | answered | Out of Band | CC BY-SA 3.0 |