Multi-owner Authentication

Developer Discussions
1

One of our protocol’s data-only (stateless) DB is backed up in a Storj bucket.

We want every approved protocol user to have read access to this single bucket to download. We want to prevent users whose access has been revoked from reusing old pre-signed URLs so we need an automated BUT protocol independent method to generate a user-specific time-limited pre-signed URL (e.g.: via this).

However, I am at a loss. Every time I conceive of a sequence, I realize it depends on the local script which then exposes it to a MITM attack.

The only solution I see is for Storj to provide a custom signature verification mechanism so I can generate this custom pre-signed URLs. But I cannot see such a mechanism in the docs.

I found that Storj proposes the use of Linksharing as another method. However, no code is provided and no docs exist on the bindings specific page to explain how this is done and if it can be coded with user-specific signature mechanism pre-compiled and attack-resistant (to programmatically force the expiration of and create a unique new link for each user.

Can you help? If you have alternate suggestions, I am “all ears”.

Thanks,
Fadi

2

Hi @Daemon-Fadi ,
Welcome back to the Forum!
I’ve forwarded your question internally and someone will return with answers for you.

3 Likes
3

You can generate an access grant with read-only permissions, then derive from it the access grant limited only to this bucket. You then may revoke only this derived access grant then generate a new one for the same bucket, but you would need to add a some change either to the path or to caveats, otherwise the generated access grant would be exactly the same, but since it’s revoked, it will not work anymore. The simplest way to change caveats is to add --not-before=-1m, this would always produce the unique access grant.
With Uplink CLI it would looks like this:
On your machine, using your root access grant

uplink share --not-before=-1m sj://db-backup

It will print the read only access grant limited to this bucket, e.g.:

$ uplink share --access us1-demo --not-before=-1m --not-after=+1m sj://db-backup
Sharing access to satellite 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S@us1.storj.io:7777
=========== ACCESS RESTRICTIONS ==========================================================
Download     : Allowed
Upload       : Disallowed
Lists        : Allowed
Deletes      : Disallowed
NotBefore    : 2024-10-27 03:02:42
NotAfter     : No restriction
MaxObjectTTL : Not set
Paths        : sj://db-backup/ (entire bucket)
=========== SERIALIZED ACCESS WITH THE ABOVE RESTRICTIONS TO SHARE WITH OTHERS ===========
Access       : 1X8k...kU8nq

Now you may configure your code on the server using this access grant as a default access grant

uplink access import --force --use main 1X8k...kU8nq

and you can derive another one from it right there and register it on the GatewayMT to get the Access Key, which you can use to generate a linksharing URL.
In Uplink CLI it would be:

uplink share --url --not-before=-1m --not-after=none sj://db-backup

it will produce a new read only access grant, register it to get s3 credentials and produce the linksharing URL using the Access Key from these s3 credentials, e.g.:

$ uplink share --url --not-before=-1m --not-after=none sj://db-backup
Sharing access to satellite 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S@us1.storj.io:7777
=========== ACCESS RESTRICTIONS ==========================================================
Download     : Allowed
Upload       : Disallowed
Lists        : Allowed
Deletes      : Disallowed
NotBefore    : 2024-10-27 03:04:18
NotAfter     : No restriction
MaxObjectTTL : Not set
Paths        : sj://db-backup/ (entire bucket)
=========== SERIALIZED ACCESS WITH THE ABOVE RESTRICTIONS TO SHARE WITH OTHERS ===========
Access       : 1Ka6C...cH5n
========== GATEWAY CREDENTIALS ===========================================================
Access Key ID: jv45v...qbmq
Secret Key   : jy...stq
Endpoint     : https://gateway.storjshare.io
Public Access: true
=========== BROWSER URL ==================================================================
URL       : https://link.storjshare.io/s/jv45v...qbmq/db-backup

code: uplink/examples/walkthrough/main.go at 265d55b49b07a86e31949946c4ff267b9f396a48 · storj/uplink · GitHub

Even if this access grant on the server would leak, you can always revoke it on your machine, providing this leaked access grant.
To revoke:

uplink access revoke 1Ka6C...cH5n

You may even revoke the access grant which was used to generate this one, then all derived accesses will be revoked too.
code: uplink/access.go at 265d55b49b07a86e31949946c4ff267b9f396a48 · storj/uplink · GitHub

Then you would need to generate a new limited access grant on your machine and configure the server with this new access grant.

However, you may still use the S3 SDK to generate a presigned URLs as before. And you can easily revoke the access to that bucket, which was used to generate these S3 credentials.
You can also generate many accesses and register them to get unique S3 credentials, which you could use to generate a presigned URLs, so you may revoke one of the sets when you want, and this would not affect others.

1 Like