The idea to "improve" security is as follows - the service will reply with a failure code even if supplied credentials are correct, but then on a second (third/whatever configured) attempt it will return a success and provide an auth token.

The rationale behind it is that even if there was a leak of some hashes/passwords - then the service will return a failure code to the "hackers" making them think that the password/hash they've stolen isn't valid.

One obvious flaw here as I see it is the overall increase in communication time due to retries, but the service in question isn't the one under high load, so that probably can be ignored.

Are there indeed any benefits here? Or is there any harm in this approach?

  • 2
    You will make your legitimate users miserable and they will stop using your service. I would personally consider that "harmful" to my business. Commented Aug 2, 2019 at 14:13

2 Answers 2


Outside of the obvious flaws in that it will increase communication overhead and that it will piss off users, how long do you think it will take before everyone realizes what's going on? My guess is somewhere between immediately and almost immediately.

And once it's known that your service is rejecting the first login attempt, what stops hackers from just running each hacked password twice? Or thrice?


Attackers will quickly learn to try passwords twice, while legitimate users will fail to understand what's happening.

That's security by obscurity, harming usuability for no good reason. Please don't do it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .