0

I was thinking about password security and thought about a possible way to slow down brute force attacks.

The imaginary login process should simply decline passwords one or two times, even when they are right. While this is bad UX and has to be explained to the user, it weakens the chance to make easy passwords guessed by dictionary attacks etc. at least by the factor 2 or 3.

Are there any more downsides, beside the mentioned bad UX?


Addition:

What do you think about positive impacts regarding

  • Phishing
  • Social Engineering

Stolen passwords wouldn't work on first try. Depending on attackers knowledge about the system, even successful stolen passwords could get marked as "not working".

To save UX, it could just pop on unknown devices.

Downsides: security through obscurity?

Luckily, I don't plan to implement this as a "feature", it's more about theoretically thoughts.

  • Bad UX is the worst enemy of security. :( – Sas3 Jun 10 '17 at 9:30
3

Bad UX kills security. Most users will look for work-arounds - and you'll be fighting your users instead of helping them / working with them.

I suggest you try this age-old technique instead. I saw this first in Open-Radius authentication and immediately liked it.

Use a time-constant, delayed response. i.e., even if you complete the verification in the back-end quickly, wait for a random time that adds up to 1s or thereabouts before responding to the user. It has multiple advantages. One of them is to discourage bruteforcing by reducing the attack speeds.

It does have a small cost though. If you have a high-traffic system then at peak times you may have too many open connections. That's not a big problem as long as you configure your software to compensate.

  • Yeah, that's a good point, slowing down the process is useful. I guess, certain systems (nginx, nodejs) don't get that much hurt by opening many connections. But for all, I added one thought to my question. – Florian Senn Jun 10 '17 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.