So, who does own my private key?
Most wallet setups, once you’ve written down your private key (12 or 24 word phrase), that’s IT. That’s why there’s so much rigor around writing it down, and putting it somewhere safe.
So why, after all the “save your key”, “write it down”, and so on, can I recover my private key via the website? Seems to imply that the private key is being stored somewhere …
I’ll be reluctant to use the service unless I’m sure I’m the only one storing my keys.
You own your private key. Nash has no access to it. What we store is an encrypted file that we cannot read, and which is decrypted entirely client-side. The words are decrypted in your browser using your password (which we also don’t have access to). This is why you have to make sure you store them safely – if you forget your password, you will need your words to access your funds.
Then why store anything at all?
If my account is compromised, then so are my keys …
if my keys are compromised so are my keys… is basically what u said … they need to figure out if ur the owner of ur wallet and grant u access to their services … thats why they store encrypted data…
if ure that worried link ur bank account and redeem ur USD-C to ur bank account and only keep a small sum on the Nash wallet
" if you forget your password, you will need your words to access your funds".
thanks
Dude, what exactly do you want to hear? 
You’ve been told:
If that is not satisfying for you then just don’t bother. Would you rather have a scenario where it is impossible to recover your account?
For anyone with a basic understanding of IT, Nash is as safe and non-custodial as it gets. Nash doesn’t hold your keys.
It’s clear that the files (and words) are encrypted with your own password. So Nash do store these files, but can’t do anything without your password (to decrypt it).
That’s why an API call has to been done to retrieve your encrypted keys (or words)
But how is it possible that you don’t have to fill in your password for signing the transaction from your Personal account to Staking? And why there is a password send to the server (hashed) as it’s decrypted client-side. That is unclear to me.
I just want to make sure that Nash is safe.
Because the private key is encrypted and stored with my login credentials, that password has becomes the weak point in the chain. Obviously the ideal is to use something like a ledger, or even better utilise the extension so that keys don’t need to be stored (encrypted or otherwise).
I’m not sure what the solution is, but the current one requires trust in Nash.
Perhaps the key is decrypted for the session and kept in memory?
Don’t think so… that can easily be compromised.
the google addon is tied to machines, i mean. there will never be 100% safety. Eventually, the 12 words will also be easily solvable. but so far it is safe and that is the mvp version. they often said that there is a next generation account management system and other f2a options
So why, after all the “save your key”, “write it down”, and so on, can I recover my private key via the website? Seems to imply that the private key is being stored somewhere …
The private key is not being stored anywhere in its raw, unencrypted form. However, we do store an encrypted form of your private key, that is only decryptable using a private key derived from your account password. We never store the key derived from your password. (We also rotate what encrypted private key is stored on our servers if you ever change your password.)Every time you log in, decryption is done behind the scenes to make your private key accessible to the web app. This also explains why we request your password before operations requiring your private key if you signed in to the app via session token, as your private key is inaccessible without the key derived from your password.
As others have said, we keep the decrypted key in memory for a short period of time (currently 10 minutes; will be configurable in the future, or can be disabled entirely so you have to enter your password for every operation.). We don’t ever persist this to cookies, session or local storage, etc. If someone steals your computer while you have a session active and the thief is into crypto then you’re in trouble, but otherwise you’re fine.
EDIT: Also worth mentioning that this only happens when your “trading session” (where the decrypted key is in memory) is active. If you refresh the page (causing the trading session to be discarded, and causing you to reauthenticate with your session token) and try to create a stake, you will be prompted to enter your credentials.
In general session token authentication can be thought of as a read-only state. Your signin credentials will be needed to access any writes.
This is part of our design to make the encrypted secret key a little bit harder to access. It’s a little hard to explain succinctly, but basically we have yet another encryption key that is generated on a per-session basis by the server that is gated behind an endpoint requiring your signin credentials. And we mix that key into encrypting anything we store on the client side, as an additional security measure.
This isn’t quite right, if you’ve truly lost your password, the seed words will be the only way for you to recover your funds. There’s nothing we can do because we don’t have enough information to access your funds.
(Sorry for the disorganized bevy of reply / quote methods – still getting familiar with the forum software 
)
It’s worth noting that any wallet on any platform that’s created using BIP39 should always be recoverable using the mnemonic, regardless of how your private key is treated.
Worth mentioning that this is true. It’s basically computationally impossible to crack the 12 word mnemonic (and if it were it’d imply fundamental encryption schemes are no longer secure and there would be far more lucrative targets to pilfer than us 
). But if your password is easily crackable, or if you use the “yellow sticky note on monitor” brand of security, and don’t have 2FA, then your account can easily be drained of funds.
I got Fabio and Ethan saying they are close to developing a way of replacing ur private key in order to interact with public chains.
sure a signature is required but not a "private key " as we are familiar with today.
Thanks @timothy for the detailed explanation, nice to see all kinds of measurement are taken to provide best in class security.
Wrong! You are only required to #TrustYourself and use a good password/2FC. The only point of failure is you, if you are careless. This is a good thing because it means hackers cannot target Nash exchange and steal en masse. Hackers can only target individuals, one at a time.
That’s why non-custodial is just the way to go.
If you ever lost your funds, it would be due to your own carelessness not Nash’s.
