What, it is 2025 and we don't have a way for a function to return an error code, or exception, or a way to propagate these errors to UI? (…)
We do. You still need to detect it, handle it, produce, test, and maintain that UI and entire separate scenario, clearly explain the situation to the user, deal with users confused by the grapheme vs byte count, have the user re-fill the password field (it’s cleared on the error). Compare that to just taking first 72 bytes of the input, which does exactly the same in 99.999% of cases, and works in 100% of sane
(1) cases.
While I do understand (and agree with) the opposition to truncation to absurdly short lengths, I don’t get the negative stance on truncation in general. It will be done anyway, because it has to be: during the KDF stage.
I'll have to look at a password manager then. Just do not like the idea of saving my passwords in an unknown program, I have no idea what it will do with the passwords. Also putting all my eggs in one backet feels like..... But it seems its the way to go. Thanks
Don’t put it in a random program. Choose wisely, set a good master passphrase, do monthly backups on a separate medium. You also can have multiple password databases, so it’s not exactly all eggs in one basket.
Also mind that having it all written in a notebook is also “all eggs in one basket,” except the basket is plaintext. Or, worse, not writing them down, but instead keeping in your head. Which universally leads to choosing weak passwords or — even worse — reusing passwords (or their fragments) across services.
(1) Having an over 72 byte password is some serious misunderstanding on user’s end.