I'm working on a project with some sensitive data. I'm trying to do statistics about Facebook conversation with a client only website. Until now, I have a big JSON file of a Facebook conversation that I parse and do stuff with data. I want to be able to deliver this file only to my friends. So, what I thought is that I locally encrypt it (with I don't know yet which algo), deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ? I don't want someone to be able to bruteforce it or whatever, as it is private conversation. And do you have any recommendation about the algo I should use ?
You placed an abstract question so you may get only an abstract answer
deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ?
There are a few conditions to make encryption safe.
using any modern cipher which is not considered weak (e.g. AES-128 provides enough of security)
the encryption key is random (or password used to generate the key is long and random enough)
optionally you may add an authentication tag to ensure message integrity
And do you have any recommendation about the algo I should use ?
To encrypt data itself, any current modern cipher will do, e. g. aes, 3des,...
If you don't want to dive into security and you just want to encrypt a file, you can you some out of box tools which would do that for you. Try to look at openssl, pgp, gpg or nppcrypt (plugin for notepad++). Just make the password long and random.
The question is how do you get the key or password to your friend safely. You can either use different channel or using asynchronous (such as RSA or ECC). You can search, read, try out and ask more specific question
Related
So I just got my first Computer with MacOS (never used MacOS, idk anything). I am trying to make a password manager which stores all my data (usernames, emails, passwords etc.) so I only need to remember one MasterPassword.
All the Data is AES encrypted with that MasterPassword and the hash of that Password is currently stored in a .txt file. Now I am thinking: What if someone just puts his own hash into that file and just logs into the program ?
How do I store this hash safely?
In general, the number one rule of crypto is "never roll your own crypto". (never write your own system to be secure when somebody else has already written one.) There are a number of reasons for this, but the most obvious is that even if you are very smart, an established package will have had more smart eyes on it to patch any security issues you might have missed.
If you want to safely store your data, use a password manager that is well-established.
If you want to make a password manager as a personal project though, here are some things to consider.
The most secure way to store a hash is to not store it at all. If you're AES encrypting your data, the way to verify that it has been decrypted is that the decrypted plaintext is correct. That way, you don't need to store anything regarding the password at all.
You want to salt your hashes so that common passwords do not lead to common hashes. The SHA-512 sum for password is 9151440965cf9c5e07f81eee6241c042a7b78e9bb2dd4f928a8f6da5e369cdffdd2b70c70663ee30d02115731d35f1ece5aad9b362aaa9850efa99e3d197212a. Here are the google search results for that string. If we instead hash password+EsistDerPascal K we get a string that returns no google search results. See the link for standard hashing techniques.
Use a proper cryptographic hash. While many things still use SHA-512 others have moved to bcrypt or other algorithms. If you're here from the future and Ubuntu isn't using SHA-512, don't use it.
You want your hash (and salt) to be only readable by users who should be able to use it. The easiest thing here is probably using chmod 600 to restrict read/write of the file to your user (or another user, or root).
This is an incomplete list and you should not rely upon any of the above to protect sensitive information.
I am currently in the process of making an online desktop of sorts, and one of the offerings that I will advertise is that the data on your online desktop is encrypted with your password, not our key. So instead of checking the password with a database then decrypting the data with our key, I would like to have each customers data encrypted with their password. The server will then try to decrypt the data with the password. If the decrypting is successful, the data is sent to the client for JavaScript or another language to organize and display. Otherwise, a failed password attempt is sent back. I would also like to completely take myself out of the equation with the passwords by making it impossible for the server to log the password or see the password in any way whatsoever, so your security is in your hands, not ours.
My question is what language would be best suited for that, and the proper methods and functions for doing this. Once I have that information, I will learn that language, and those methods and functions to do this.
I am not too worried about a quick release of hiring a dev as rite now this is a project I challenged myself to, and doing it for fun.
Thanks in advance!
I'm currently developing an iOS app and in which I encrypt some user data with a user-chosen key. The data can be stored locally or in iCloud or both. I also want to allow a quicker access such as 4-digit pin code or drawn pattern.
In both cases I can store an encrypted key in the iOS keychain and decrypt it with the 4-digit code or the pattern string. Basically, I don't store the master key in plaintext to the keychain.
The problem is Touch ID. Currently I'm storing the master key in plaintext to the keychain because I can't figure out how not to. If anyone could give me an idea, concept, pseudo code or whatever, I would really appreciate it.
The problem is that the PIN and pattern don't contain enough information to create a secure key. They can only be used to unlock things (because you can reject the login after X tries and you may not be able to automate the login process).
If I'm not mistaken iOS already uses PIN or pattern for protection of the key chain; this article seems to concur with this. As Apple does seem to use the PIN or pattern for encryption, it's no wonder that iOS keychain protection is easy to break. But building your own scheme on the same principles isn't going to help, so you might as well stick to the key chain.
The only other way of handling this correctly is to ask the user for a strong password, use PBKDF2 or bcrypt on it and encrypt with the resulting key.
So I would like to modify a PHP / MySQL application in order to store credit card but not cvv and bank account info securely. PCI DSS require 1024 RSA/DSA. A small number of users will be given private key in order to decrypt the batch file of account info for submission to payment processors monthly. I'm unclear if it is possible to have a system that would allow the users who have signed in with normal 8 digit passwords to modify their own account info securely. It seems that this is not possible, and the encryption should be one-way (ie each user -> admins; never allowing user to decrypt their own info again), with account info never exposed back to users even over SSL connections. Or is there a proper and easy way to do this that I'm unaware of that is PCI DSS compliant?
PCI DSS does not require 1024 bit RSA to encrypt. Older versions of the specification mentioned AES and 3DES by name, but I believe newer versions just specify strong encryption. Most people are using AES 256.
Encrypting data at-rest with an asymmetric algorithm doesn't really work. Symmetric algorithms work best. This allows the application to access the card data when it needs to. This doesn't mean you have to show the data to the user ever again, it just means the data is there when you need to get to it. If you're storing credit card authorization information, you'll usually need the card number for settlement. (It really depends on the features your processor has. Some of the small-business level processors store the card for you, but this is infeasible for large scale processors like Paymentech and FDMS.)
The problem is that you will have to rotate your encryption keys periodically. This is usually what screws everyone up. If you roll your own encryption, you need to make sure that you can specify n number of keys that are accessible for as long as there is data encrypted with those keys. At any point in time, only one of those keys should be used for encryption. Unless you have a deep understanding of crypto and key management in terms of PCI, you might want to go with a commercial offering. Yes, these are expensive, but you have to determine the best course with a build or buy decision making process.
Ingrian (now SafeNet) has a decent offering for a network HSM. It will manage the keys for you and do the cryptographic operations. It may also be possible to use their DB level encryption integration so that you don't have to change your application at all. (Though DB level encryption is dubiously secure in my opinion.)
This is a very deep subject; I've done a lot with PCI and suggest you hire someone to guide you through doing it properly. You'll spend a lot of money on false starts and redoing work, so get an auditor involved early to at least asses what you need and tell you how to implement the security properly.
You may have an easier time if you differentiate between data storage, access, and transmission.
Storage requires strong reversible encryption; the data is not useful unless you can retrieve it.
Access requires a user or process to authenticate itself before it is permitted to decrypt the data. Here's an example of a mechanism that would accomplish this:
Store the data with a secret key that is never directly exposed to any user. Of course, you'll need to store that key somewhere, and you must be able to retrieve it.
When each user chooses a password, use the password to encrypt a personal copy of the private key for that user. (Note: even though you're encrypting each copy of the key, security issues may arise from maintaining multiple copies of the same information.)
Do not store the user's password. Instead, hash it according to standard best practices (with salt, etc.) and store the hash.
When a user provides a password to log in, hash it and compare to your stored value. If they match, use the (plainitext) password to decrypt the key, which is then used to decrypt the actual data.
Transmit the data through a secure connection, such as SSL. It's reasonable (perhaps required) to allow users to access (and modify) their own data, as long as you continue to follow best practices.
Comments:
An 8-digit password implies a key space of 108 ~ 227 = 27 bits, which by today's standards is fairly terrible. If you can't encourage longer (or alphanumeric) passwords, you may want to consider additional layers.
One advantage to the multiple-layer strategy (user provides a password that is used to encrypt the "actual" key) is that you can change the encryption key transparently to the user, thereby satisfying any key-rotation requirements..
The standard admonition whenever you're designing a security solution is to remember that DIY security, even when following standards, is risky at best. You're almost always better off using an off-the-shelf package by a reputable vendor, or at least having a trained, certified security professional audit both your strategy and your implementation.
Good luck!
Some web applications, like Google Docs, store data generated by the users. Data that can only be read by its owner. Or maybe not?
As far as I know, this data is stored as is in a remote database. So, if anybody with enough privileges in the remote system (a sysadmin, for instance) can lurk my data, my privacy could get compromised.
What could be the best solution to store this data encrypted in a remote database and that only the data's owner could decrypt it? How to make this process transparent to the user? (You can't use the user's password as the key to encrypt his data, because you shouldn't know his password).
If encryption/decryption is performed on the server, there is no way you can make sure that the cleartext is not dumped somewhere in some log file or the like.
You need to do the encryption/decryption inside the browser using JavaScript/Java/ActiveX or whatever. As a user, you need to trust the client-side of the web service not to send back the info unencrypted to the server.
Carl
I think Carl, nailed it on the head, but I wanted to say that with any website, if you are providing it any confidential/personal/privileged information then you have to have a certain level of trust, and it is the responsibility of the service provider to establish this trust. This is one of those questions that has been asked many times, across the internet since it's inception, and it will only continue to grow until we all have our own SSL certs encoded on our fingerprint, and even then we will have to ask the question 'How do I know that the finger is still attached to the user?'.
Well, I'd consider a process similar to Amazons AWS. You authenticate with a private password that is not saved remotely. Just a hash is used to validate the user. Then you generate a certificate with one of the main and long-tested algorithms and provide this from a secure page. Then a public/private key algorithm can be used to encrypt things for the users.
But the main problem remains the same: If someone with enough privileges can access the data (say: hacked your server), you're lost. Given enough time and power, everything could be breaked. It's just a matter of time.
But I think algorithms and applications like GPG/PGP and similar are very well known and can be implemented in a way that secure web applications - and keep the usability at a score that the average user can handle.
edit I want to catch up with #Carl and Unkwntech and add their statement: If you don't trust the site itself, don't give private data away. That's even before someone hacks their servers... ;-)
Auron asked: How do you generate a key for the client to encrypt/decrypt the data? Where do you store this key?
Well, the key is usually derived from some password the user has chosen. You don't store it, you trust the user to remember it. What you can store is maybe some salt value associated to that user, to increase security against rainbow-table attacks for instance.
Crypto is hard to get right ;-) I would recommend to look at the source code for AxCrypt and for Xecrets' off-line client.
Carl
No, you can't use passwords, but you could use password hashes. However, Google Docs are all about sharing, so such a method would require storing a copy of the document for each user.