SSL VPN MFA autentification

Forum|Forum|9 years ago
July 19, 2017
6 replies
13737 views

There are new requirement from PCI DSS, that MFA autentification verification, should be done after all factors were submited.

At the moment fortigate SSL VPN client first asks for user name and password, and if they are correct, only then asks for fortitoken code. It should ask for user name, password, and fortitoken code, and only then accept or deny. So that user could not know which part of MFA was wrong.

Also it would be great if we could use the same fortitokens for administrators logon to device using MFA autentification.

Francisco_Beltran

New Member

hello, indeed my clients are in need of this same solution to be able to fulfill the requested by PCI. Have any roadmap or version already available with this change ?. to comply with these rules it is required that the key and the token are entered on the same screen, in such a way to prevent an attacker from knowing if the key you are entering is correct and what you would lack would be the token. when entering both together the attacker will not know if the fixed key is correct or the token is the wrong. (The idea is to make it more difficult to obtain the keys of the users to the attackers)

The fulfillment of this PCI application is for 2018 and must be met by the associated companies and/or PCI certified.

Thank you.

emnoc

New Member

The PCI-DSS requirement does not say that and breaks all aspect of any existing MFA. You are confusing multi-step and multi-factor.

Ken

Kenundrum

New Member

PCI DSS requires that all factors in multi-factor authentication be verified prior to the authentication mechanism granting the requested access. Moreover, no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented. If an unauthorized user can deduce the validity of any individual authentication factor, the overall authentication process becomes a collection of subsequent, single-factor authentication steps, even if a different factor is used for each step. For example, if an individual submits credentials (e.g., username/password) that, once successfully validated, lead to the presentation of the second factor for validation (e.g., biometric), this would be considered “multistep” authentication.

That is pulled from the PCI Multifactor authentication guidance document available at https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf

It does seem to suggest that the current way SSLVPN works would be considered multi-step multifactor and not what PCI wants which could be described as single-step multifactor. I imagine it would be an end user nightmare to see the mfa field if you don't need one. Maybe something like the first screen just has your username, once you put in a valid username, it presents you with a password and mfa field if needed. with no MFA, it would just be a password field.

I also learned from that document that PCI frowns upon sending one-time passcodes to accounts that are governed by the same authentication. So for example sending an email OTP to an account where the username/password is the same as the VPN negates the utility of it. Also- SMS is on its way out as an approved method of delivery since it is possible to compromise as well. I'm not sure where that leaves people other than with hard/soft tokens whenever those rule changes come into effect.

Sign up

Login with SSO

Login to the community

Login with SSO