0

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.

3 Answers 3

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.

1
  • I understand that with asymmetric cryptography anyone can more easily verify the authorship, which is great. But what I don't get is how the author edit his data, because when he comes to edit one data, we have to be sure that this is the actual person associated with the public key and therefore need an identification system right? Or does he need to provide the secret key?
    – Cinn
    Jul 22, 2019 at 23:13
1

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.

5
  • I didn't see the administrator point! My goal is having a secure database on a descentralised network (stuffs like edge computing), such as iExec. A public database like this makes it way much easier since it does not need identification if it does not have secret data. But I see from your respond that a worker (a computing node in a network) may change the hashes as it wants... hard to control!
    – Cinn
    Jul 22, 2019 at 23:16
  • @Cinn - I wrote the section on "Evil Database Administrator" for a former position. I explained how the "EDA" was unable to alter our database, except in a purely destructive manner. There's more to protecting the data than what happens OUTSIDE the server room. Jul 23, 2019 at 23:51
  • I didn't find it, is it a book?
    – Cinn
    Jul 24, 2019 at 10:02
  • @Cinn - It was a section in a white paper which was written for a former employer. As I prefer to do my best to be somewhat anonymous I’d prefer not to tell you the name of the employer or the paper or anything else of the sort. Jul 25, 2019 at 21:51
  • I understand no problem.
    – Cinn
    Jul 26, 2019 at 9:45
1

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 2255 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.

1
  • Thank you i will take care of those 2 conditions while trying to implement this! However I now need to figure out if asymmetric cryptography is not a better option as another response suggested...
    – Cinn
    Jul 22, 2019 at 23:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.