I'm using Identity Server and I lost one secret, and now I only have the hash
its anyway to obtain the original secret having the shared secret and hash of SHA256?
The best tool in the industry to crack a hash is to use HashCat, but depending on the hash algorithm used, it might take quite some time.
Related
I'll start by saying I understand wanting to make data as safe as possible.
I have an app and I would like to just encrypt all of the information that can be used to personally identify someone in the database.
So I have read that it is terrible to store your key on the same server as the data. Okay so separate servers, no problem. Then I've read that It's terrible to put the key in the code on the app server (away from the data). People say that the proper way to store an encryption key is by using a HSM or a Key vault like Azure Key Vault. Ok, I am on-board with that but if my code has access to the HSM or the Azure Key Vault (which it would need to have in order to decrypt or access the data AT ALL...
If my code is stolen from the app server (which is why storing the key in the code itself would be insecure) Why couldn't an attacker just use the same method that my code uses to decrypt the data from the HSM or Key vault?
Assuming that it isn't safe to just store the key inside of the code itself.. How is it any different to have a method or a function that can decrypt the data in the code? That would essentially tell the attacker how to get the key from the vault anyway, wouldn't it?
What is the extra vector or layer that using an HSM or Keyvault prevents?
I don't mind paying for and implementing the extra layer. I am genuinely curious as I can't really see any difference.
I think your question is mainly about protecting secret keys in software vs. hardware key management solutions. the following links have useful information about their differences:
Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks
https://www.itprotoday.com/iaaspaas/software-vs-hsm-protected-keys-azure-key-vault
if I understand your question correctly, it's because the application never sees the actual cryptographic keys. the HSM just exposes the primitive crypto operations, but never the keys themselves.
an attacker would therefore need to be logged into your "app server" in order to perform the operations, which is (hopefully) relatively easy to revoke/deny. if you had the keys available to the code itself then they could continue using the keys on any existing encrypted data until it has been re-encrypted after rotating in a new key. this also has associated assurance difficulties, e.g. how do you know the attacker didn't manipulate some data while this rotation was happening
I'm working on adding the option to encrypt uploaded files on my website by giving each file a "password", but I'm not sure of the best way to keep track of the encryption keys for each individual file. For example, when retrieving the file if the user enters the wrong password I'm pretty sure it'll download the file, but it won't be unencrypted properly. Is it best to store the hashed & salted passwords for each file in a database and match up there first? Or is there a better way to do it?
If you store the encryption keys as hashed (and salted) values, there is no way to retrieve the original encryption key. If you hash something (with a strong hashing algorithm), you cannot get the original back.
The best mechanism depends on the operating environment (OS, plus potentially other software installed), and on the requirements.
Depending on the specific requirements, it may be best not to store the encryption key at all. The point is that the user wants to protect data and the user knows the key. If it is possible to perform the encryption on the client side, the key would never have to traverse the network at all (e.g. encrypt in JavaScript). If the encryption must happen on the server, ensure the key is sent via an https connection, use it in memory to encrypt the file, and remove from memory (if your language supports immediately removing something from memory... e.g. in C# use a SecureString).
If you must keep the encryption key (which is a security issue on several levels), you will have to state more information about the operating environment.
Recently we've been diving into using OpenSSL to help encrypt/decrypt some data we have. Each "client" will have Public/Private key pair and X509 Certificate given to them by a local Certificate Authority. I'm now looking into encrypting/decrypting data with that key pair.
Everything I've looked into show using the methods RSA_public_encrypt and RSA_private_decrypt for RSA encryption. But the amount of data I can encrypt at once is limited by RSA_size(rsa) - 41 for the padding type RSA_PKCS1_OAEP_PADDING. So my question is how to encrypt larger amounts of data while sticking to our RSA scheme (no static keyphrases, etc). I was thinking about breaking the data up into chunks and then encrypting it but that seems like it's defeating the point of padding.
Any help would be appreciated.
Even if you break the data, you will find out, that the speed is prohibitively slow. The right method is
Generate random key for symmetric algorithm
encrypt the data using symmetric algorithm and the random key
encrypt the random key using your public key and store it in the encrypted form next (or before) the data.
You should use a standard like CMS (the basis of the S/MIME support in your email client) or PGP. There are libraries for both of these standards for just about every platform.
You will find that they are very similar in their approach to bulk data encryption, using a symmetric cipher to encrypt data and encrypting that secret key with the public key of the "message" recipients. This approach is secure and fast.
However, these standards go further, securely handling things you might not have thought about yet, like encrypting the data for multiple recipients, attaching meta-data to the encrypted content, etc. You also get interoperability with other software. For example, if you use S/MIME, you can use just about any email client on any platform to decrypt. In fact, depending on your integration requirements, you might not need to write any software yourself.
Using one of these well-established protocols won't solve all of your security problems, but it will make it more difficult to do something really dumb.
If i am not wrong, when you want to encrypt the content in the database you will use md5. I use that right now for passwords. But now i want to add encryption to all personal information, etc for enterprise clients. Below are my questions:
If I md5 everything, will php display everything the normal way, like without the md5?
When i allow editing of the content, i will have to display the info without the md5 and then add md5 upon submission, correct?
If someone gets access to the database, they will only see md5. But if they download it and then remove md5, wouldn't they see all the info?
As you can tell i am an amateur under pressure. Please correct me if i am wrong with my thinking of md5. If so, how can i encrypt the databases keeping in mind that info will be edited by users anytime.
Thanks.
MD5 is a hashing algorithm, not an encryption algorithm. Hashing is one way; that is, you cannot take hashed data and turn it back into the original data. MD5 is used to hash passwords (well, hashing algorithms are used to hash passwords...MD5 is generally regarded as insecure and not suitable for applications involving security...like passwords) because all you care about is whether or not the passwords match, not what the password actually is. This allows you to store a token in your database (the hash) that you can use to compare without actually storing the password.
If you're going to do application-level encryption of database data (rather than relying on any RDBMS-specific encryption features), you will always have to encrypt the data (in code) before you put it into the database and decrypt the data (in code) whenever you take it out of the database. For systems like this, a symmetric key encryption algorithm like AES is generally used.
MD5 is an hashing function! Is a one-way function.
You cannot decode a MD5 hash !
If you encode you content with MD5, you loose the data!!!
Instead use 3DES, BLOWFISH or other encryption methods!
Encription depends from DB to DB. More or less every db has an encription module to use (and pay)
As far as I know, MD5 is known not to really be a secure hashing function nowadays. There are places out there on the web offering reverse MD5 services, where they collect a huge database of strings with their MD5 equivalent. Try going for something like SHA-512 and use techniques like iterative hashing to make it more secure. PHP has a crypt() library you might like to checkout, or use SQLite database encryption maybe.
If I md5 everything, will php display everything the normal way, like without the md5?
Nope. Everything will be an md5 digest. The original data will be (almost) impossible to recover from the digest.
When i allow editing of the content, i will have to display the info without the md5 and then add md5 upon submission, correct?
Since the md5 digest cannot (easily) be decoded into the original data, you'll have to keep the original info somewhere.
If someone gets access to the database, they will only see md5. But if they download it and then remove md5, wouldn't they see all the info?
Nope. The md5 digest cannot (easily) be reversed to reconstruct any of the original info.
MD5 is one way hashing function. It won't be decrypted. JUST ENCRYPTED.
In some project we have very that even our staff is not suppose to have access to. In theory, we have policies to ensure they don't. In practice, we are in Africa and policies don't mean a lot, no matter how strongly you enforce it.
I would like to know is there is a way to encrypt data in your database so:
each user password encrypt and decrypt its own data, and its own data only;
data is decrypted as late as possible in the process to ensure maximum security to the user. Ideally it would be on the client side I guess, but I'd love to hear that it's possible to do some crazy thing I don't know about on the server side.
data is still searchable. Is that even possible?
My first idea was: "if a customer want THAT level of protection, then give him its own hosting on a virtual machine and encrypt the hardrive, then all maintenance must be done with it's allowance".
I can't come up with a fancy strategy just how I've implemented this:
Keep in mind that you have to re-encrypt everything when the user changes his password. I'm using always the same encryption key but the key is encrypted using the user's plaintext password. So I just have to re-encrypt the key. The user's password is stored as a salted hash so nobody can decrypt the key and the data even if he sees the hash.
It works like this:
User enters his plaintext password
Create salted hash
Check if the generated hash matches the one in the database (authentication)
If yes, then decrypt the key for the data using his plaintext password
Decrypt stored data using the key
This won't give you 100% security but improves it.
Here are a few things I can think of:
You should encrypt data stored when it is stored in the and when you read it back. Use a solution that integrates at an RDBMS level rather than the data layer.
For the transport of data to and from the application, use HTTPS web services.
If you have a Desktop application, do not store any data and log files etc locally.
If it is a web app, make the app HTTPS as well.
Security is bound to make the app a little slower than using plain data, but that's the price you will pay.
It really depends on what and where (on the client or server) you are doing with the data.
For example, your application don't need to know the password itself to verify it during authentification. Best practice for this use case is to store only a cryptographic hash (e.g. sha1) of the password and a random salt. That is sufficient to verify it, but giving only the hash and salt, it would take a nearly infinte amount of time to figure out the plain password.
Encryption can be a soultion if you have to exchange data over unsecure channels. But keep in mind that in order to process the data you have to decrypt them. So if de- and encryption is done on the same machine, it's rather pointless. And if decryption is required it doesn't matter how late you are going to do it, because of the key must be given anyway.
You can use encryption to secure the communication between the server and the client, for example. You could even generate messages on the server that only the client will be able to read and vice versa using asynchronous encryption. So once the message was generated on the server and encrypted using the client's public key even the server isn't able to read the message anymore, because of the private key only the client knows is required for the decryption.
What you denfinetly can not solve by cryptography is, when you have data on the server, that the server should be able to read in order to process them but human users unrestricted with priveleages to this server shouldn't.