New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Password retry upon failure #249

Open
drsassafras opened this Issue Jul 29, 2018 · 3 comments

Comments

2 participants
@drsassafras

drsassafras commented Jul 29, 2018

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 aonez self-assigned this Jul 30, 2018

@aonez

This comment has been minimized.

Owner

aonez commented Jul 30, 2018

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.

@aonez aonez added this to the Look at milestone Jul 30, 2018

@drsassafras

This comment has been minimized.

drsassafras commented Aug 5, 2018

@aonez

This comment has been minimized.

Owner

aonez commented Aug 9, 2018

@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 aonez modified the milestones: Look at, Future, 1.2.0 Aug 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment