First of all, let’s recap how TOTP works: your authenticator app stores “TOTP password” in an accessible way (some apps store it plaintext, Aegis stores them in an encrypted DB. They can also be stored on Yubikey.). To generate one time code, the app takes the password, concatenates it with current time rounded to 30 seconds and compute a hash from this string.

The resulting hash is used to create a 6 digit code, that you’ll enter on login.

To check the code, server repeats the same procedure and compare your result with the just generated one.

As you can see, for this system to work you and the server must use the same hash function.

Conclusion: 1)Hash function in TOTP has nothing to do with password storage, it is used only for TOTP-code generation. 2) Cryptographic security of the hash function is not much a concern here: TOTP code expose an extremely low amount of information about TOTP password, so to reliably recover the password from TOTP-codes you’ll have to intercept millions of them.

I read the other day something about being a limitation that google official app only supports that and all the other are forced to use the same to be compatible.

https://lobste.rs/s/gqoj5n/passkeys_shattered_dream#c_bv8hpr

Also you can’t change it on your side, a server and the part tou have in your authenticator need to be in sync. There’s no point to change only on your side if the server was not configured to also use the same settings I guess.

I think this question might be missing the point of TOTP and protection it provides. The reason 256/512 is used to encrypt data and passwords is to prevent the possibility of brute force and other attacks (e.g. using other data breaches). This doesn’t really matter with TOTP. They can’t reverse engineer a TOTP password out of you. They can’t use your info from prior breaches to gleen what your TOTP might be anywhere else. It’s not something where “cracking” the hash is likely to be attempted, as an attacker would still have to capture the generated codes and time of input in some way, then brute force hashes until they generate one that produces the correct codes at x time. Why would they ever do that when it would be a thousand times easier to compromise a device or TOTP app, and scrape the hashes directly from it; negating any need to brute force?

Note: I am not a cryptographer and have not implemented a TOTP server, so I could be completely wrong.

TL;DR 256/512 wouldn’t necessarily increase the security of TOTP at all.

SHA1 was the official standard when TOTP started being widely deployed. I wouldn’t worry. If you look at how the hash function is actually used in the TOTP algorithm, it would be very hard to exploit SHA-1’s vulnerability to finding free collisions. It’s much more likely that either the server or the client app gets pwned somehow.

It’s up to every individual website to use whatever specific type of hash function they want, so absent of really technical users that know how to change the cipher, they all just default to SHA-1 for maximum compatibility.