Follow RFC4226 recommendations and increase shared secret key to 160 Bits!
Idea shared by Howell Dell - 2/21/2022 at 3:55 PM
It took quite some time for 2FA to arrive inside of SmarterMail. However, it's time to up the ante and make the security better!

https://tools.ietf.org/html/rfc4226 says "4. Algorithm Requirements. R6 - The algorithm MUST use a strong shared secret.  The length of the shared secret MUST be at least 128 bits.  This document RECOMMENDs a shared secret length of 160 bits.".

As we seen with SSL, the security folks have increased the key bit strength over the years to 2048 bits and support for 4096 is on the horizon. We have also updated from SHA1 to SHA256 for hashing functions of data in SSL Certificates. We know that SHA1 has issues and is being phased out.

However, while digging through Google's git log for TOTP, their code has been generating 80-bit keys since March 26, 2010, commit 35ae38faf1a7a55b8d1808d893d2e4c4a1ef7824. I think SmarterMail is likely using 80-Bit Keys as well.

In addition, to the bit strength I would like to see support for SHA256 or SHA-512 hashing functions and more 2FA digits beyond 6 -- say any length from 6 to 12 digits.

I'm not sure that either Google or Microsoft TOTP apps that support these parameters, however, Google's URI for TOTP supports both "algorithm" parameter values: SHA1 (Default), SHA256 and SHA512 plus "digits" parameter determines how long of a one-time passcode to display to the user. The default is 6 and the spec mentions 8, however, I've seen 9 digits in the wild. Here is the URI spec from Google: https://github.com/google/google-authenticator/wiki/Key-Uri-Format.

If anyone has an idea on Android Auth Apps that support these "algorithm" and more digits" parameters, please update here. For SmarterMail these parameters (seed key length, algorithm, and digits) should be options at the domain level with system wide defaults. And of course, like many things in SmarterMail have feature settings to allow or disallow the domain admin override.

We also need some increase bit strength for machine passwords as well!

6 Replies

Reply to Thread
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.

Reply to Thread