Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secrets from date #1265

Open
MakerTim opened this issue Mar 13, 2024 · 5 comments
Open

Secrets from date #1265

MakerTim opened this issue Mar 13, 2024 · 5 comments

Comments

@MakerTim
Copy link

The problem

When sharing secrets we have the problem that certain passwords are only accessible from a specific date.
The problem is now that we are required to only make them available from a specific time.
But in the ideal world, would the link be already present and shared; if the secret-holder gets sick or anything happens in the process, the secret sharing process is lost.

The solution

Next to the till date we get a from date for secrets.
So long the date is not met, the secret is not accessible.

Alternatives

I am still required till the last second to share them and when I'm sick or something there will be an insecure step in the sharing of secrets

Additional context

We share keys for an external organization. And it tries to unzip it based on the url (that will be read as plain text)... whole process; it works.
Now I will make the secret one minute before the files are released, fill them in a CMS at the last second and the file is released.
but i would like to do this all a few weeks before and trust the PrivateBin to do its work.

Support

I am very interested to work on this feature and would assign developer capacity. But would this be a feature that would be accepted with the scope of PrivateBin or is this very out of scope?

@rugk
Copy link
Member

rugk commented Mar 13, 2024

Thanks for filling out the issue template in detail, but I still don't get your process? Could you just enumerate what are you doing (best as 1./2./3. etc.) and what you want PrivateBin to do in each step? (Or how you are currently doing it vs how you want it to do.)

@MakerTim
Copy link
Author

Allright, tldr; all I need is delayed/timed/scheduled publishing of secrets.
So I can upload a secret at day x, set the publishing date, have the url ready for sharing purposes. And trust that PrivateBin will keep my secret private until set a set date.

We share secrets in a small window, to "unlock" zipped files
the zip is uploaded weeks in advance, and a zero-trust system should unlock it at a specific date.
for now, we need the person that is holding the unlock-key for the zip to upload it to a PrivateBin at the last second when the files are ready for publishing. And that is a stressful and person-depended job.
the unlocking process can be from a external URL (next to last-minute uploading the unlock-key), that it will read the unlock-key from PrivateBin. But currently all secrets uploaded are accessible directly. We need a system where its only public from a specific set date.
We host our PrivateBin external, and this is the best "zero-trust" way we can think of to publish secrets on a safe way.
So no one, even internals, can know the unlock key before the files should be published and the zip and unlock keys are stored on separate places.

I hope the context is no a bit more defined

@elrido
Copy link
Contributor

elrido commented Mar 15, 2024

The key phrase, I think, is "And that is a stressful and person-depended job." - when recognizing such a condition, investigating a way to automate it is the way to go. Is it an option to use one of the third-party clients in a script, triggered by an at-job or systemd timer at the precise time, to create the paste, store the link and send the notification?

While it is certainly possible to modify this service to have a second timestamp attribute and not serve the paste before that is reached, you still have to trust the server code not to get bypassed somehow. If the paste isn't created till that time, it is more secure. The paste creation could be done from another, more secure environment.

@rugk
Copy link
Member

rugk commented Mar 15, 2024

An alternative idea to automate this may be having a list of secrets saved in pads (maybe even on a "public" site) already, and only providing the access links - or better maybe, passwords – at the start time ("from time"), where you want the secret to be accessed.
Such a password could be automatically be provided via mail or any messenger/push system.

@MakerTim
Copy link
Author

The nice thing here, and that is very personal, is that our hosting has a public facing PrivateBin.
We can access the files, but not the PrivateBin.
They cannot access the files (and don't know what Bin is for the file) but in theory have the password.
It's very opinionated, and even if we have to find a 3th PrivateBin place / hosted variant, than we are still in the clear.

The whole goal is that the file and password are not stored at one place.
So even if a colleague (or me for that matter) are not in the clear, there is physically and theoretically no way to expose the files in advance.

I get that this is a whole new scope in security/aspect for the application; because keeping it a secret until a moment means a new attack vector / security layer to support this propperly (if even possible)
but my advantage is that "only allowed to open once" and "in the future" are must haves

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants