Changing App Logic To Address A Password Reuse Attack

Changing App Logic To Address A Password Reuse Attack


Late one afternoon, it became apparent that customers of a loyalty card service were being targeted by password reuse attacks and customer reward points used to fraudulently acquire iPhones and other assets.

Given the nature of the service, both stopping the attack whilst maintaining the service and then the longer term authentication issue was a real problem. The company only had registered email addresses for clients and was reluctant to add complexity or multi factor rules to the service.

Given they already had RedShield’s generic threat protection service in place failed log in attempts were being detected and anomalous IP addresses blocked, however the attackers had moved to a fairly distributed network to obscure their Identity. As a result the company raised an urgent case on RedShield.

Note the company did not have a 24/7 dev capability and most of the devs were already unavailable.



RedShield’s shielding team immediately swung into action. Given the constraints that the business had proposed with respect to customer experience, ie the only form of identity is an email address and limits on using complexity and multifactor options in the solution, email authentication was proposed.

With this solution the application logic flow was changed to the following:

  1. On successful login the customer would presented with a splash page hosted by RedShield stating that “due to a security event a one time password had been sent to their registered email address and they must use that code to continue the process.’ The code entry field was displayed on the page plus a submit button.
  2. At the same time RedShield generated a 16 character unique code and sent it to the email address for the account.
  3. On successful retrieval of the password from the email account the customer entered the code and was let through to the application
  4. At the same time RedShield assigned an authentication cookie to the session to allow continuous browsing

An information note was also added to the company’s public website plus the company’s helpdesk was briefed.


Having the RedShield shielding team on call is like having your dev team available 24/7. The speed at which they modified our application behaviour without requiring us to do anything was astounding.



In less that 2 hours from raising an urgent case, the solution had been designed, tested, deployed into production and the attacker stopped in their tracks.

By changing the application logic 3 elements of defense had been implemented:

  1. By changing the application logic any automated tool would have to be modified to adhere to the new methodology. Given generic tools are often used horizontally against all logins that meet a specific criteria those tools would no longer work. Also given attacking is a business the cost to attack has just been raised which might discourage development.
  2. The is a chance, however small, that the email password and that reused for the loyalty service do not match and hence the service would truly be protected
  3. Customers now have notification in their email that activity is occurring on their accounts

The plan was for this to be a temporary measure whilst the business decided on their preferred final solution. Reality has been that the company has rolled out this solution to other apps and will get the dev teams to integrate this functionality nature into appropriate apps in upcoming releases

May 21, 2020