Can I use SHA256 from BIP39 passphrase for auth credentials?

I am working on an E2E encrypted app. I am using OpenPGP.js and storing public and private keys on the server. The private key is encrypted with a BIP39 passphrase which is stored in browser LocalStorage so it's never sent to a server. But I also need some credentials for users to login.

My idea is to make SHA256 from BIP39 passphrase and split it to two strings. First can be used for "username" and the second for server password.

Is this approach safe? As far I know it should be. BIP39 passphrase has entropy big enough. I can't use salt because that BIP39 passphrase should be the only secret to store.

Is this approach valid? Thank you.

Can I use SHA256 from BIP39 passphrase for auth credentials?

My idea is to make SHA256 from BIP39 passphrase and split it to two strings.

That's seems to be two serious errors from a security design standpoint.

• That's using a fast hash function like SHA-256 to process something aimed at being memorized. Rather, one must use a slow password hash for key streching. These are known as Password-Based Key Derivation function. If at all possible, it must be memory-hard. Recommendable choices include Argon2 or scrypt. While BIP-39's choice of PBKDF2-HMAC-SHA512 with 512 rounds is poor (because HMAC is not memory hard and suitable for massive speedup with ASICs, FPGAs, or GPUs), SHA-256 is about 1000 times faster, thus easier to attack for a password cracker.
• That's splitting the data/entropy of a secret into two independent shorter secrets, that can be separately attacked. Analogy: replacing a 6-digit code to enter a building into two 3-digit codes, one for each of two successive doors. When something secret and memorable must be put to multiple use, the whole secret must enter a Password-Based Key Derivation Function, together with some constant tied to the intended usage, and if at all possible salt.

Note: there may be other mistakes in the design. And perhaps the above two apparent issues really are mitigated by something. We can't tell, since security goals, assumptions, and detailed design are not stated.

To answer your actual question, yes your idea sounds secure, but it's not how it's usually done.

If you have a single "master" secret and need to split it into two or more secrets such that knowledge of any of them confers no information about the master, then what you want is HKDF, specified in RFC 5869, which uses HMAC to generate any number of independent secrets from a single secret.

There are plenty of alternatives to HKDF for this purpose, too. If you aren't married to SHA-256, you could use BLAKE2 which supports "personalized hashes" which allow you to mix in a personalization value. Unique personalization values result in unique hashes, even for the same input.