We would like to use two factor authentication on all accounts that are accessing the service externally (i.e.; not from within our WAN). However, there is no way that we can ensure our customers (some are in restricted areas) would have a phone and/or be able to use an authenticator application. One solution that has worked very well in the past for us is email of one time password (OTP) for the 2FA with 15 minute timeout. When we first started using this it sounded sort of kludgy, but it has worked quite well if your mail server is reasonably responsive and your session time outs are a bit relaxed, say 12 hours or so.
In LF the email can't be considered as true second factor authentication. But you can keep the Strong authentication you have configured now (SMS, TOTP or DUO) and these restricted areas (networks) where users can't have phone you can list in the "Strong Authentication Exclude Networks" under the "Admin > Groups > edit > Authentication" tab.
Thank you for the response. I understand your perspective that OTP email is not considered "true 2FA". Unfortunately we have no clear way to pre-identify customers that would not support the strong 2FA and as such on other systems we have passively fallen back to email OTP as a better than nothing and compatible with all users. Using the described approach would require interruption in file access to users that would need to be reported to the system administrator then identification of their IP address(es) for exclusion. Bottom line is these external users will not know that information (I refer to some of our .mil customers) and it will cause frustration. I also admit that I am not a current product owner and am evaluating Liquid Files as a potential replacement for another solution that we currently use and I also understand that you have a vision for your product that may not be compatible with our needs. That said I do appreciate your responsive approach to customer support. Allen
no worries at all we aim to reply to all. Currently this OTP email form is not planned. We would probably have a look in to this if this authentication form would be frequently requested by other users as well. Now back to the OTP email more practically: If the main bottleneck was only that your clients don't have smart phones with an application for TOTP authentication, but users had at least some common GSM phone. Then the strong authentication could be easily solved by switching to the SMS authentication method built-in the LF appliance. Users would then receive the pin in the SMS. Similarly the authentication via SMS offers, If I remember, also the DUO.com service. If the clients did not have any phone, theoretically the OTP email could be solved in LF only as a workaround which would use a custom SMS Action scripting. You would need to create a script which would not send pins in a SMS via some SMS provider's API requests but it would send an email. A Snag is that SMS actions allow to save only a phone number (or a number) which is stored in the user profiles and this number is then passed to the SMS action script when the authentication is triggered. So in the script you would have to add also a hash table which would map the received user's number to user's email address to which the email with a pin would be sent. Annoying is that would would have keep updated the hash table with numbers and email addresses in the script manually.
