I use Aegis as my 2fa. Today on new token creation I observed that there’s hash function set to SHA-1, later checked all my tokens and the result is same type of encryption used for all. So I have edited all my tokens to SHA-256 as a result my totp doesn’t authenticate. Do I have to rescan my tokens for updating to SHA-256 or it doesn’t work like that?
Security: SHA-1 < SHA-256 < SHA-512
Speed: SHA-1 > SHA-256 > SHA-512
My doubts are: Why can’t we use SHA-256? Is it because TOTP requires less time so faster one(SHA-1) is chosen? Can we use SHA-256 for TOTPs?
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.
And some TOTP apps don’t interpret the
algorithmparameter correctly, which makes it safer to go with the default SHA-1.Lemmy in fact was using SHA-256 for its earlier TOTP implementation and reverted back to SHA-1 since some people locked themselves out due to poor support in some TOTP app (among other issues, another was that the activation workflow never asked you to confirm the code you enrolled was working and generating the correct code…).
damn it.
correct
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.
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
Given a TOTP key is usually at least 18 characters for a 6-digit code, having only one data point sticks you with something on the order of 10^28 possible keys for a given singular code (way more if case sensitive). You’d need to be regularly intercepting TOTP codes to brute force your way to the right key, and even then it’d only be valid for a single site. At that point it probably means you’ve fully compromised the connecting device or server, at which point, why do you even need the TOTP again?
You should be using bcrypt or something similiarly designed to hash passwords, since they are much safer than sha256/512. Sha is not designed for hashing passwords and therefore a fast algorithm which you shouldn’t use for passwords
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.
The entropy of otp codes is low compared to the seed’s. I’d never though about what that meant for reversion. Good point !
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.
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.
