Blog Home > Authentication Security > Secure User Authentication for VPN

Secure User Authentication for VPN

PassiveKey for Virtual Private Network (VPN) provides the security of two-factor authentication by leveraging the end-user’s device, which abolishes the needs for the need for a hardware token and “pay per use” software-based solution. This approach is simple, minimizing the impact on end-users while addressing the number one problem of network attacks by hackers worldwide.

VPNs allow end users access to corporate network resources remotely. Secure authentication is the primary way to mitigate the risk that comes with remote end-users, but putting in place the proper levels of security can often cause problems for the end-users.

VPN users typically have at least one of the following options in place single-factor, certificate based, two factor authentication using hard tokens, and two-factor authentication using soft tokens. Single-factor (password only) is not enough to prevent unauthorized access to your VPN.

The newest alternative to these methods is “PassiveKey for VPN” this method leverages the users’ machine as hardware token. Although the users’ laptop serves as a hardware token, it will not be put in jeopardy by physical theft, since there is a strong Active Directory policy and the drive will be encrypted. This eliminates the need for key fobs, adequate cell phone reception and users do not need to manually enter One Time Passcodes (OTPs). PassiveKey still allows end-users to achieve two-factor authentication for security or compliance reasons.

The PassiveKey for VPN relies on RADIUS protocol, which is an Internet standard that was primarily designed to authenticate remote users for dial-up services. A RADIUS authentication exchange involves a “client” and a “server”, in this case the PortalGuard server acts as the “RADIUS server” and a Network Access Server (NAS) is the “NAS client”. The end-user only communicates with the NAS client that then sends the information to the PortalGuard server for validation.

VPN PassiveKey

The following steps detail how VPN for PassiveKey works.

  1. The user attempts to connect to the NAS/ firewall using either a browser or VPN client software and is prompted for username and password.
  2. The NAS communicates the credentials to the PortalGuard server using RADIUS protocol.
  3. The PortalGuard server validates the user’s credentials against its configured user repository (e.g. Active Directory).
  4. The user repository returns a success or failure code indicating the fidelity of the username and password.
  5. PortalGuard queries its security policies and user profile store to determine what features are in effect for the user and what requirements have yet to be satisfied.
  6. PortalGuard parses the data from the Portal Guard security policy and the user profile and see that the user is required to use two-factor authentication.
  7. Portal Guard sends a RADIUS “challenge” response that includes a custom message that will be displayed to the user.
  8. The NAS displays the custom message requesting the user to enter an OTP.
  9. The user presses the PassiveKey for VPN hotkey which automatically generates Time-based OTP, enters it into a field and submits it to the NAS.
  10. The NAS sends the OTP to PortalGuard using RADIUS.
  11. PortalGuard accesses its profile data for the user to validate the OTP.
  12. The OTP is validated.
  13. The PortalGuard server sends back a 2nd RADIUS response that the authentication is successful & complete.
  14. The NAS accepts the user’s authentication and the VPN tunnel/ session is established. The user is then able to access resources (e.g. “”).


Please follow and like us:

Author: thoey

Tom, PistolStar’s founder and CEO, has over 25 years of experience as a software engineer and is one of the main architects for the widely successful PistolStar product line. He also works closely with his core team to define the sales, marketing and product strategies that drive PistolStar’s growth and success. Prior to launching PistolStar in 2000, Tom was at Digital Equipment Corporation and Iris Associates, an IBM Lotus subsidiary, developing core functionality found in lower-level operating systems and in Lotus Notes and Domino.

Comments are closed.

Main menu