Recently I’ve thinking of the scenario where I’m using several blockstack dapps daily, relying on browser.blockstack.org. I post from my phone on Afari, write docs on graphite on my laptop, etc.
All this requires me to be logged in to blockstack browser on my device. It is not practical to login and logout everyday using the 12 word key.
What would then happen if my phone is stolen? If physical security is compromised, i don’t think there is a way for me to remotely ‘revoke’ access to my blockstack account. Or is there?
if you are logged in in multiple places, and your phone gets stolen, but not another device you are logged into:
You should be able to reset your password from the other device.
Depending on where your gaia storage is hosted, you could takedown the FQDN to the readpath of the gaia hub, and remove your gaia hub from enabling read/write access.
If you hosted your own gaia hub on aws for example, then you should have a separate login to aws where you host that hub, enabling you to do this. You would probably want to change the logins for that as well depending on what other data was accessed or compromised.
That is not the most ideal solution, but it would allow you to truly own your data by disconnecting it from the blockstack eosystem until your blockstack id auth was reset.
The request for a feature to remotely revoke access has been duly noted. We keep a long list of feature requests and always have to prioritize. I can’t say this will be implemented right away, but I can say is on the list of things to consider now.
You are also welcome to make a pull req for this. We would love more open source contributers to the project.
Let us know if you have any more specific ideas/feedback regarding this.
Thanks for the thorough reply. I live in a city where phone snatching is far too common (happened to me twice in 3 years) and with tools like YourNote appearing I’m considering relying on gaia to safely host notes and secrets, which means the phone where I’m logged in could be a security hole.
I thought the password only applied to the logged in instance. Ie. If i change the password on my phone’s blockstack browser, this does not affect the password i setup on my laptop’s blockstack browser…
Thats good to know for those self hosting. (I tried the heroku gaia instance but found the 5usd/fee required to be too high for me). Is there a guide for gaia on AWS?
We have an AWS s3 driver in the gaia repo. Setting up an s3 bucket has instructions on amazon so utilizing the driver should be straightforward but we should add more detailed instructions overall. Digital Ocean Spaces is more user friendly if you are not already familiar with the aws environment. We are working to make hosting your own gaia hubs more user friendly, and adding instructions for popular options.
From an app developer standpoint, I’ve thought a lot about this. Each app can certainly implement a session timeout feature, but as @mario points out, that doesn’t really matter since a thief could simply log back in as long as the Blockstack Browser sessions is stored.
Perhaps a solution is to optionally enable session storage for the browser rather than local storage? This creates a significant UX problem for users that log into apps frequently, but it mitigates this security risk. For those that use password management systems, restoring the browser may not actually be all that tedious for each session, but the browser will absolutely need to restore all IDs automatically (not just the first ID). I know there’s an issue open for that already.
What are everyone’s thoughts on some config option that would allow for using sessions storage instead of local storage?
This is a terrible state of affairs. Besides a lost phone, this makes me realize that if there is any kind of flaw on the application, there is no way to reset my password ???
For example, if Afari has XSS, the attacker has my private key forever? The only thing I can do is wipe my accounts and start over ?
How is blockstack not a toy ? On one hand we tell people that centralization is dangerous, but the blockstack authentication seems really reckless. When will this be fixed ? Major red flag
@jehunter5811.id the “restoring of IDs” (that is, the derived ones within the same login) is trivial and way too easy to be considered as a blocker for this issue. One could just store the offsets to regenerate within the profile.json for when you restore an account, though there are easier/simpler/safer solutions than this as well. I don’t believe multiple-root-IDs (that use different recovery phrases) will ever be implemented due to security risks, etc.
@Jenayers93 Blockstack works a little differently in that you never “reset your password.” Your recovery key is tied to your account – I.E. if you even changed one word within the phrase you would generate an entirely different address (if it was valid at all), as the address is derived from the phrase.
The recovery (private) key is never stored in plaintext, and the only way it could be gathered is if they get it in the (rather) small amount of time where you either recover your account or view it (by re-entering your password to temporarily show it in the browser app/settings). Otherwise, it can not be easily cracked via the encryption as the official browser uses three layers (or if you are using my extension, just AES-256), which leaves only the dictionary attack left – though that should take much too long due to the size of the dictionary used.
Thus the only real concern – which is discussed here – should be having an attacker able to access a live session, such as through a stolen phone or if one used a public computer and forgot to log out. Currently there is no way to “end” a session remotely – so they could technically do anything you can do, except for get your recovery key or do anything that requires your password or key phrase.
This is definitely an issue that should be looked into as ending sessions is rather important – perhaps this could be done by keeping a sessions.json active within the gaiahub and, if the official browser(s) detect that they are no longer allowed then they log out by themselves. This is obviously able to be bypassed by more experienced hackers but it’s a start.
Another way would be to use “democratized-but-still-centralized nodes” to handle user authentication and session management. This would be like using the core-node to sign people in and handle the important things… but it could be run by the user themselves (similar to a gaia hub) if they wanted that security. This may be the safest but least decentralized way to do it, but it is something to look into.
@MichaelFedora thank you for that condescending reply and explaining to me what I already know.
With the XSS I am obviously referring to the private key for the application which I am currently authenticated to. If there is an XSS on browser.blockstack it would apply to the master account key.
Blockstack authentication breaks the web security model
When you use terms such as “reset your password” I assume you don’t know much about the Blockstack ecosystem and thus tried to help you get into the loop into what we’re talking about. Never meant to be condescending, but I’m glad you already understand though!
After looking into it again, if they are able to pull off XSS onto the browser.blockstack.org, the localhost version if you installed it, an extension, or anything else, then yes, they would be able to access your private key as that is stored locally (and has to in order to generate app private keys, sign your profile.json, and many other things). The recovery phrase is still encrypted but honestly that doesn’t matter if you already have the private key out in the storage – it’s a little funny noticing that now.
However I don’t believe the browser is affected by either reflected or persistent XSS vulnerabilities – definitely not the latter, as there is no DB that can be effected by a third party to affect everyone else, and while the former may be more possible as they would have the auth?=<token> to try and manipulate, I would argue it would have to be demonstrated, honestly. Regardless, it still would be prudent to put in security measures to make sure that doesn’t happen. Thanks for raising this concern!
As for breaking the web security model, it’s an entirely different way to do authentication in a decentralized manner, so it would be kind of obvious that it would break things. Do you have any solutions that would fix this while keeping the decentralized/democratized nature of Blockstack?
(Though tbh this is off topic from the Original Post – perhaps you can make a new thread about it)
You’re wrong about obviously breaking things because it’s decentralized that’s not an excuse for poor design. Like raised in this thread, normal features like logout, being able to sign out other sessions, change your password on an application, etc are more or less not implemented with blockstack
For anyone coming to blockstack for privacy this is a few steps backwards
I disagree completely. Authentication in Blockstack is decentralized in such a way that every client uses their own key and is responsible for it, therefore obviously breaking things in the standard model, as having sessions and “changing passwords” only works in a centralized system. Otherwise you’re talking about a partially centralized system which I reference above:
With the way Blockstack is implemented now, it is impossible to have the features you are demanding for. The “Internet 3.0” that we are trying to build here will inevitably go through growing pains like this, and maybe the standards will have to change and we will have to build solutions to the root problems (like what is supposed to be discussed here) and not try to have it align with what previously was held as the model.
Privacy as well is not one of Blockstacks goals (iirc – if I’m wrong someone correct me), but it is rather just decentralization. With that said, privacy is a lot easier to maintain/create within a decentralized environment, but it is never guaranteed on the internet in general.
Again, please take this to another thread (as you were the one to initialize this conversation) and/or if you could come up with some solutions that would be fantastic and constructive compared to the dialogue we have been having.
I will parse your feedback as feature requests and see what works with the Blockstack auth model. We always have many feature requests and are always looking at what to implement. You can always file issues on our Blockstack github as well, that way our core engineers will immediately be notified and we can prioritise and provide feedback there as well.
We also have a bug bounty platform on Hackerone, so if you find any vulnerabilities in our model you can post them there as well. We encourage that type of feedback.
The features you mention like resetting passwords, or doing so remotely for different devices are potentially something to look into, but the Blockstack model is not necessarily a model that lends itself to a 1:1 mapping with all of the features associated with navigating around vulnerabilities in the current centralised web model. Regardless, we are trying to make things easier for users.
As far as the specifics about how Blockstack authentication is reckless in your wording, in what specific ways were you talking about? I am not sure if you were referring to unimplemented features you referred to about making it easier for users to manage their logins, or flaws in the model itself. Let us know, and we can address them and give formalized feedback.
I personally would not go as far to say that all the people who contribute to Blockstack have only done so much as a create a toy, but we would say it is a work in progress, and we are always looking for feedback on how to make Blockstack user friendly and support user owned identities and storage in a safe decentralised, but reasonably usable manner.
Thank you again for the feedback, and encouraging technical debate in the forum!
If a remote service can reset your password without your consent, then they can take your access away from your data. At Blockstack we believe this is an unacceptable design choice.
There are no application passwords, since only the owner of the application private key can decrypt or sign the user’s application data. Recall that application data is not stored with the application in Blockstack apps; it’s stored on the user’s preferred Gaia hub (the application is simply a view of that data). We have already merged code into Gaia to allow the user to revoke app keys and revoke outstanding auth session tokens, and are in the process of rolling this out.
Your account on an application is controlled with a private key that is specific to the application. A buggy or malicious application may leak the private key or expose it, but this will not compromise your master private key nor will it compromise other apps’ private keys or other apps’ data (Gaia buckets your data on a per-key basis). What is still needed in the design of the auth protocol is a way to rotate application private keys in such an event, but this isn’t too hard to do – we’d simply (1) alter the app private key derivation path for that application, (2) list the new derivation path in the user’s profile so the browser will know which key to generate, and (3) if necessary, migrate any encrypted or signed data to the new key. This, combined with the ability to revoke authentication tokens on a Gaia hub (and generate ones that are limited in scope), should address your remaining concerns.
Maybe Blockstack can better communicate the feature and anti-feature that blockstack brings to educate blockstack users and society in general how to deal with private keys.
@Jenayers93 Would you be more comfortable using blockstack if a thief of your phone would need to proof that the thief is actually you e.g. by providing your fingerprint or having a hardware fob before using your blockstack accounts/keys? There is an open issue for this: https://github.com/blockstack/blockstack-browser/issues/1709
Maybe Blockstack can better communicate the feature and anti-feature that blockstack brings to educate blockstack users and society in general how to deal with private keys.
I could also see us adding this information to blockstack.org directly in a new “Learn how Blockstack protects your identity and data” section or dedicated page for end users.
I’d love to communicate a lot of this better for end users there, perhaps as something to which apps can send new users for a quick introduction before they authenticate for the first time. cc @jeffd