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.
this post was submitted on 07 May 2024
39 points (97.6% liked)
Privacy
32173 readers
353 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
And some TOTP apps don't interpret the algorithm parameter 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.