4
$\begingroup$

I'm working on a blockchain-based distributed application which stores Client information. I'm thinking of alternate ways to authenticate Clients on the network. One idea I got was to associate a Username and Password with the Client data structure -- where Password is a Hash(salt+password) where salt is securely stored only with us (the blockchain operator).

The clear security concern is that all participating members in the network can now view the hashed version of these passwords -- so how secure is this? Are there any other approaches I should be thinking about?

Improve this question
$\endgroup$
4
$\begingroup$

The main problem will be the password policy and users. If you let the users to choose any password, then they will tend to use 1234 as a password. A malicious user in your system can easily bruteforce all widely used insecure passwords. If you have a good policy, the only way is brute-forcing since we cannot reverse the hash and the salt prevents rainbow tables. For a general guideline for passwords, see NIST Digital Identity Guidelines 800-63B.

While considering the attack risks, we already assume that an attacker access the database of the users and we design our password systems as a last defense against the attacker. According to this, we design our system not by security by obscurity. So, you already in this stage.

Actually, we don't use a simple hash technique to store passwords. For example, iteration as in PBKDF2 can decrease the time of the attacker like 10000 times. Also, you need to protect against massive parallelization as in GPU usage of hashcat.

You should use PBKDF2, Bcrypt, or better argon2 which is the winner of the password hashing competition.

Also, for general advice see the How to securely hash passwords? from Information Security.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I was planning on using bcrypt, with minimum requirements set on passwords such as 8 characters minimum, one uppercase, one special character, etc. I will look into Argon2 as well. $\endgroup$ – Ryder Sep 1 '19 at 10:27
  • 1
    $\begingroup$ 8 is the minimum by the NIST, make it bigger. See Hascat on gtx-1080-ti $\endgroup$ – kelalaka Sep 1 '19 at 10:30
  • $\begingroup$ Alright. Ive been looking into Argon2, and come across 2 different versions - Argon2i and Argon2id -- which one should I use? Specifically, in the Golang implementation at godoc.org/golang.org/x/crypto/argon2 -- which function should I use? Also given that these will be public on the network, how much memory and threads and what key length should I use? (Sorry, I don't know much about cryptography, just a decent software developer) $\endgroup$ – Ryder Sep 3 '19 at 18:39
  • $\begingroup$ @Ryder This two questions may help you; When to use Argon2i vs Argon2d vs Argon2id? and also What is the difference between Argon2d and Argon2i? $\endgroup$ – kelalaka Sep 3 '19 at 18:41
  • 1
    $\begingroup$ It looks to me from the first question's answer that Argon2id is the way to go -- but at the same time I don't fully understand why still. About the parameters, I guess I'll have to look more into what the memory threads and keyLen parameters do and what my server can handle. $\endgroup$ – Ryder Sep 3 '19 at 18:48
0
$\begingroup$

It depends on the hash function you use. If you use fast hashes like MD5, SHA1-, SHA-3, it is not secure, because they make brute forcing easier.

There is a set of hash functions (called also key stretching or password derivation functions) like PBKDF2, scrypt, Argon2 that require relatively much computation resources (much CPU, much memory) for every hash. Single user notices no difference. But these functions make brute force essentially more expensive than the normal fast hashes. If is quite secure to use these hash functions. If somebody gets access to your database with such hashes, it will be impossible to recover passwords from such hashes.

"Are there any other approaches": Yes. Many.

  1. Use client certificates issued by you or by your company to authenticate users. Then you don't need any hashes at all.
  2. Use 2-factor authentication. It can be based on SMS, OTP (one time password), TANs including Photo-TAN. Think of Yubikey or Titan hardware tokens.
  3. Define user access profile. It is a combination of IP range, device data (laptop, smartphone model etc.), browser data (browser agent, screen resolution, etc.). This is something like Google uses. For Google you don't have to force users to have complex passwords. You don't have to think much of hashing. If you enter correct password from an unknown device or IP, Google requires additional confirmation that it is you.

Important: I suggest you to think if additional approach is adequate to what are you protecting.

What will it cost you or your users if smb. recovers some of the passwords? And what will it cost you to implement other approaches? If the whole purpose of your application is to send customized greeting cards, then hacking such an account doesn't lead to any serious harm and even normal fast hashes like SHA-3 are quite sufficient. But if your application provides access to banking account, you may need serious 2-factor authentication, because the costs in case of recovered password are much higher.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Yes I'll definitely use either bcrypt or Argon2. The client certificate idea is what we were doing before, but the UX seemed very poor for non-tech users -- we wanted something simpler. You are right that it provides access to banking accounts in a way, so I will start looking into 2FA as well. $\endgroup$ – Ryder Sep 1 '19 at 14:16
  • $\begingroup$ If you accept the answer, can you mark it as useful? $\endgroup$ – mentallurg Sep 1 '19 at 16:39
  • 4
    $\begingroup$ If somebody gets access to your database with such hashes - The question clearly specifies everyone on the network can view the password hashes, so mentioning this case doesn't seem applicable here. ... it will be impossible to recover passwords from such hashes. - Using a proper password hash does not make password hashes impossible to crack, it simply makes it more expensive. $\endgroup$ – Ella Rose Sep 1 '19 at 19:45
  • 1
    $\begingroup$ @EllaRose: 1) Regarding "gets access" - you are right. If you wish, you can edit it. 2) Regarding "impossible" - again you are right. I mean "the probability to recover it in a for an attacker acceptable time is is small. The resources needed to brute force are huge". Here you can find estimation, that 8-char SHA-512 password can be brute forced on a single CPU in 29 hours: crypto.stackexchange.com/questions/57680/…. For 20-char password it will take much more. For Argon2 depending on parameters even more. $\endgroup$ – mentallurg Sep 1 '19 at 20:29
  • 1
    $\begingroup$ @EllaRose: ... but yes, it is not impossible to brute force. But I think this particular question does not require answer with absolutely precise wording, because - if formally correct - an answer will be not read fully or not understood - and thus will be not helpful. That's why I'd prefer to keep my wording in this answer as is. $\endgroup$ – mentallurg Sep 1 '19 at 20:34

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.