Introducing Second-Factor Authentication (2FA) Shields

Written by RedShield Security | Jul 29, 2021 1:59:59 AM

Today, we are excited to announce a brand new function that RedShield has developed to address a specific requirement – preventing malicious users from logging in to compromised accounts.

Compromised accounts due to password re-use, credential stuffing attacks or compromised email accounts remains a major problem globally. Many organisations particularly with older applications or with limited development resource struggle to be able to implement 2FA due to complications or simply prioritisation.

Today RedShield can now offer an easy to implement and cost-effective alternative for organisations struggling with these challenges - 2FA shields.

What are 'shields' and how are they executed?

RedShield’s developers create custom software objects called “shields” that execute on our edge compute platform which enables us to modify application behaviour to fix software bugs. With this approach, RedShield is able to achieve very similar results to a full stack development team without having to touch source code.

In this instance, RedShield’s development team have created SMS or Time-based One Time Password (TOTP) 2FA shields, designed to prevent attackers from logging in to compromised accounts.

How do the SMS-based 2FA shields work?

If accounts are already compromised, the SMS-based 2FA shields will prevent attackers from logging in with legitimate credentials. The shields work by requiring users to provide a code supplied via SMS message to their cell phone number. Without changing your application code, this solution has been designed to:

Handle all exceptions and serve the correct error pages or messages to the user;
Connect to an API (e.g. Twilio) to send the code via email or text message;
Perform the verification of the SMS code;
Confirm the responses are valid;
Manage the number of second-factor attempts and display an error or message appropriately; and
Submit the login request to the application server once all checks and balances have been met.
If the user does not have a mobile number registered to the account, and the email provider is believed to be uncompromised, shields will fall back to sending an email as the second-factor challenge.

This solution has been designed with your customers’ experience in mind; the shield will hook into the existing application code so the second-factor challenge can be presented without needing to reload the page and lose any details the customer has already entered.

For further information and full shield details, please see the detailed product descriptions for:

For a demonstration and consultation, please contact us

View full post