Few questions about password hashing

[Ahmad Bilal]

Hello or Salaam everyone,

I have a few questions regarding password hashing in general. And would very much appreciate any advice (just try not to use harsh words, please ;) )

Before that, I want to tell you something brief about what I'm doing. Basically I'm building a product that you can call in common terms as a social media website. For starters, you can think that it is meant to be a replacement for facebook/twitter. One that would respect your privacy (centrally). Actually it is much more than that, but that is not relevant here.

Now this is not an advertisement, I'm not even naming it. I respect the purpose of this mailing list. But I just want to make clear my good intentions, and inform you about "to what end" I might use your valuable suggestions on which you may spend your valuable time.

Also, I know that it is a huge undertaking. And on that account I tell you that I have spent 7+ best years of my life, entirely dedicated to pressing out the details of how to not repeat the mistakes of the current crop and how to do the right thing. How to make it into a neutral platform from the get go, and how to not make it a means of lot of bad things.

libgcrypt is an important tool, that can help me build such a product (like it has helped other such good intended projects). But Cryptography is not my forte, it might be yours, and that is exactly why I'm writing this email.

I'm working on the login system currently, running FreeBSD 11 / Apache / C CGI

Questions, in no particular order (correct me if I'm wrong anywhere): :

- FreeBSD recently replaced the RC4 algorithm with ChaCha20 in arc4random. While the libgcrypt is using SHA1 in its CSPRNG.

1. Is SHA1 secure in this role? For how long approximately? Are there plans to replace it with another algorithm in future?

2. How do both of them (arc4random and libgcrypt CSPRNG) compare in critical areas like security and efficiency?

- I see that (perhaps) Bcrypt is not available as a hash function in libgcrypt. I thought that it was (and is) a corner stone of password security? I don't understand. It is not a new hash function like Argon2, but an old one. I'm currently thinking of storing user passwords as salted bcrypt hash in a DB.

1. What are the reasons behind it not being there in libgcrypt (if so)? Is it not recommended?

2. I recently saw this: https://packages.debian.org/stretch/bcrypt , are all current bcrypt implementations using ECB mode and are considered unsafe?

3. If it is still considered safe, would it be implemented anytime soon in libgcrypt? On a side not,  I recently saw this: https://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/

- I do not yet fully understand the concept of KDFs and HMAC from the common texts (even after reading a few times),

1. Are they an option for me to use instead of common hashing? I heard a bit about the memory hard scrypt algorithm.

- What is the ideal flow of the authentication system in terms of cryptography? I know there are a lot more steps, but I'm just asking about the broad ones.

Here is what I have in mind:

1. Take form data from user, and sanitize it (specially for overflow and malicious code in submitted form).

2. Make a connection to DB, and check if user exists (if not, then log it, throw error, and exit)

2.5 Allocate secure memory ? <-- not sure about this

3. Retrieve Unhashed Salt (before bcrypt) <-- I'm not sure about this step, should it be hashed salt or unhashed salt

4. Concatenate the Salt with User submitted password and hash it

5. Compare this hash with the hash in DB (stored salted hash)

6. explicit_bzero , the string that contained plain password submitted by the form, the string containing salt (retrieved from DB), and the strings containing both hashes ?

7. generate 2-3 session keys (that only work in combo for one session) using CSPRNG (should be hashed using SHA-384 perhaps??) and set cookies for session management

X. At some point use mlock ? I do not understand what "preventing the swapping out" means here.

X. At what point do I need to free the secure memory (if used) at the earliest?

- I see that minimum secure memory allocated is 16384 (This is 16kb? 8bit = 1byte?) in libgcrypt when using GCRYCTL_INIT_SECMEM;
1. Is this going to be enough in my case?

2. If not, how do I arrive at a reasonably efficient and safe size? I mean how do I calculate my secure memory need here?

- If I use "GCRYCTL_USE_SECURE_RNDPOOL"

1. Do I still need gcry_random_bytes_secure convenience function? Can I just use gcry_randomize instead of it, and secure memory will be automatically allocated?

2. In the format of gcry_random_bytes_secure and gcry_random_bytes, I do not see a "buf" argument. Then how are these two functions used? I mean, where are the random bytes generated callable from?

- For error handling, I hear that libgpg-error is required by the libgcrypt.

1. Does it requires any additional headers?
2. What are the advantages of using the inbuilt error reporting of libgpg-error than normal error reporting in C? This question holds true for memory management as well.

- I could really use a simple chart that shows the salt length/password length requirement of different algorithms used in libgcrypt. It is a suggestion. I had hard time arriving at the facts about bcrypt:

password length min 8, maximum 56 in crypt(3)/FreeBSD, salt size should be exactly 128bit or 16bytes (correct me if I'm wrong)? End result is of variable size? or fixed size?

These are most of the questions I have at this point.

Thank you in advance. Honestly I cannot give you anything in return, but I know that Almighty is a witness to all good deeds, and knows the deepest and slightest of intentions we have when we do good (or bad). If a person does a good thing/deed and expects a reward from only him, know that he is the best to reward, fully capable of doing everything (including calculating a more than generous reward of ones deed. In both this world and hereafter)

Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20181123/d88add55/attachment-0001.html>