One way to secure a password in the database is to hash it with salt i.e. appending a random string to the password and then hash it and store the value.
Does encrypting the
password || salt then hashing it make it more secure? Is it really necessary (or can I skip the encryption part)?
Go to Source
Being not a cryptography expert, I am having some basic questions on how to manage keys wrt. sodium-plus. Let me briefly explain the context: the use case involves sending data from a web frontend to a backend, but the backend should not be able to read it (deliberate design choice due to privacy concerns). The data in question needs to be usable from different client machines (the same frontend used at different times on differnet machines). It should be en- and decrypted using a secret that is under the control of the user and not stored by the application. There is no second user involved that should be able to decrypt the data, so I see this as a scenario for using a shared-key encyption approach.
I am looking into using sodium-plus.js for this and in particular to use
crypto_secretbox, but am actually not clear on how to manage the key part in the scenario — ultimately, the user needs to have a way to access the same data on a different machine. Looking through the API documentation, I see two options:
- Generate a random key, convert it to a hex string, present the hex presentation to the user and leave it up to the user how she stores it. Then the user could use this hex presentation on the next client machine to decrypt her data.
Unfortunately, I seem to be unable to re-create a cryptographic key from the hex presentation (
hex2bin returns a (Promise for a) string). Is this even feasible? Also, I’m not at all convinced that this approach is not entirely defeating the idea of generating a random key in the first place?
- Derive a key from a password via
crypto_pwhash that the user has to specify. However, this requires also a salt, so I’m back in a similar unclear situation on how to handle it: if the user would give the same password on a different machine (on which to decrypt the data) I also have to use the same salt to generate the same cryptographic key. How do people handle this?
If I could easily have read up on all of this, I would appreciate pointers, as my search-fu seems to fail me.
Go to Source
I’m exhausted after looking for an answer for 3 days. I don’t know if my suggested flow is wrong or my Google skills have really deteriorated.
My API needs to create a valid certificate from a CSR it received, by signing it with a private key that exists ONLY inside an HSM-like service (Azure KeyVault), which unfortunately doesn’t offer Certificate Authority functions BUT does offer signing data with a key that exists there. My CA certificate’s private key is stored in the HSM. I’m using ECDSA.
My suggested flow:
- Client generates Key Pair + CSR and sends CSR to API
- API creates a certificate from the CSR
- API asks HSM to sign the CSR data and receives back a signature
- API appends the signature to the certificate and returns a signed (and including CA in chain) certificate to the Client
I’m using C# .NET Core and would like to keep it cross-platform (as it runs in Linux containers), so I have to keep it as native as possible or using Bouncy Castle (which I’m still not sure if runs in Linux .NET Core).
I really appreciate your help!
Go to Source