I would rather prefer to have no password but multiple devices connected to my account. Then when i want to add another device to the account, a message would pop up on all devices to vote for the add. After n-of-m votes (can be configured in the account settings) the device gets added to the account.
recovery devices, they can vote, but without being associated with the account (kind of a lost key function/giving a key to a neighbour in case i lose my own key).
n-of-m removal of devices, so i can remove a lost device, but without that the one who finds it can remove my devices. (remove as not just removing device keys, but disallowing it to do anything with the data at the network level in case that the access key is saved on the device. Removing the key on the network wouldn’t do anything)
Hi @urrtag, what is a device here? An IoT device or something like a mobile phone?
Because if it’s an IoT device, and we assume there is single app running in it, then it’s just like any other app, we just need to create the communication channel for the first-time authorisation (I see it more like a provisioning thing in this scenario), as you wouldn’t want the authenticator installed and running in the device itself.
I don’t understand how this would work for a mobile device, or IoT devices with multiple apps in it, would you trust any app running in that device and share the device’s key to all of the apps to act on behalf of the device on the network?
EDIT: I’m thinking now that I’m misunderstanding your proposal, do you actually mean that you provision your device/s with a sign key, and add/associate that sign key to your account, then whenever an app wants to authorise the device receives a notification from the network that it can respond to with a signed vote?
do you actually mean that you provision your device/s with a sign key, and add/associate that sign key to your account
then whenever an app wants to authorise the device receives a notification from the network that it can respond to with a signed vote?
Right now you have to login into your safenet account with a pin + secret + password combination. I was thinking about an addition to this, so you don’t need a password anymore. You create a new account on the first device, then connect additional devices to that account (ring is doing something similar)
Not as secure IMO
Yeah, ok. I had the opposite impression (as you could remove (when eg stolen/lost) and add devices in an n-of-m multisig fashion without the need to depend on a possibly insecure password).
I have no idea who’s owning the data objects on the network, is it the user, the app or just a “random” key (to get some anonymity by signing the data with changing keys)?
I don’t think it’s a dumb idea at all, and I think I understand now, because Ring seems to let you add a device but it’s actually adding/authorising an application instance running on another device, if I get it right, and I think it could be implemented on safe network. Also, note Ring requires you to type the PIN and also the password on the other device.
1- You could create your account, as you do it today, which you would need to do it with the secret and password.
2- Then when you want to add a “device”, which is basically pre-authorise an app, the Authenticator could generate all the sign/encryption keys as it does it today for an app when it’s authorised (there are some details here to consider though, related to generating random id/name for the app I believe).
3- In the normal scenario, the Authenticator sends back all the generated keys to the app using the system URI mechanism, encoding them into what we call the authorisation URI. But it could encrypt the auth URI with a newly generated encryption key which will be shared with the other device/app (this encryption key would be analogous to the PIN in the Ring flow, perhaps using a QR code to have the other device to scan it as an encryption key wouldn’t be so easy to type as a PIN).
4- The encrypted auth URI can be now stored in a MutabeData which address is the hash of the group ID you’ve chosen (the Authenticator could give you administration tools to manage your groups of devices)
5- At this point, you scan the QR code with the other app to get the encryption key and group ID, the app can now go and fetch the MutableData, decrypt and decode the auth URI, and finally connect to the network. It can also remove the data published in the group ID’s MutableData so it’s a bit more secure, you can have the Authenticator to also remove it after a period of time as an additional security measure.
You can also, just share the auth URI with the other device with a QR code instead of storing it on the network, and that would be an even (much) simpler flow (assuming it all fits in the QR code capacity).
I think this is exactly what we need for IoT devices, you acquire an IoT device, you then provision it with this flow from the Authenticator, which can be running on your PC, tablet, or mobile phone, after that the IoT device can connect directly to the network without the need of the Authenticator, and you can revoke its access and/or permissions any time you want, from anywhere, using your account with the Authenticator.
Fido U2F would be ideal… That lets all owners of the newest Yubikeys, Ledger Nano S and Blue, and new Trezors have hardware wallet access. It is already a standard as well, with reference implementations. Shouldn’t be too hard to add down the line.
cool, would this work if i want to have one app get authorized on multiple “devices”, say i have a chat app and want to use that on my phone and my pc? Would it authorize separately (each app getting a separated “identity”) and then manage the same data? Would this imply that if i remove a “device” each data entry must be changed (removing an owner)? I think removal of lost “devices” is a must-have feature, so if someone else finds that device he can’t do anything with it.
/// Contains a set of owners which are allowed to mutate permissions.
/// Currently limited to one owner to disallow multisig.
This is what is intended according to the comment in code and by the usage of a btreeset. But I have already expressed my doubts about this in the past, as no signatures are stored. For a single owner it works because the client manager can check the signature of the message that transfers ownership, but for several owners, possibly managed by different client managers I have not the faintest idea on how this can be implemented reliably.
As its name implies this permission allows a user to modify the set of permissions of a mutable data. This concept is different from ownership, though an owner has implicitly all permissions.
For example the owner can grant it to other users in order to delegate some powers to other people. Or on contrary, he can remove it from every body, including himself, as a proof that the Mutable Data won’t be changed in the future. Of course, this must be done in addition to:
removing all insert/delete/update permissions
transferring ownership to NO_OWNER_PUB_KEY
owners field is checked in verify_mdata_owner function of vault crate. This function is called from handle_change_mdata_owner function and checks that one of the owner is the sender of the message. As I said above, this is OK for only one owner because the signature of the sender of the message has been checked by the routing protocol, but I don’t see how this can been extended to several owners.
Edit: This would also work for a 1-of-N multisignature, but this is a very restricted use case.
I agree @bochaco its all about provisioning this is key.
And the mindset of the user. Put it in their hands. I’m making an app where it has to be possible to start a new account on a mobile device, and then LATER after a password login on a new desktop computer, this success block and notify the mobile:
if the mobile is not lost the login can be approved or blocked inside the timeout
the account can be locked down to nearly disable these auto-logins completely (no password resets!) a successful brute-force would have to wait 2 weeks though.
if the mobile is lost, the “Luser” only has to wait 5 minutes for the default expiry on their new machine.
This is done to increase user retention in the case of hardware failure.