Timeline for Brute force prevention: where and when?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2017 at 10:42 | history | tweeted | twitter.com/StackSecurity/status/934371604372574208 | ||
| Nov 25, 2017 at 0:49 | comment | added | Criticizing Israel not allowed | @rew1nd If your server is properly secured then I can't change the code on your server. I can change the code on my phone because it's my phone, not yours. (If I really needed to I could open it up and solder extra wires on, but in reality there are easier ways) | |
| Nov 24, 2017 at 22:36 | comment | added | h4ckNinja | One thing to note is you can never prevent brute force attacks, you can only mitigate them. Implement mitigations like profiling (you normally login at 7PM, but now you are logging in at 4AM), checks across accounts (horizontal brute force), and other mitigations, you can make attacks harder, but never impossible. | |
| Nov 24, 2017 at 22:17 | answer | added | CGretski | timeline score: 0 | |
| Nov 24, 2017 at 19:35 | answer | added | kasperd | timeline score: 0 | |
| Nov 24, 2017 at 15:41 | comment | added | Soron | @rew1nd "The same way, that if i want with more time, i will reach your server and comment the lines that are blocking my attack." - at that point, you've got a major security breach, and the attackers will have ruined your production data and stolen all the password hashes for offline cracking. Server-side checks are something that you can rely on for brute force prevention, you just have to make sure to implement them correctly. | |
| Nov 24, 2017 at 14:48 | comment | added | el.pescado - нет войне | I think just adding label "Please do not try to log in more than three times" would be better. Way easier to implement and about the same effective as login throttling in client. | |
| Nov 24, 2017 at 14:09 | comment | added | Caterpillaraoz | "i will reach your server and comment the lines that are blocking my attack" is WAY WAY WAY more difficult that removing a limit from the app. You do not rely on "app`s code obscurity" for your safety. | |
| Nov 24, 2017 at 12:35 | comment | added | rew1nd | @S.L.Barth, yes mate. I accept your answer before he reply. Thank you both, i will pass the validation to the server. | |
| Nov 24, 2017 at 12:34 | vote | accept | rew1nd | ||
| Nov 24, 2017 at 12:27 | comment | added | S.L. Barth is on codidact.com | @rew1nd Thank you for the accept, but I consider mr. spuratic's answer better than mine. May I suggest you accept their answer instead? | |
| Nov 24, 2017 at 12:25 | vote | accept | rew1nd | ||
| Nov 24, 2017 at 12:34 | |||||
| Nov 24, 2017 at 11:36 | answer | added | mr.spuratic | timeline score: 23 | |
| Nov 24, 2017 at 11:18 | history | edited | S.L. Barth is on codidact.com | CC BY-SA 3.0 |
Fixed grammar.
|
| Nov 24, 2017 at 11:15 | answer | added | S.L. Barth is on codidact.com | timeline score: 7 | |
| Nov 24, 2017 at 11:04 | comment | added | rew1nd | @immibis The same way, that if i want with more time, i will reach your server and comment the lines that are blocking my attack. This is what i think, servers are also vulnerable. I came here to ask the best point to empower brutte force prevention, not no learn that android apps can be decompiled and code changed :) | |
| Nov 24, 2017 at 10:57 | comment | added | Criticizing Israel not allowed | You think serious attackers are going to use your app to log in? Of course they won't. I'm going to download your app, decompile it, comment out all the bits not related to logging in, run it on several servers and make 10000 login attempts per second, if I want to. | |
| Nov 24, 2017 at 10:47 | history | asked | rew1nd | CC BY-SA 3.0 |