The downside to this method is that since the resulting cryptographic hash and salt have to be in the resulting file, so there is nothing stopping someone from pulling the hash/salt out and bruteforcing it locally (as opposed to being able to ratelimit login attempts on a server) if they are so inclined and have the required resources.. which may not be that much in the way of resources as the tool uses 1000 iterations of PBKDF2[1]. This is magnitudes lower than what OWASP recommends[2].
I wouldn't personally put anything you want secure behind this.
Right but all that's happening here is stretching. So the difference only matters in the middle. Regardless of the strategy bad guys will guess "1234" or "sesame" (too easy) and they won't guess a random 128-bit key I just generated with my hexadecimal dice (impossible). This weakness only means it's easier than expected to guess your password is "suckitelon" or "GoCowboys1978" or whatever
We put a lot of effort into teaching people to do better stretching, but it feels like the result was they put even more passwords on things, rather than using the breathing room to get off passwords. If your project for 2023 is "Use a fancier password hash" instead of "Get rid of passwords" you are Doing It Wrong™.
If you wanted to do something like this seriously, consider hmac-secret extension to FIDO, which means Security Keys (so the things you'd use to log in to say Google or Facebook) can present an arbitrary always-identical secret value which would be more than adequate to secure such a thing unlike a human memorable password. Today hmac-secret is mostly used to authenticate to an off-line laptop PC or similar.
Strong cryptographic keys should never be input using a keyboard and fingers, there are much better interfaces for that (security keys, passkeys, password managers).
I was thinking that I keep my secrets at hand in my password manager of the Keepass family. I sync the db from my laptop to my mobile devices.
The 100 characters password would be in the password manager but the secrets I would work with fit into the password manager, so I have no need to use a separate channel. I could upload the db, download it and just remember the master password.
The only use case for this technology is when the secret is the file itself and it can't fit in the password manager. An image, a file, etc.
TLDR: No. In fact, theoretically stretching the password is more effective than increasing iterations. However, I don't see him citing the fact some password hashing functions have limited input size, which means at some point having a larger password doesn't really change anything.
I wouldn't personally put anything you want secure behind this.
[1]: https://github.com/robinmoisson/staticrypt/blob/5dac008ba644... [2]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...