SMS Information and Best Practices
Problem
You would like to use SMS/text messages in PortalGuard
Solution
SMS/text messages are a powerful, efficient and widely adopted mechanism for communication and helping prove a user's identity. With PortalGuard, you can configure each of the following settings per security policy:
The length of the randomly generated One-Time Passcode (OTP)
The characters used to comprise the OTP
How long it is valid if unused
The message surrounding the OTP
Please note that while NIST does not list SMS as a “preferred” second factor method due to SIM swapping attacks, it remains an effective and sufficient method for many organizations.
PortalGuard supports multiple methods for SMS delivery:
3rd Party Messaging Providers - In this scenario, customers work with a provider directly to acquire an account and purchase credits. PortalGuard is then simply configured to use this account and makes real-time calls to the provider's API/service to send messages. Each usage of the service has an associated cost – most providers charge less than 1 cent per text message. Some also charge a fixed, nominal fee for each reserved phone line on the account (e.g. Twilio charges $1/month).
Use of messaging providers does incur extra cost, but it is recommended for production environments due to their reliability and speed.
PortalGuard currently has built-in SMS support for the following providers:
Clickatell
Esendex
MessageMedia
Plivo
Regroup
SMSMatrix
Twilio
Many of our California customers use Regroup because it has an “unlimited” plan.
“Custom” Configurations – If you have a hardware device on-premises that has its own HTTP-based API, you can configure PortalGuard to make call outs to it. This method can also be used to enable newer 3rd party messaging providers that aren’t directly supported in PortalGuard.
Full control over the HTTP request made by PortalGuard (GET or POST) and how the response should be interpreted to indicate success or failure.
Email-to-SMS Gateways – Many phone providers maintain gateways that can convert an email message to a native SMS freely. This approach is extremely unreliable so it should only be used during evaluation, if at all. Besides reliability, it also requires users to choose their phone provider from a drop-down list. They often gloss over this field, leaving the default, which can lead to delivery failures and end-user frustration.