问题
I am trailing the Gun/SEA authentication system for a distributed/serverless application. This app is saving session information to local storage when a Gun user is authenticated. One problem I am having is when the page is refreshed or a new tab is opened I want to keep the user authenticated while the session is valid and I would rather not store the user name and password in local storage due to XSS and physical security reasons. Is there a solution to this problem currently? I think sessionStorage could be nicer but it still has some of the same security issues of storing the user name and password somewhere an attacker may be able to get it, and needing the user to log in when a new tab is opened.
回答1:
grant ! Awesome to hear from you, sorry for the delay in reply (I'm not sure who the person commenting was, as it didn't really help your situation).
This is a great question, and you have somewhat already poked at the limits of security and browser tech - honestly, none of them are very good. Let's review:
- if you add
user.recall({sessionStorage: true})it will attempt auto log you back in. But you are right, there are some security tradeoffs, but I think this one is reasonable. localStorage. I've heard a few people complaining different browsers handle sessionStorage poorly (doesn't preserve in new tab, etc.), so the next option would be to use localStorage. However, I do think this is an actual security concern.- SPA. Single Page App - this will already be useful if you are trying to distributed standalone packaged 'dApps'. But you are right, you still have the refresh problem. In my own experience, (1) worked well enough to make this a good user experience.
- PIN. Another idea our community threw around was using (1 ~ 3) but combining it with a device PIN code. This means you could store it in localStorage with reasonable security assumptions, and on refresh/resume users type in their PIN to decrypt their session.
IndexedDB. Turns out that WebCrypto API does have an option to import keys and will encrypt them in IndexedDB and retrieve them later without it getting passed to user land - at least, that is what I've heard. However, you still have to deal with initially getting the keys, and IndexedDB support varies, and you'd to write a GUN plugin for it.- Browser extension. I like this least of all, since it requires a user to install something, but due to browsers not providing some native functionality equivalent to this that is secure, we have to intervene. The good news is that there is a GUN + MetaMask integration happening, and MetaMask already has 1M+ installs, so there may be a chance your users already have it.
- Browser API. We will be working with the MetaMask team and others to get a native API for this as a standard. My hope is Brave will follow MetaMask's lead, and FireFox will follow Brave, and Chrome last.
In the meanwhile, your original suggestion is probably best - to use (1) sessionStorage. It will be/is forward/backward compatible with MetaMask. Mid-term hopefully you or somebody else in the community will get (5) working. And then long-term (6 & 7) will be the solution.
As for now, check out the MetaMask demo: https://twitter.com/marknadal/status/1062153254283276288
Edit: MetaMask still working on their API for this, in the meanwhile, you can use our http://party.lol extension.
来源：https://stackoverflow.com/questions/53578591/keeping-a-gun-db-user-authenticated-during-a-session