Found and I am researching FreeOTP and FreeOTP+ both support all of the parameters including algorithm, digits and longer key sizes.

Thanks to the good folks in SmarterTools support we find that SmarterMail is using 128 Bit Keys! That is very good, however, I would like to move to 160 as recommended by the smarter folks (than me) in the RFC!

Hello my fellow SmarterMail Techs!. Com'on "guys" -- are we not interested in stronger Security? We also need 2FA for Administrator Logons as well! For this account we need to back-up recovery code we can use just in case! 2FA is the best way to protect SmarterMail against Phising. I just had a customer Phised and then the hackers wrote eMails to all of his family, friends, customers and vendors trying to SCAM them!

We did 160bits for our control panel and found many users complaining of apps not accepting the token or accepting it, but not generating correct tokens. As well... 2^79 evals of HMAC hashes will take a lot of GPU power and even much much much more for 2^127. Even if the attacker got/guessed the main webmail account password, it would take them forever to get a token, even brute forcing it would take considerable time since web servers dont respond instantly, and I am sure IDS blocks would kick in.

The only other real issue coming from the 2FA system are app passwords, where if a user's computer is compromised and the password from Outlook or Tbird etc. is exposed, no 2FA will stop them now (depending on the password and what service it was for, if it was SMTP/POP/IMAP, they can now just start pumping out emails).

I don't see this issue with apps not excepting the 2FA Codes at all. I've been using Google Auth and equivalent for years. Your problem could be time Clock Drift. The RFC behind HOTP use time as "salt" in the computation thus the clocks in the Token device and Server have to be very closely synced with "real-time" -- NTP does a great job to solve that. Given time clock drift concerns between the Token and Server validating the 2FA Code -- I counsel my customers that if the 30 Second count clock on the Token is less than 8 to wait until the 2FA Code cycles. Works like a charm!

Also, the App or Machines generated passwords are very strong IMHO as they are number letter jumbles and can't easily be guessed or dictionary attacked given SmarterMail has a baked-in IDS. Since the end users have stored the App password in the "machine" (aka Outlook, PC, SmartPhone or Tablet) thet would be fairly hard to get to them (not impossible) unless you are NOT using TLS. If the hacker has gotten into a device, IMHO, you are already in a heap of trouble.

Most of the problem for me has been *dumb* users giving up their passwords via Phishing -- I just had this happen twice in the last few weeks! If they don't know it or readily have access to their App password, then they can't give it up!

FInally, IMHO, the model that I provide to my customers is to provide multiple security layers to harden the Servers, PCs, and Network so the hacker will move on to softer targets.

I am very well aware of how HOTP works :) All of our servers are sync'd to within ~100ms of "real time" with a local GPS time source (with fallback to University of Colorado in Boulder, NIST). So, it's not a clock issue. The problem went away when we down to 128bit. We've not had any issues so far of customer devices having time out of sync.

The passwords are strong, but it doesnt stop customers giving up passwords or getting a virus/malware that is able to get the password from their local email client. Retrieving passwords from Outlook using an app running on the local machine is very easy, and there are many apps that can do it with a click of a button.