Store optional password on Server

[xkus]

Hello,

when creating a paste a optional password could be set.
There is a recommodation that this should be a secure password.

"As long as you do not set a password, everyone who gets the link can decrypt the contents of a PrivateBin document! The only way to prevent this is to set a long, secure password when creating a new document. You can find many hints on how to create secure password online, such as the method outlined in this xkcd comic (explanation)."

However people don't like secure passwords.
If I use a weak optional password, an attacker could do an offline attack on the encrypted past, if he knows the link to the paste.
Would it be possible to store the optional password as a hash on the server?
So it would be possible to implement a brute-force protection before delivering the encrypted paste.
I think with quantum computers it could be easier to brute force the optional passwort.
Some banks already just use 4 digits as a password and an other 2FA.
What do you think about that?

Best regards
xkus

[elrido]

See the various schemes and discussions in #245 - I had taken a stab at such a scheme in #447 but in the end abandoned it as during review too many doubts and weaknesses turned up.

Reviewing it, it boils down to the need for a different protocol: ATM a client can create a paste by just sending it and they get a paste ID back from the server to access it. For a challenge-response mechanism, the client and server need a shared secret. They could for example perform a Diffie-Hellman key exchange, but that requires extra requests up front and a way for the server to persist this shared key between the exchange and the paste creation (say, using a session).

[rugk]

What you say is true, but the point is the OP just not #245 aka a brute force protection but not requesting a password at all. I'll add another answer.

[rugk]

No. Because it's not secure.

The solution you probably search for is: You can just not add a password. That's secure and only requires the link to access a paste. Now this is secure, no password is needed. The security just depends on the link being shared, as your quoted text explains. No password needs to be "stored" on the server.

A compromise for long links that weakens security is the URL shortener feature some instances use. Anyway, as said, this is a convenience feature and a severity tradeoff we do lot recommend.

BTW, quantum security is completely off-topic.
Similarly, Privatebin cannot be compared to other authentication mechanisms like a PIN because banks do not usually encrypt any data client side. Authentication does not equal encryption and is something totally different.

And encryption needs key material and thus entropy to get a key from (in a secure way). Ideas like @elrido pointed out are way more complex (for areal key storage, not only validation) to built a scheme and even if it would be done, one would again trust the server again which this project explicitly aims to not do. So no, this is more possible in a secure way.