What you have been doing is unconventional, but is cryptographically safe, and should be fine as long as the implementation of
pbkdf2-hmac-sha256 is correct. Things to watch out:
- is all the stuff (characters?) in
salt safely kept by whatever
- is this
secret then converted to octets without entropy loss on entry of
pbkdf2-hmac-sha256 ? Changing anything non-ASCII to
? is a goof that has crept; combined with use of a foreign language, overly paranoid user, or an endianness problem, that could degenerate to the length of the secret being the only entropy left! Another issue that can creep is stopping at the first zero octet in
- Does the
pbkdf2-hmac-sha256 implementation correctly handle the case when
secret, converted to octets, exceeds 64 octets? The action
pbkdf2-hmac-sha256 should perform in this case is to replace these octets with their 32-octet SHA-256 hash.
Given this, the worst I can think the unconventional use of
pbkdf2-hmac-sha256could cause is that timing execution could leak the length of
password in an easier manner, but that's a non-issue.
Before that comment, I knew no language where 100_000 is a valid constant. More importantly, a hundred thousands is an insufficient iteration count nowadays for PBKDF2-HMAC-SHA-256, a short memorable password, and protecting a key from exhaustive search. Modern password-based key derivation functions make use of memory, sometime multiple execution threads, to greatly increase their effectiveness at a given execution time or cost, e.g. scrypt, Argon2, Balloon.
Note: implementing the core of PBKDF2-HMAC-SHA-256 in something that ultimately is interpreted rather than somewhat compiled would be a huge (but not rare) design mistake, since it would force using a lower iteration count than would be otherwise possible.