Password retry upon failure

[drsassafras]

Right now if I type the wrong password to unpack an archive it ends in a failure notice and to re-try I need to try re-unpacking the archive.

I wager that the most common reason why an encrypted archive can decrypt is because the password was wrong.

Perhaps a better default behaviour would be to re-ask for the password. That would allow me to quickly type in the real password that I mistyped the first time.

To do:

• IF current brute force tools are OK, infinite retries with a 1-2 second/s delay, ELSE
• Limit to 5-10 tries per operation, after that end the operation and
• limit to 20-30 total tries per minute, after that end operations without offering the retry until a "cooldown" of 10-20 seconds

[aonez]

This was asked before (just can't find where) and always told no because of brute force attacks. But actually this might be done with some limitation to evade brute force use. Not sure here.

[drsassafras]

Brute force attacks rely on a massive number if retrys. Tens of thousands. Even if a password list is being used, one needs 100 or so tries for much success. But to really avoid dictionary attacks the only real way is to have a dictionary blacklist of the most commonly used passwords. http://doc.tiki.org/Password-Blacklists So if the number of password retry's was limited to 3-5 before the program shuts down (like it currently does) I can't see that that it would introduce a security risk. An attacker could still use the program the way it is now to brute force a archive. They would just need a macro to relaunch and retry. Or another application could be used to brute force the archive. So the security objective here isn't to prevent the archive from being brite forced, as that can't be prevented. It's to make sure your not providing a tool that makes it easier than the other tools they have to brute force. Your essentially reducing your own liability. There is brute forcing hacking tools out there that allow you to set frequency (to avoid overloafing) along with what kinds of characters to allow, and even have built-in dictionary lists to try. These tools are very convenient. I doubt there are many situations where Keka could outshine something like that. It's still good to make things difficult though. Limiting attempts (maybe 20-30 attempts per minute?) and forcing an application shut down after 5 unsuccessful attempts would likely make Keka more brute force resistant than no password attempt limits and shutting down every time. A bot would then have to be programmed to relaunch every 5 attempts and also to severely limit its attempts to accommodate the retry limitation. In short, I doubt anyone would even attempt it. Another tool would be selected to attempt the brute-force attack. Password retry attempts would also make the app much nicer to use for non-hacker users and I doubt that 20-30 unsuccessful attempts to decrypt an archive could be exceeded under normal circumstances. As a secondary note, the unsuccessful decryption attempts limitation would be best set per-application, rather than per archive and be persistent through application restarts so that multiple archives could not be attempted at once. Just a few thoughts. Brendan

[aonez]

@drsassafras thanks a lot for all your points. Synthesising:

• Limit to 5-10 tries per operation, after that end the operation
• Limit to 20-30 total tries per minute, after that end operations without offering the retry until a "cooldown" of 10-20 seconds

I'll research for those brute force tools you talk about before developing this enhancement, since if they're already convenient and well made just adding a 1-2 second delay between retries will make Keka be less efficient than those tools.

I'm really not against brute force, sometimes people lose it's passwords... But you know, not all is white 😊

[aonez]

@drsassafras I think you'll like to check to the latest development version, it has this feature 😊