You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2020. It is now read-only.
Look for "account_key" then change one or two characters. - Don't change "data" and "{}" text
Reload the page
Tested OS
Mac
Browser
Chrome
FF
Safari
Suggested fix
Having the Private/Account key stored on the browser local storage is not advisable, due to:
XSS vulnerability
When someone uses the site and leaves the wallet logged in, someone would just quickly get the key in just a few seconds without leaving a trace.
Which is why on some sites profile page, "password" is hidden. Though this a rare case, but prevention is always better than cure.
Personal solution would be is to generate a long random string and store it to the database along with an expiry date. Then match the current string stored on the local storage vs the one on the Database and if it did then it's considered the user as logged in.
This way you won't be exposing the user's Private/Account key. And in case of any XSS injections, you won't be needing to ask all the users to force reset their Private/Account key - not sure if reseting is possible.
Bug Report
By changing the account key stored on the browser local storage, it seems that it creates a new wallet or logged in on an existing one.
This screenshot above is a newly created wallet by just changing few characters of the account key.
You can reproduce this by:
Tested OS
Mac
Browser
Chrome
FF
Safari
Suggested fix
Having the Private/Account key stored on the browser local storage is not advisable, due to:
Which is why on some sites profile page, "password" is hidden. Though this a rare case, but prevention is always better than cure.
Personal solution would be is to generate a long random string and store it to the database along with an expiry date. Then match the current string stored on the local storage vs the one on the Database and if it did then it's considered the user as logged in.
This way you won't be exposing the user's Private/Account key. And in case of any XSS injections, you won't be needing to ask all the users to force reset their Private/Account key - not sure if reseting is possible.
Reward Information
Voluntary donation: 0x6562eb37a210a0949fd502f2a746284a38f4e9cc
Email: [email protected]
The text was updated successfully, but these errors were encountered: