I'm working on my first secure shopping site. We're not storing credit card data, so that's not a problem. However, we do have a transaction key and API login key for our payment gateway (authorize.net) that I'd prefer to keep in a database, rather than hard-coding into my php. I don't know that we need tremendous security, but I would rather not store it in plain text. I know about sha, but that's one-way. I need a way to store the value in the database in a semi-secure format, but then be able to "decrypt" it programmatically for use in my function.
An additional caveat to this is that my site is hosted, which means there's a very tight limit to what kind of stuff I can install, so ideally any solution would rely on something that's included with a standard php install.
Can anyone point me in the right direction? I'm very new to securing data.
EDITED TO ADD: I checked with my host and mcrypt is installed. Is this the right direction to look in?
MCrypt can be your friend here. What you do need to take into account, though, is that every publicly available (and useful) encryption method requires a key. If AES encryption or 3DES encryption didn't require a key during the encryption process then breaking the encryption would just be a matter of trying every standard decryption method until you got a meaningful result. Thus, storing the key for your payment gateway incurs the exact same risks as storing the key for your encryption. No matter how many layers of encryption you want to add, at some level there will have to be a key stored in plain text, usually hard-coded into the PHP and often in an included config.php file to make it easy to change in the future.
The only option for securely storing information without the need for a key would be to invent your own encryption method. The security of this method lies solely in the fact that no one knows the means by which you are encrypting the string, so they don't have a step-by-step pattern to just walk backwards through. If you ever told someone how your encryption worked, though, then the security would be forfeit. Also, there are many algorithmic ways to break simple encryptions (letter replacement, for example). This is why mathematicians get a lot of money for developing things like AES.
Your best best is to look into MCrypt Encrypt and MCrypt Decrypt. This way if just your PHP is compromised then they know the key you used to encrypt, but they don't have the data. If just the database is compromised then they have the data but not the key you used to encrypt it. If both are compromised, you're screwed. But if both are compromised you're screwed no matter what you do, so that's a fairly safe route.
Hmm, you can try AES encryption. The problem is that you have to save the salt hash(98sdfx9c6v5c) somewhere in your PHP.
Insert config:
INSERT INTO config (secret_key) VALUES (AES_ENCRYPT('secret api key','98sdfx9c6v5c'));
select config:
SELECT AES_DECRYPT(secret_key,'98sdfx9c6v5c') AS secret_url FROM config
From a security perspective, there's no difference by storing it in the php files or in the database, if someone has access to your php files he has access to the database as well.
working with mcrypt doesn't mean you will have MORE security, (if they can read your php files they can read the key as well) so...
If I were you i'd store the API key in plain text on a file outside the web server directory.
just write good code you should be fine.
Related
User's content is encrypted, but needs to be decrypted. There are multiple files that need decryption to be viewed, and they will definitely not be viewed at the same time.
I am currently encrypting by using the user's plaintext password to encrypt a randomly-generated key, which encrypts the user's data. The password is hashed and verified normally before doing anything. I am using PHP's aes-128-gcm openssl_encrypt() function.
My current system requires a password every time the user wants to read a file.
I have thought about decrypting all of the content at one, but this doesn't scale well. I have also thought about storing the user's key as a cookie, but I'm worried about security.
Is there a standard way to do this?
Thanks!
The first thing to do is separate the users password out of this. You'll have to decrypt and re-encrypt all their files. There may be other ways around this such as allowing only new files to use this system. But that is very use case specific, such as how long do you keep their files, what is the turn over on them etc..
In any case this is a way to do that:
Encrypt the files they submit using a password you generate.
Store this password in another file we'll call it key.txt for now. Encrypt this file using the users password.
When user logs in (if they don't have it stored) take their password, decrypt key.txt and get the generated password.
Now you can save this generated password anywhere you want, without affecting the users account.
What they see (the end user experience) will look like always they go to downlaod a file, put their password in and get the file. They wont ever know you did this, which is nice for them.
So problem one is fixed.
Now where should we store this?
You could simply store it on the server in the DB. This sort of depends on how confidential the data is, and how secure your server is. Your ultimately responsible for the security of someone else's data, at least this way you can control it.
Make a table with these fields
user_id | ip | password | last_access
When a user goes to download a file, check their last access time and IP address to invalidate the password and make them refresh it. This is very easy to setup and totally under your control. If you save the encryption key, it will always have some level of vulnerability at least this way its all under your control.
Even if you don't want to store it in your DB, the biggest disadvantage here is if someone gets a hold of that table, but if they do that and your storing important data you probably have plenty of problems already.
At least use the first part as that solves a big problem with tying this to their actual account password. Even if a hacker gets the file password from the client (stolen cookies etc.) because it's separate, having that alone wont let them login to your site like the account password would. I am assuming here, a user must login to even get to the download part. Using the same password for both gives them them access to both the means of the getting this data and the method to download it.
To be clear, their is an argument to be made about storing it on the client side. Then if your site is compromised there is less chance someone could get a hold of the password as it (depending how you do it) only exist in memory on both the client and server etc. It puts the responsibility on them.
ASYMMETRIC ENCRYPTION
You could also use asymmetric encryption. Currently it looks you are using AES, which is fine, but it's a Symmetric Key block cypher. Basically there are three common forms of "encryption" (in vernacular):
Hashing (which really isn't encryption) - md5, sha1, sha256 - these are one way, can't be decoded. They have fixed lengths, and always encrypt to the same thing. It's common to see this for file checksum (for validating the contents of the file), Block Chain, Passwords or anything else where you need to compare two "encrypted" values.
Symmetric - AES, 3DES, Blowfish, Twofish - anything you need to encrypt and decrypt. The same key can do both. Generally these will encrypt the same thing to different values each time, because of the IV.
Asymmetric - SSL, DSA, RSA, PGP, used in Crypto currency wallets, TLS etc. With these you have 2 keys, a public one and a private one. The keys cannot decrypt their own encrypted data, only the other key can. So with this if you have one key on the server and the client has the other. You can encrypt their files using your key (decryptable by only their key) and you don't have to worry so much about someone getting your key as it won't allow them to decrypt the files. You can give one key to the client, who can use that key to decrypt their data you encrypted (even without your key). These also encrypt to different "Stuff" each time you use them.
So you can see Asymmetric form has a few advantages to use in a two(or more) party system. It also has the benefit that you don't need their key to encrypt a file. All you need is your part of the pair. So for example if you generate data for them and wan't to encrypt and later have them decrypt it with the same system, you can do that with no issues. This probably eliminates a step, as you would need to ask them, or keep track of their Symmetric anytime you wanted to encrypt something. Here you just need your part of the key pair.
It really isn't much harder to implement (on the server), its just harder to understand what it does. That's why I decided to add this, without this knowledge (which you may or may not already know) it's hard to use these terms and have them make sense. The only real disadvantage for you (if you call it that) if you used Asymmetric encryption, is if a client loses their key you would have no way to decrypt the file. So I would make sure they know to back them up in a secure place. It's the same problem that you see in the news when it comes to losing a crypto currency wallet which is encrypted Asymmetrically
As I said most of my knowledge has to do with encrypting and dealing with data on a server. So I am not sure how to tie that in to the "client experience". I do know for example how to use RSA keys for password less login for SSH etc. Which is kind of the same thing but not quite.
Hope it helps!
they will definitely not be viewed at the same time
Wouldn't the most secure answer here be to simply require the password every time? I would assume (although I'm sure this isn't the answer you're looking for) that simply asking for the password each time might be the best solution.
Although it may be tedious for the user, I would also assume it imparts some sense of security - since it's not quite as simple as logging in (as the files are encrypted).
From my perspective, I would argue that encrypted files should not be mass decrypted anyways?
Sorry, I know this isn't the answer you're looking for - but if you have more information about your motivation, maybe then a more reasonable solution can be found?
Don't do decryption on the server-side - do it client side. It is safe to keep the user's password in memory on their own device.
I have been asked to do some research on how form submission data can be encrypted and ensure that it is stored securely in a database. The form submission will contain personal details about employees and these must be kept secure.
I have come across AES_ENCRYPT() during my research and have managed to apply this function so that it stores the data successfully in the database.
Example SQL statement I used:
"INSERT INTO employee (firstname) VALUES (AES_ENCRYPT('$name', '$encryption_key'))"
However, I have very limited knowledge in this area and am not sure if this is sufficient enough protection to prevent the data being hacked. What level of security does this provide? Is there anything that I have missed or another technique I could use to improve my implementation?
Additionally, I have stored the encryption key in a separate PHP file but I do not know what the recommended way to store it is. Any advice on this would be much appreciated.
Sorry if this question is vague or quite broad. I am a complete beginner in this area. I am happy to provide more information if it is needed.
AES (Rijndael) crypto is pretty doggone secure. In practice, unless your data is tremendously valuable, you can consider it secure. Unless some actor with vast resources decides they want to crack your encryption, nobody will.
But it's symmetric. It uses the same key to encrypt and decrypt stuff. So, you can consider it to be as secure as your key.
Your key is insecure. If a cybercreep cracks the server running your php code, they immediately get access to your key. And that gives them access to your encrypted data. And they have a bright neon road sign saying "here's the data I think is sensitive."
Don't forget that security depends on the weak link. Generally it's considered smarter to use your money and time to secure your server, rather than use symmetric encryption on a few columns of a dbms. In other words, with respect, you're probably wasting your time doing this column based encryption.
If you absolutely must encrypt data at rest, you should consider using an asymmetric (public / private key) cryptosystem. Encrypt stuff using the public key, and keep the private key on an airgapped secure system in case you need to decrypt some data.
Your example (first name) isn't sensitive enough to be worth this trouble.
In a typical web scenario, a website user will come along, use a website, fill out a form, and transmit the data to the server for storage in the database. Now let's say we needed to ensure their address was encrypted as it was top secret, and only those with access to the back end of the website should be able to see what that address was - this is reasonably easy to achieve right? We would just store an encryption key server-side which would be used to generate the encrypted data, store the data in the DB, and we would just use the key again to decrypt it.
Now supposing someone at the hosting company were to browse the files on your server - they could very easily get access to this encryption key, and then use it to decrypt any data they wanted, since all addresses in the database have been encrypted with the same key!
I am just trying to cover every base with the new security model, and in a "trust no one" policy I am looking at ways of stopping the hosting company from getting at the data too.
So does anyone have any suggestions to prevent those with server access from obtaining the key and decrypting data? Would password salting help in any way, or would they still be able to decrypt data quite easily.
I can't think of a way around the issue. Does anyone have any suggestions to solve this particular problem?
Encrypt and decrypt in the browser everything sent to the host. Use a passphrase entered on the client to do the cryptography, and never send the passphrase to the host. There's a fuller description at Host-proof Hosting
I guess that's a risk when it comes to shared hostings. I'm using amazon aws for most of my projects and linode for my personal blog. Both solutions are in the model "you are your own sysadmin" and nobody peeks in your machines.
If I was in your shoes, I'd use mcrypt with a variable key. For example, whe username field of the same row. This way, for the data to be compromised, the intruder would need to get access to both your database and source code to figure out how to decrypt the data. At that point your problem would be far worse than a mere information leak.
Well mostly hosting companies have access to all databases and files that is bad really bad.
Few years ago I did some experimenting with encryption and decryption.
The best way would be to have personal servers, but that isn't cheap.
Example RC4 encryption requires key to crypt data. Now tricky part is to make that key also encrypted with some other encryption like BASE 64 , ATOM 128. This wont make it be 100% secure
But It will be really hard to decrypt data.
I hope you can understand me.
Cheers :)
btw point is there is no 100% secure data.
If you don't need to be able to decrypt the data online, this is an ideal situation for public-key cryptography. In particular, a sealing API. For example, using libsodium (PHP 7.2):
Encryption
$store_me = sodium_crypto_box_seal($plaintext, $box_publickey);
sodium_memzero($plaintext);
Decryption
$plaintext = sodium_crypto_box_seal_open($stored_msg, $box_keypair);
If, however, you do need to be able to decrypt the data from the webserver, then anyone who accesses the webserver can just pilfer the keys and decrypt your data. No cryptography algorithm can stop someone with the keys from decrypting messages.
Always start with a threat model.
I'm using Zend Framework with a LAMP stack. The client has requested protection of sensitive data, email included. In this project, emails will be used in two ways: for sending automated messages and for sending newsletters.
Has anyone worked with this? What algorithms are fast, reliable and can be used with a variable encryption key? Where should I store the encryption key? What engine should the database table use?
Ok, these are my 2cent.
For data that needs to be both encrypted and decrypted on the fly, I would suggest symmetric key algorithms, and the first that comes to mind is Blowfish. It is both fast, and relatively safe.
As to the variable keys. Usually there is little to no merit in having a different key for each entry that needs to be both encrypted and decrypted. Thus, I'd recommend using a single key, that is set in config file somewhere.
If you do need to have a key for each of the users/records, I'd recommend not keeping them in the db. Save them to flat-files on the disk.
As to table engine, it should not matter which one you choose, as long as it's not memory based.
As to merit - I think there is merit, if the client specifically asks for it. Even if there is technically little reason to create this encryption, this will contribute to the clients feeling of safety. Sure, it could be a false one, but it does help keep the data a bit more safe, and lets the client sleep more soundly. Therefore, if the client asks for it, go for it!
If you really have to do this, the answer Janis Peisenieks gives is a good starting point.
As far as I know, there's no safe way of storing keys in PHP - this means that an attacker who gets a moderate level of control over your system can retrieve the key from a config file, and use that to decrypt the data.
An attacker who wanted to know the email addresses of your users would have several options to retrieve that data - as GordonM writes, if your system sends email to those users, that email is relatively easily to intercept, and whilst the body may be encrypted, to "to address" is not.
Just checking that you will be hashing (not encrypting) passwords (if your system uses these?)
I have a PHP app that needs to run bash scripts, and provide a username & password (for remote systems).
I need to store these credentials somewhere that is accessible by my PHP (web) app.
The logical place is the database (currently MySQL, but will be agnostic).
The problem with the "standard" way of hashing and storing the credentials, is that it is not reversible. I have to be able to get the credentials out as unencrypted clear text, to be able to insert the data into bash scripts.
Does anyone have any suggestions for a secure way to go about this ?
I thought maybe PKI'ing the credentials, and storing the result in the DB. Then use the private key to unencrypt (PHP can do that). Store the scripts to do this outside the web root.
Any thoughts much appreciated.
First, to state the (hopefully) obvious, if you can in any way at all avoid storing usernames and passwords do so; it's a big responsibility and if your credential store is breached it may provide access to many other places for the same users (due to password sharing).
Second, if you must store credentials prefer rather to stored passwords using a non-reversible, salted cryptographic hash, so if you data is compromised the passwords cannot easily be reverse-engineered and there's no need to store a decryption key at all.
If you must store decryptable credentials:
Choose a good encryption algorithm - AES-256, 3DES (dated), or a public key cipher (though I think that's unnecessary for this use). Use cryptographic software from a reputable trustworthy source - DO NOT ATTEMPT TO ROLL YOUR OWN, YOU WILL LIKELY GET IT WRONG.
Use a secure random generator to generate your keys. Weak randomness is the number one cause of encryption related security failures, not cipher algorithms.
Store the encryption/decryption key(s) separately from your database, in an O/S secured file, accessible only to your applications runtime profile. That way, if your DB is breached (e.g. through SQL injection) your key is not automatically vulnerable, since that would require access to to the HDD in general. If your O/S supports file encryption tied to a profile, use it - it can only help and it's generally transparent (e.g. NTFS encryption).
If practical, store the keys themselves encrypted with a primary password. This usually means your app. will need that password keyed in at startup - it does no good to supply it in a parameter from a script since if your HDD is breached you must assume that both the key file and the script can be viewed.
For each credential set, store a salt (unencrypted) along with the encrypted data; this is used to "prime" the encryption cipher such that two identical passwords do not produce the same cipher text - since that gives away that the passwords are the same.
If the username is not necessary to locate the account record (which in your case it is not), encrypt both the username and password. If you encrypt both, encrypt them as one encryption run, e.g
userAndPass=(user+":"+pass);
encryptInit();
encrypt(salt);
encrypt(userAndPass);
cipherText=encryptFinal();
and store the singular blob, so that there is less occurrence of short cipher texts, which are easier to break, and the username further salts the password.
PS: I don't program in PHP so cannot comment on suitable crypto s/w in that environment.
You'll need to look into good 2 way cryptographic methods, and my general rule of thumb is:
If you implement your own cryptographic code you will fail.
So, find a good implementation that is well verified, and utilize that.
There is probably some good info here:
http://phpsec.org/library/
Check this library: PECL gnupg it provides you methods to interact with gnupg. You can easily encrypt and decrypt data, using safe public-key cryptographic algorithms.
I would suggest you not store the passwords, but use passwordless ssh connection from the host to the remote system by generating a ssh key and storing your public key in the remote system's authorized_keys file. Then you would only need to establish connectivity during configuration. Admittedly not quite answering your question, but storing passwords in a reversible form is a slippery slope to a security breach imho, although I am sure smarter brains than mine can make it safe.
One easy way to get started is to use mysql's ENCODE() and DECODE() functions. I don't know what algorithm is used underneath, but it's easy enough to use:
INSERT INTO tbl_passwords SET encoded_pw = ENCODE('r00t', 'my-salt-string');
and
SELECT DECODE(encoded_pw, 'my-salt-string') FROM tbl_passwords;
If you go the PKI, and I would, make sure you safe guard your private keys! The strong encryption provided by PKI is only as secure as your keys.
I think you're on target. Look at GPG for a good, open encryption library
It looks like you pretty much have two methods of doing this:
1) Like you suggested use an encryption algorithm or algorithms which can then be decrypted and used for authentication in your scripts. You can use the MCrypt library in PHP to accomplish this.
2) Depending on the required level of security and your script's level of vulnerability, you could use a secure hash, key, or some other hard to guess unique identifier that you can use to hijack each user's account within the confines of the script.
As many stated you scenario requires that you encrypt username and password. I would recommend that you check out the mcrypt extension of php for encryption/decryption.
I think I am going to investigate compiling a PHP script with the credentials embedded, on the fly, from the web app.
I would ask for the credentials (for a given use), then create and compile a new PHP script, for this use only. That way, the script will only do what I need, and should not be "readable". I think this sounds like the safest way to do this.
Will try using Roadsend. http://www.roadsend.com/
Just to follow up on the suggestion to use MySQL encode and decode functions, the manual is vague on just how these work:
The strength of the encryption is based on how good the random generator is. It should suffice for short strings.
But what I'd suggest is that you can instead use the built-in MySQL 5.0 AES functions; AES_ENCRYPT() and AES_DECRYPT()
SELECT AES_ENCRYPT('secret squirrel', '12345678') AS encoded
=> ØA;J×ÍfOU»] É8
SELECT AES_DECRYPT('ØA;J×ÍfOU»] É8', '12345678') AS decoded
=> secret squirrel
These use 128-bit AES which should be strong enough for most purposes. As others commented, using a salt value and a key with a high entropy is a good practice.
For PHP, it is important to note that AES encryption is implemented via MCRYPT_RIJNDAEL functions. Don't go paying for a non-open implementation when PHP has them available.
See the PHP page discussing available ciphers for more information.