Support for 2FA OTP tokens

One big issue with the approach Helm has taken in relying on other email clients is the inability of clients to support OTP 2FA tokens. This leaves Helm email accounts relatively insecure and inappropriate for use with any accounts of high importance (eg online banking), in my opinion.

I’ve made this point with Helm customer service and they didn’t seem to take this security shortcoming as seriously as I would have hoped they would.

Is the only way to address this issue is for Helm to create its own suite of clients?

1 Like

YubiKey support would be nice, too.

1 Like

If the answer is yes, then I could see the point of having to constrain their implementation to only what popular email clients support in terms of authentication. I would almost certainly not want use a proprietary email client from Helm or anyone else. If there were standardised extensions for IMAP and SMTP authentication that supported FIDO or TOTP, then I would hope Helm would include them in their product, but if no popular email clients used them, then there would be little/no benefit.

Lots of IF’s in my comment above, granted, that could be answered by someone far deeper in the state of email protocols…

1 Like

I’m not smart enough to know how important OTP 2FA tokens are but I agree that it might be hard sell to get some users to give up their feature-rich/favorite email client for a Helm proprietary replacement.

I think 2 Factor Authentication would be very nice on email clients we use with Helm. I’m using a personal domain as most are. I haven’t tested any vulnerabilities. @transatlantic have you found vulnerabilities specific to a client or just trying to stay ahead of potential risk? I would like to try and duplicate any vulnerability on my end if you have experienced a major issue.

I haven’t found any vulnerabilities. I’m just concerned about the fact that the only thing securing a Helm email address is a password (and the trivially easy to obtain account/server details).

The fact that the default auto generated password by the Helm app is relatively short is also not inspiring confidence that Helm takes security as seriously as I’d like.

It’s great to have the privacy that comes with running your own email server, but that privacy is completely undermined if attackers can gain access to your email because of inadequate security protection.

Hoping that Helm can find a solution to boost security. Love Helm’s mission and want to see them succeed.

I wouldn’t want to use a proprietary client on the desktop, but an app I’d be OK with. For a desktop client, the easiest and fastest way to add support would be by setting up browser based email access.

1 Like

Let’s clear up a few things -

First, Helm user accounts and passwords can only be generated via the Helm app. The Helm app has 2 separate factors for authentication: the password you create and a proximity token that is generated when the administrator has paired with the Helm server. The proximity token generates OTP style passwords to enable authentication to the Helm server alongside the user’s admin credentials. This concept is similar to how online services can generate “app specific” passwords with an important caveat that we require 2 factor authentication to generate these passwords with the second factor coming from physical proximity at the time the device is configured. We have taken this approach because IMAP clients do not support OTP tokens for authentication.

Second, Helm only supports authentication over TLS so your user account credentials are never sent in the clear. So there is a chained 2 factor authentication flow from the credential creation to authentication. Over time we would like to see IMAP clients add support for OTP tokens and we may choose to roll out our own clients that support this as well.

Lastly, user account passwords are 20 characters so auto generated passwords are not short as previously suggested.

Just to comment…

Proximity tokens suck for remote users. They don’t work, and the work around is an inherent security risk itself. It’s a horrible process that requires the device admin to change passwords for the users, and then forward them to the remote users. The concept is great for local users, but not remote.

One time 2FA is NOT real 2FA. This is a bad argument, easily bypassed by any number of malicious phone apps that decide to look for an installed Helm app. Or see the above user password change scenario above.

20 characters is great, but lets not forget that the character set is ONLY 36 characters. You have removed upper case and special characters from the randomly generated passwords.

Also, could always set up client certificate authentication for IMAP. Not an OTP, but it would be an actual 2FA and is supported by multiple clients.

1 Like

Thanks for your feedback. We are working on improving the experience for adding remote users.

The 2FA is not one-time. The proximity token on the device generates a OTP for each authentication back to the Helm server for administrative functions in the Helm app. You say this can be easily bypassed by malicious phone apps - can you give any examples? We would like to understand this better.

We’ll look into client certificate authentication and evaluate that for our roadmap.

Sorry wasn’t clear, but I was specifically referring to service login, not administrative use. Email login does not use 2FA or OTP.

I thought you were stating that these services were using 2FA. The concern was basically typical malware. Instead of looking for installed banking apps, look for an installed Helm app and scrape login information. If the user is an admin, that means the malicious app could scrape the login information for all users since those are presented in clear text to the admins.

The benefit of adding FIDO support to a local browser based email client would be that it should then be simple (for someone not me, lol) to add that support to the NextCloud implementation as well. No idea if the current gen hardware can support the resources for multiple client connections though (NextCloud already a bit slow).

1 Like

Correct, email login credentials are generated using a 2FA/OTP process but the login process does not use 2FA/OTP because of limitations in email clients.

Are there apps you can point to that do this scraping you describe? Our understanding is that these are risks if a device is rooted or if the user grants apps permissions that go too far. This is one reason why in the mobile apps, passwords are masked by default.

Considering I will only buy phones I can get root on so to protect myself from malicious ads, yeah, it’s a risk. Mitigated by the fact that I am very careful about the apps that go on my phone. Unfortunately many users are not.

Here is an example of malware that presents a fake UI to harvest FB credentials…

Not screen scraping, but I imagine some users might fall for it.

Also, passwords are not masked in my app. I can see user’s passwords when opening the app. I’m not sure about what would be required to create malware that opens installed apps and I haven’t looked at the folders to see what data is stored locally.

We don’t recommend using rooted devices for most users. The example you provide was distributed on a 3rd party app store - something we don’t recommend most people use to source apps for their devices. And you’re right, it’s not screen scraping either. This type of attack wouldn’t be very effective against a Helm user given that user credentials don’t work without the proximity token and device-specific passwords for clients are only to be used within an email client. A fake email client is a possibility but this type of attack would not be unique to Helm or be defeated with 2FA/OTP as a fake app could proxy the credentials.

Can you please send support what screens you are talking about where you can see user’s passwords when opening the app - I just reviewed it for the admin and secondary users and all passwords are masked by default. Perhaps you’ve unmasked a password and that state has been preserved when re-entering the app.

Yes, this was the main point of my post.

Can you discuss what you think might be done to address this issue in the future?

Thank you.

Just to clarify, I stated they were “relatively short”.

Agree that 20 characters is not “short”.

Open App > Menu > User Management > User > Email, Calendar and Contacts > Email Address > Device Credentials = username and pwd displayed in clear

I’m totally on board with Helm having a different risk profile than say a Gmail account using 2FA. I will still take the Helm option as a lower risk to my data (obviously), but it doesn’t mean I wouldn’t like to have additional security layers. I would really love to be able to use 2FA with NextCloud as well.

There are a LOT of features I would like to see make it to the Helm that would basically turn it into a “cloud in a box” solution. As it stands, with no additional features, I will still prefer it over something like Gmail. I’m still going to ask for more though! :smiley:

Speaking of, I got this for Xmas and still have nowehere to put it…

1 Like

I have the same SSD and keep checking to see if there’s been any updates on the SSD, but no dice. On the site under features tab it shows the follow excerpt:

Expand Helm’s storage capacity up to 5 TB by adding an additional drive.
firmware update coming soon

Let’s hope “soon” has the same meaning as the Webster dictionary. The SSD is a game changer and was the deciding factor for me to purchase my Helm.

Yeah, I remember reading about it in the Ars article a while back. Was also a contributing factor to my purchase. I know it’s been on their roadmap for a long time since they built the removabele sled into the hardware. I assumed it would be an easy update, not sure what problems they must be running into for it to take so long. I was really surprised to see NextCloud file sharing get integrated without it.