cupcakearmy / cryptgeon

cryptgeon is a secure, open source note / file sharing service inspired by PrivNote written in rust & svelte.
https://cryptgeon.org/
MIT License
797 stars 84 forks source link

Can the password function be added? #69

Closed nakatsusizuru closed 1 year ago

nakatsusizuru commented 1 year ago

Like privnote, the sender can set a password

cupcakearmy commented 1 year ago

This was a thing before, was removed because mostly it's better to use generated passwords than user chosen ones. What would be the use case? (just out of curiousity :) )

nakatsusizuru commented 1 year ago

This was a thing before, was removed because mostly it's better to use generated passwords than user chosen ones. What would be the use case? (just out of curiousity :) )

In some cases, I am worried that Chinese websites or social media software will actively access these links to know the content of the notes, because I have experienced it, so I am worried that if there is a custom password function, I can agree on a password with others in advance, so that I can block access to the notes

cupcakearmy commented 1 year ago

makes perfect sense. Should be added.

kakra commented 1 year ago

We are discussing a similar feature with one of our clients who wants to use Cryptgeon to securely share passwords via link. This is currently not possible because you cannot agree a second factor via phone before sending the link. Without this, sharing the link via mail is only a tiny little bit better than sharing the plain text password, the only benefit is that with the Cryptgeon link the password won't be stored in an email archive. But it could still be intercepted and accessed before the destined recipient clicks on the link. Well, at least you then know the password has been compromised - but it's also too late by then.

So Cryptgeon should offer to secure a link by a generated 6-digit code, or optionally a user-provided password. Since it's a one-time access, a highly secure password isn't needed, we just need a second factor to provide authenticity of the intended receiver.

cupcakearmy commented 1 year ago

A second layer of protection is outside of the scope, as it a non trivial task that requires infrastructure. The server has the goal to be stateless. Also authenticity is quite a complex topic, in theory best handled by async crypto, like signatures.

I'd argue that not having password in your email/slack/etc. dumps is already a huge win. This is why the project basically was started 😁

I think what you are requesting are TOTP codes right? 6 digit pins are only as secure as the rate limit, as outherwise it's brute forced in less than a second. Rate limiting is a super complex and non trivial task though.

nakatsusizuru commented 1 year ago

A second layer of protection is outside of the scope, as it a non trivial task that requires infrastructure. The server has the goal to be stateless. Also authenticity is quite a complex topic, in theory best handled by async crypto, like signatures.

I'd argue that not having password in your email/slack/etc. dumps is already a huge win. This is why the project basically was started 😁

I think what you are requesting are TOTP codes right? 6 digit pins are only as secure as the rate limit, as outherwise it's brute forced in less than a second. Rate limiting is a super complex and non trivial task though.

I think a custom password like privnote is perfect enough, and a custom password can prevent Chinese Internet service providers from trying to decrypt

nakatsusizuru commented 1 year ago

We are discussing a similar feature with one of our clients who wants to use Cryptgeon to securely share passwords via link. This is currently not possible because you cannot agree a second factor via phone before sending the link. Without this, sharing the link via mail is only a tiny little bit better than sharing the plain text password, the only benefit is that with the Cryptgeon link the password won't be stored in an email archive. But it could still be intercepted and accessed before the destined recipient clicks on the link. Well, at least you then know the password has been compromised - but it's also too late by then.

So Cryptgeon should offer to secure a link by a generated 6-digit code, or optionally a user-provided password. Since it's a one-time access, a highly secure password isn't needed, we just need a second factor to provide authenticity of the intended receiver.

I think a custom password like privnote is perfect enough, and a custom password can prevent Chinese Internet service providers from trying to decrypt

kakra commented 1 year ago

I think what you are requesting are TOTP codes right?

No, not TOTP because that requires state. A simple "password generator" next to a password field would be enough which could create simple or complex passwords per choice. The primary use-case here is to put complex password into a Cryptgeon note which would otherwise be cumbersome to share via phone. But a second layer of protection would be needed, so the intended receiver has the link via email, and gets a simple password/code via phone (the "second factor").

Brute force protection isn't really needed as long as the link becomes invalid before the second factor could be brute forced. Optional rate limiting could be deployed at the nginx level.

The note should self-destroy after entering the PIN/password, not before. It could be stored inside the note itself as meta-data, so it would be encrypted, too. The web interface would only present and destroy the note if the PIN/password matches (through a second web request). This would also successfully prevent link previewers from destroying the note, similar to how this is already done. The second factor unlock could be put side-by-side with that button.

luxus commented 1 year ago

its this still planned i would look forward for protected by password?

cupcakearmy commented 1 year ago

Yes, this is planned, probably going to add that back in the coming weeks :)