Is it safe to protect the write permission only with a publicly accessible hashed password?

Question

A user stores a raw information (a comment on a website, a like on a post etc.) in a database. He pairs it with a hashed password and keep the original password safely for him/herself. This password is required to modify or delete this data.

Let's say the password is randomly generated, long enough, the hash algorithm is very strong (I know nothing about cryptography).

Can this model be considered safe enough to let anymore read the entire database?

Such a database would contains only public informations, nothing secret. The password behavior is here just to protect the write permission on any data.

Answer 1

Blockchain database like Bitcoin works on essentially the same constraint and principle. So yes, it can be made safe. With that said, it's easy to get this wrong and unless you're doing something like a Bitcoin, there are often simpler and easier ways to achieve the same security goals. There are also lots of ways to make something that matches your description that is insecure, so your description itself isn't sufficient to rule out that it may be insecure.

The main technique to secure such database though, is that you need to use asymmetric cryptography. Rather than using passwords, you instead cryptographically sign any data you authored with your private key that other people can verify using your public key. A public key can be published publicly and can be read by anyone without compromising the security of the system, the private key is the "password" that one can use to prove that contents you author and an amendment to those contents is made by the same author.

If you don't want users to deal with managing a key pair and if you trust that your users don't use weak passwords, it's certainly possible to publish an encrypted version of your private key to the database and use a password to encrypt that password. If you do this, then from users' perspective everything will look and behave exactly the same as what you described, in that your authorship is protected simply by a password, though the difficulty of enforcing everyone to use strong password means that this is likely to be weaker in practice than if users just keep their private key to themselves instead of publishing the encrypted private key.

Answer 2

The short answer is "It depends", and most of the "depends" is based on the implementation details.

But it also depends on what, precisely, you're attempting to achieve. If the goal is a simple security scheme where casual users can have a high assurance that they, and only they, can edit their own content -- with the understanding that the database administrator can edit their content, or modify the stored hash so they or someone else can -- your scheme would offer certain advantages. Primarily, there is no need for an entire public / private key scheme.

As I hinted above, what you've described provides no assurance that a database administrator can't simply change the stored hash to some other value and grant access to a different user.

Answer 3

For SHA-2, SHA-3, Skein, Blake2, etc. the password is the weakest link in the chain. There are two potential attacks on such hashes which allow user impersonation. _{^{Besides things like rubber-hose attacks, surveillance, and social engineering.}}

1. Determine the password by brute force, guess-and-check
2. Search for another "password" which produces identical output

The difficulty of method one depends on how random the password is. If you use an RNG appropriate for generating cryptographic keys, read 128 bits, then use base-64 encoding to make the password human-readable, then this attack would be totally infeasible.

_{(Normally you'd use something like Argon2 to hash passwords. Humans fail to generate good passwords, so a hash function which is slow and costly to parallelize should be used instead of one of the algorithms listed a the start of this answer. But a fast, cheap cryptographic hash would suffice if all passwords are as difficult to guess as, say, an AES key.)}

Method 2 is ineffective for the algorithms mentioned above. They are all believed to have at least 256-bit preimage resistance. That means there is no search procedure faster than bruteforce that can produce some message which hashes to a given output. Such a search is expected to take as much work as evaluating a hash function 2²⁵⁵ times.

_{(Argon2 has as much preimage resistance as Blake2. So it should still be favored over cheaper hash algorithms for weak passwords, especially human generated ones. Argon2 has preimage resistance by design, as is intended to be used for hashing passwords.)}

In summary, revealing password hashes is safe if all passwords are known to be exceptionally strong and the hash algorithm chosen is preimage resistance. Otherwise hashes revealed to the public are vulnerable.

"Exceptionally strong" implies that the passwords will be longer and likely more difficult to memorize than typical passwords.