Create account

replied 2081d
I expressed my concerns with this months ago to @jason when I first started on the app but was told it's standard practice. I'm with you. Session tokens, no plaintext.
replied 2081d
Well, at least we know what is going on. So, your memo $BCH is as secure as your browser. Lose the browser, lose the funds. The more browsers, the bigger the security risk. Right?
replied 2080d
For now yes. We plan to use multiple keys that can recover ID from compromise. The funds would still be lost though.

https://github.com/memocash/mips/blob/master/mip-0003/mip-0003.md
replied 2080d
Generate BIP39 mnemonic, use that as seed to derive m/44'/145'/x' where x' is the service. Forget the root master and use the Memo pass to encrypt the XPRV of this account.
replied 2080d
Love MIP 4 and 5. Keep up the good work!
replied 2080d
If the parent key was never used for memo, and the memo.cash website itself generated child keys, then at configurable threshold sent to parent keys, you could minimize risk.
replied 2080d
Malware can search for it because the data has the same rights as you. Instead of stealing, it'll just post spam from your account. At least that's how I'd exploit it.
anarchovegan
replied 2080d
Simon Van Gelder
replied 2080d
AFAIK only the PW is local, and signing is done via conjunction of the server key and PW. I think changing your PW would shut-off compromised browsers.
Simon Van Gelder
replied 2080d
But if the attacker has the wherewithal to export the private key from within the account, you're out-of-luck for that address.
replied 2080d
BIP39 mnemonic should be provided to the user and forgotten. The Memo password should encrypt the XPRV for this specific account and should be unlocked on each session.
Simon Van Gelder
replied 2080d
Agreed, but I think Momo made that choice for UX, not so much for security.