SSL VPN MFA autentification

[Salas]

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]

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]

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]

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.

[emnoc]

Yes that's correct if you follow the PC mfa guidance document and the scenario that exist you should be good. But to assume you send all aspect for ALL factors at one time is not correct understanding of a MFA platform.

read  the   above reference  "Guidance for Multi-Factor Authentication  v1  PCI-DSS " document from the PCI community  and the independence and types for MFA.

[Kenundrum]

I disagree. The section of the document I quoted above and all other sources I have found would make the fortigate implementation non-compliant. Submiting the username/password/token at the same time is not the issue.

The issue is that the standard wants no indication of success or failure until all factors are entered.

The current process is, type in username/password, if successful, you get presented with a token input, if successful you login. If you type in the wrong username/password, you get an access denied message right away, confirmation of failure. What they want is even if you type the wrong password, you still get presented the token input screen. This poses complications for usability unless all the fields are available on the first login screen. Is it supposed to present the token screen and not send a code? Or maybe send the code anyway? How would legitimate users know what they are doing wrong?

Honestly- I am not aware of any implementation that currently has it set up that way. All of the services I use that have MFA first confirm the password, then ask for second factor. My suggestion of presenting the username first, then presenting a password prompt along with a token prompt seems like the most logical step if you have to send out a token code since you need something to trigger the send. Then if you fail, you won't know which one you got wrong, just that you have a valid username. Conceivably you could also program the system to present even a bad username with the password/token prompt just never send out a token code to limit the ability to deduce usernames. This can also present a DoS scenario where someone just remotely hammers the right username and keeps sending OTP since they wouldn't need the password to be able to trigger it. The legitimate user wouldn't be able to determine which OTP to use when they actually are trying to get in because they have hundreds to choose from.

[emnoc]

hmm

Honestly- I am not aware of any implementation that currently has it set up that way. All of the services I use that have MFA first confirm the password, then ask for second factor.

I recall a meeting with an auditor-team and that was mention, None of the  applications that uses MFA application.  Did you see this clarification tho.

http://blog.securitymetrics.com/2017/05/new-multi-factor-authentication-supplement.html

It speaks about common loopholes in MFA and securing each factor from risk or compromised leading to a total compromise of the  MFA process.

At y day job, on my desktop I run  a EntrustIDGuard-token-APP  and Authv plugin in  Chrome. In   the new PCI-DSS requirements this would be  not acceptable for MFA

e.g

My laptop is stole and or compromise , now my MFA-authenticator is at risk.

I think that's what the new PCI-DSS auditor are looking at, they don't want one factor being compromised leading to all other  factors being compromised.

So in my  friendly above example, if I used  SSLVPN FC with username/password and certificate ( 2nd factor " something I know and  have "   ) and the certificate is on my laptop. My username/password is compromised and let's say the vpn-user-certificate is not passphrase protect, now my remote-access is compromised and at risk if my laptop is  lost or compromised.

As long as your not doing something similar to the above , and can show/demostrate to  the Auditor that is not in use , then you should be okay.

Conceivably you could also program the system to present even a bad username with the password/token prompt just never send out a token code to limit the ability to deduce usernames.

That would be good ideal, a lock out for unsuccessful logins is ever  better. I believe most system have lockouts capabilities natively.

I rolled out some MFA with vpn for fortigates last year and finally worked up  a blog post about it . DUO was one of the MFA that we've liked the most  and it was very good for securing a wide audience  with MFA

http://socpuppet.blogspot.com/2017/04/securing-fortigate-sslvpn-with-mfa-by.html

Ken