This is for both users and developers. Vote which one you think is best (while being feasible)!
(Do note I’m not part of Blockstack PBC, this is a community-run poll and there is no promise any of these alternatives will be implemented – I’m just figuring out what the community thinks about these and trying to start a discussion).
- Current Method (persistent keypair & address, gaia token)
- Session Token (persistent folder, gaia session token)
- Injected API (persistent folder, browser handles everything)
- Other (comment below!)
0 voters
Explanation
As I have been reviewing how app authentication works, I was thinking of different ways to go about it with varying security benefits (and amounts of work to implement). It might be that the one that is already implemented is the best way, and if so, great! But perhaps there’s a better way. Feel free to explain your position in the comments, or even argue for multiple options for apps to use.
Current Method (persistent keypair & address, gaia token)
Currently the App is given a public address and a private key to use, generated by and from the user’s own address/private key. They are also given a Gaia Token to use to store data in the hub, and if it expires the app is no longer able to write.
Security concerns: losing your phone/device while the app is still logged in, or having the app leak its key in some form (such as using it in a hidden backend API or XSS) would allow the “attacker” to misuse the encrypted app data as well as overwrite it – even if the browser had a session and was able to be logged out of remotely. In addition, if the association token is leaked, the attacker would be able to overwrite things (for a limited time, ~4 months) in private Gaia hubs.
Session Token (persistent folder, gaia session token)
Apps would be given a folder within the user’s Gaia bucket, such as hub.blockstack.org/{user address}/{app folder}, and would be given a token to have write access to that bucket. The address would be persistent but would not have a corresponding private key, and the token could be rejected/expired at any time if the session was removed.
Security concerns: data storage provider can track what apps you are using and what data really belongs to you. Apps can also use the session token outside of when the user is present, such as through a backend API or through other apps.
Implementation Difficulty: fairly easy, as all one would need is a new Gaia authentication method/token for both the Hub and the Browser and some changes to blockstack.js to handle it properly.
Injected API (persistent folder, browser handles everything)
Like the above, but instead of a session token being given to the app, the app uses the injected API to write into the user’s gaia hub. Folders no longer need to be permissioned with tokens and if the browser is disconnected the app can do nothing on the user’s behalf, therefore being more secure. The “browser token” is only a small token given to the app fro the browser so it would be able to do things securely with less of a chance to be spoofed.
Security concerns: data storage provider can track what apps you are using and what data really belongs to you.
Usage concerns: can no longer have write-access from backend services.
Implementation difficulty: very difficult, as an official extension would have to be made similar to MetaMask, blockstack.js would have to be rewritten to be able to be injected into websites, and apps would have to be rewritten to use the injected api instead of the included blockstack.js they have been using. Gaia could be left alone, however.