RaiWebWallet
RaiWebWallet copied to clipboard
jaimehgb
Page refresh after login returns you to site root.
After login you go to: https://raiwallet.com/home
However if you refresh the browser you then return to the site root. Ideally a page refresh should respect the current page / routing and refresh that instead.
Testing on Windows 10 in Chrome.
I haven't found a way to do that. The thing is that keys are decrypted at the browser with the user password, so when refreshing the page all data in memory is lost and the wallet needs to be decrypted again. The server doesn't have the password so ...
Ideas? :)
Interesting problem then really -- will have to mull it over. So storing any information for the session, even it's securely encrypted somehow goes against your base design and objectives?
I think it works the same for blockchain.info and I would say this shows secure design. Not a bug.
Right -- it was never reported as a bug to be honest, more of an expected user experience thing. Any decent site you go to operates the same on page refresh, it's standard procedure.
Non-tech users will not necessarily understand the technicalities or perceived security benefits of course, just wonder why they 'get logged out'.
Not that I have a solution, that doesn't involved storing some piece of info in the session. :)
I've a suggestion, for this issue and #32.
How about we don't decrypt keys at login and save session info to prevent from getting logged out. Let login just query the account balance, pending transactions, and things that don't require the seed/secret key. This would mean that we can even use social accounts (gmail, fb..) to login.
But we'll have a separate password which will decrypt the keys just when we need them and immediately forget after the relevant operation. Basically the user will have to enter the password every time to sign the operation.
That can be done. But then yeah, users will need to have 2 passwords.
We can take an hybrid approach. Right now, when a user logs in, after decrypting the wallet a shared key is sent to the server so the server knows the user knew the correct password (the one which decrypts the keys). A session could be started there, tracking all user accounts and balances and once the user wants to send or receive (receive blocks should be signed too) a transaction ask him for the password if he refreshed the page at some point.
The password in this case would be the same for both login and key-decryption, it still won't reach the server (yay!). This way, only users who are logging in with social accounts will need to have 2 different passwords. Normal users can use a single one.
Interesting ...
OK. Correct me if I'm wrong. Now raiwallet authenticates users by checking if they can decrypt the seed. Does this decryption happen on the server side or the client side? If it is on the server side, personally, I don't like that. I like it when the authentication simply checks whether the hash of the password matches with the hash stored in the server side db. And this is the step a user can bypass via OAuth.
About the SEED, send it in the encrypted form. Decrypt on the client side, every time it is required.
But for that you need 2 passwords. The way it works right now is:
- Wallets are stored at the server encrypted.
- User logs in with his identifier, gets the wallet cipher and decrypts it with his password (at the browser).
- When the wallet is decrypted, there's a kind of password which was encrypted too which is sent to the server to notify it about a successful decrytion (this password is generated randomly when creating the wallet, it cant decrypt the wallet, its only purpose is to notify the server about a successful decryption). When that password is sent to the server, a session starts. The user is then allowed to query the rest of methods.
It is encrypted with the rest of the wallet, with the main password. AES256 https://github.com/chriscohoat/rai-wallet/blob/master/src/Wallet.js#L1209