2

Is there any way to generate HD wallet based on username/password combination only?

I understand that I can easily generate and recreate the wallet in a deterministic way based on a mnemonic phrase (eg. with ethereumjs-wallet), but I don't want to make the user remember the mnemonic phrase nor do I want to store anything sensitive on the backend side like private keys (even in an encrypted form).

Each time the user logs in with his username/password I would like to be able to recreate his HD wallet entirely browser-side based just on username/pass.

I could imagine running PBKDF2 on the password with username as salt and using that as an entropy for entropyToMnemonic() from bip39 - could that work?

Is there any other solution?

EDIT: the user will be able to get and backup their mnemonic, but I cannot ask the user for mnemonic to recreate his wallet as it is going to be happening on each login, so it is unacceptable in my use case in terms usability

1
  • IMHO it is a bad idea, the whole entropy is from username/password, pbkdf2 only makes it hard to brute force. If anyone can obtain the algorithm (very easy if it is deployed in the user computers) then it can try with more common username/password and it will easily generate possible addresses.
    – Ismael
    Commented Aug 22, 2018 at 16:32

1 Answer 1

1

I could imagine running PBKDF2 on the password with username as salt and using that as an entropy for entropyToMnemonic() from bip39 - could that work?

Sure, you could do this. The downside here is that if the user forgets the password, there is no possible ways to recover the accounts - after all, how would you reset a password and access the keys derived from the old, now forgotten password?

One way you could fix that is to use a separate base for the key derivation, and encrypt that using the password. Then, when the user logs in, decrypt that base, and derive addresses.

If the user forgets the password, you can either maintain a backup of the key root encrypted with a company key, or ask the user to note it down the first time and reenter it when they reset the password.

Naturally, at this point, you might as well use a BIP39 compliant phrase for the key derivation, and protect that with a password.

I would strongly advise against trying to built your own version of this process when standards such as BIP32/39 already exist, and are well supported and battle tested. You are liable to run into issues such as users losing the password, or getting confused between your custom standard and other BIP39 compliant wallets.

If you value usability over security, you could encrypt the seed words with a backup company key, and use that to decrypt them upon a password reset and encrypt again with a new password. However, this certainly impacts security, and means that you have access to all keys at all time, and I would not use such a service.

I would strongly recommend that you use the existing BIP39 standard, and ensure users make a backup of their phrase, like any other wallet.

7
  • Thanks. No, I don't want to have access to users' keys, that is the whole point. It is definitely about the security over usability and my users are willing to accept the trade off of being unable to reset forgotten password if it means the setup is more secure.
    – dawka
    Commented Aug 21, 2018 at 5:30
  • That said as long as users remember their password they will have the ability to see and backup their private key / seed, so as long as they back that up they will still be able to access their accounts using other ways since they will be in possession of private keys. But users' wallets still have to regenerated after login and I cannot ask them for their seed after each login therefore I need to regenerate their wallets based on username/password solely.
    – dawka
    Commented Aug 21, 2018 at 5:32
  • In that case, you should still use a regular seed based derivation, and protect the root key using a password, similar to Electrum etc. This prevents users from losing coins if your service goes down, follows existing standards, and is better for security than having you maintain a backup. Commented Aug 21, 2018 at 5:33
  • I am sorry, my message above got split - users will not lose their coins if my service goes down because they can backup their private keys after registration (hence they are in possession of their keys as longs as they did that). I cannot use regular seed based derivation as that would require users to enter their seed every time they login / want to perform any action on the platform requiring access to their wallet - it does not make sense in my usecase unfortunately.
    – dawka
    Commented Aug 21, 2018 at 5:42
  • The idea is that you used the regular seed, and store a copy encrypted with the user's password. When the user logs in, you decrypt the seed using the password, and carry on as normal. This way, you maintain explicit compatibility with existing standards, without requiring users to backup individual keys (just the seed words) Commented Aug 21, 2018 at 5:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.