is descriptes the Problem to the tutanota support team @ github and they said its an app Bug.
The TOTP settings are correct base32 and 30 seconds 6 numbers.
But when you add the secret(i striped it from blanks) you getting an error - which is basically a string violation because it exceed its size.
I would appreciate if someone fixes this bug!
please try to not strip the blanks and copy and paste the secret “as is”. As far as I remember you do not have to strip these when using google authenticator either, so maybe something went wrong there…
I try to login within this service to get a look at it these days.
i copy paste the sercet into the nitro key app - same issue.
2 to 5 seconds before crashing …
TOTP is working in other mail clients like Proton mail. Without debugging the app its getting tricky.
for your information: I am on it. Afaik I need a premium account to test the beta OTP functionality of Tutanota. Therefore I asked Tutanota to get premium access for testing purposes. As soon I can test it, I will have a look how to debug and submit an issue on Github eventually. So please stay tuned.
I opened a issue on Github. Thanks for your feedback!
should work fine now. https://github.com/Nitrokey/nitrokey-app/releases/tag/v1.2
I am sorry for any inconvenience and thank you for your feedback!
Thanks, yep its now working tested it with 1.2.1 and my Tutanota account.
A smal hint for users with TOTP - check your clock settings.The protocol is time based a small offset of 45 seconds can break it…
I am glad it works for you! Just to elaborate: whole thing could be even more complicated. TOTP works on assumption, that both sides will have the same result basing on the UTC clock and shared key.
The breaking offset depends on:
- what is your TOTP configuration period (30/60 seconds or more - the bigger value, the less chance for failure),
- your typing speed (will you enter the OTP code during the period)
- and the server implementation (is it getting the code on its side before you enter the code or after or would accept the both - my guess is it should be the latter).
Not to mention, that you might be caught on the verge of periods - that is the code will change in the very moment after you will get it - e.g. if you have 60 seconds period then the code will change every minute. If you are getting the code on 11:59:59 and clicking the send button 2 seconds later then it might be rejected (depending on server-side implementation).
I learned it the hard way
After studying the https://tools.ietf.org/html/rfc6238 basics of the Alogrithmus i had a hint.
In my limited free time i play sometimes games which are only playable on windows.
So im normally a linux user, for this a dualboot implementation is perfect but it has its problems.
Linux synchronizes with GMT time, Windows tries to synchronize with your local time zone.
That skews every time the clock and also breaks the TOTP(the other factors are also an potential error source)
You can easily fix it in windows with a registry fix.