I wanted to know if there exists a somewhat simple, but secure, method to encrypt strings(not passwords), with a password which is not stored on the server, in PHP.
I've checked A reversible password encryption routine for PHP, but I'm unsure if it is secure enough if intruders have access to the server and source.
We're talking about a automatic system where a computer sends a request to a server, which stores information in a log. So I'm thinking I could send the encryption password in the request header, preferably encrypted, but then it would be difficult to decrypt without storing the password somehow on the server. Wait, I think i might be complicating things a bit too much, but I hope you get the idea... It's meant to keep the information safe, even if hackers have full control over the server.
If I understand you correctly, you aim for a log that is encrypted by the server. The requests are sent in plain, but you'd like to log something like per-user access statistics or the like and you deem this data to be confidential, so it should be encrypted by the server and also be decrypted by the server, if necessary.
If this is the case, it is actually not all too complicated.
Generate an encryption key (AES would be a good choice) that is to be used by the server.
You store this key in a file.
Make sure that the application and only a few selected people have access to that location. Worst case would be it's served in your public files and anyone could download it from the web. So put it in a folder far away from your public resources :)
Encrypt that file using password-based encryption e.g. PBKDF2 in RFC 2898.
Then you will realize that you created a hen-egg problem - the file again needs a password for the server to have access to the key stored inside. But here's the trick - you will have to enter the key upon server startup manually, and that's the ephemeral component you need. The password for the file should be out-of-band information (e.g. placed in a physical vault) and nowhere on the computer itself.
An alternative (but potentially less secure because the password would be present in some physical form) is to rely on OS-specific "password vaults" such as Windows' Isolated Storage.
One option for this, which would seem to meet your requirements, would be to use public/private key cryptography. If you had the user encrypt the string using a public key then had the encrypted data stored on the server it would not be possible for an attacker to decrypt the data.
when/if you need to decrypt the data just copy it to a location where you have the private key and use that for decryption.
I would go with Mcrypt to encrypt/decrypt data in php.
My algorithm of choice would be twofish.
You will need a key to encrypt/decrypt data and sending it via request could be a security issue unless you have ssl implemented.
If the encryption should be on request not real-time thing than you could just execute the script in console so the password is not stored on the server.
The code for encryption/decryption is simple:
$encrypted= mcrypt_ecb(MCRYPT_TWOFISH, $key, $input, MCRYPT_ENCRYPT);
$decrypted= mcrypt_decrypt(MCRYPT_TWOFISH , $key, $data, MCRYPT_DECRYPT);
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.
Needed to store passwords in mysql from other services. Hash not work, i needed to decryt passwords. How to safety to do that? Only that i think safe way is to use hardware token with decrypt key? Is there any other issues? Sorry my bad English.
You ask how to safely to store encrypted data in MySQL in a way in which it can be decrypted automatically.
Here's the thing: encrypting and decrypting itself is easy. Php offers the mcrypt package. http://php.net/manual/en/mcrypt.examples.php
The safety of such a procedure depends, however, on secure key management. If the app you use with MySQL is capable of decrypting the data, and the key is available to it, then a cybercriminal who penetrates your system will have access to it. Cybercriminals can read your php code, see how you decrypt this data, and do it themselves. So the safety of this process depends on how hard it is for your opponents to obtain your keys.
I suppose you could create a web service that accepted encrypted data and returned decrypted data. That web service could hold the keys inside it. You could protect it in a few ways:
putting it behind a firewall
rate-limit it to a few dozen decryption operations per second
keep the decryption keys inside it.
log all operations (but not the decrypted data) and monitor the logs diligently.
Another possibility is to do something client side. The open-source password safe called Keepass http://keepass.info/ is a good example, and so is Bruce Schneier's password manager. https://www.schneier.com/blog/archives/2014/09/security_of_pas.html
One-way password hashing (http://php.net/manual/en/book.password.php) prevents decryption, but still allows password verification. It's much harder to steal passwords that are one-way hashed.
With respect, this is not a suitable project for an inexperienced person if the passwords protect valuable assets. Cybercriminals are way ahead of the rest of us.
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 am creating a program that communicates with a PHP script on a web server and to do so I need to be able to pass parameters from the program to the PHP script.
Now here is my question. At some point the user name and password needs to be passed to the script. Now this is not done in a way that is apparent to users (such as in an address bar) but I know with a little sniffing around someone that really wanted to could figure it out. So while my script is safe from injection, obviously variable tampering is an issue here.
This is an idea I have come up with so please help me wrap my head around it and see if this would work the way I THINK it will.
My thought was to encrypt the user password (or another unique key) variables on the client side before sending so you get a url like (obviously just made up) mypage.php?un=Oa348uty8&ps=op986hGTfreu Then when it gets to the PHP script decrypt it and encrypt it again with a different salt.
So when it leaves the application it would be encrypted but not the correct way, and then when it hits the PHP script server side decrypt it and re-encrypt it with the correct salt so it would correctly match the stored encrypted password.
This way, they user would not know what the encrypted version of their password is supposed to look like so without that they would not be able to tamper with the URL and try to insert fake values.
To put it in a nutshell, you are thinking of this:
On server side you have:
a database, with login/password matches.
a script that take 2 parameters (password and username) and check in the database if the couple exists
Your problem:
When your local application call the php script on server side, the 2 parameters are given in plain text. And you want to avoid tampering ( if your script are safe against injection i only see tampering used to bruteforce the auth <= keep in mind that i will keep this assumption in the whole post)
Your solution:
On client side, encrypt the 2 parameters
On server side, add a salt in your script to salt
Then decrypt the 2 parameters and encrypt with a salt
What I think:
This will not solve the tampering issue, someone can still forge requests.
The first encryption is useless because someone can retreive the key used by your client.
The second encryption is not safe enought because you use the same salt for all you users.
What I suggest:
Accept that tampering can't be avoided if you don't use a secure protocol like HTTPS (can either use SSL or TLS).
If you want an acceptable security without HTTPS the following is what i would implement:
A token system that you will check in order to see if the user can perform the login operation
A username that would not be encrypted
The password sha1 hashed stored in database
On client side, you call the script and provide the username as non encrypted and your password as a sha1 hash, rehashed with a random salt (sha1(sha1(pass)+salt) (the salt is stored in the user session on server side)
The script would then compared the provided hash with db password hash rehashed with session salt
The improvement is that the attacker must try to brute force two sha1 passwords consecutivaly and must provide a valid token to perform the login action. Plus if you use as salt a string using hex char of a variable even length, it will make the job harder for the attacker to recognised that the value bruteforced by the second hash is a sha1 hash, and even if he know it's an sha1 he will have to test multiple case to try to find the right portion of the value that correspond to the hash.
Because of variable salt, a same password won't be the same if hashed:
Imagine the attacker sniffed a hash and know which password was used then sniff another hash that was made with the same password as the other, the attacker won't be able to know that the 2 password where the same( a little overkill but still usefull).
It is safer to store the password as hashed value, because if the attacker manage to dump your user table, he won't be able to use the passwords right away, he would have to bruteforce each of then.
Finally sha1 hash are safer than md5 (i tell you that because you used the md5 tag in your post)
The downside of this method is that passwords can't be reversed, so you won't be able to given them back to your users if they lost it. You will have to make them set a new one.
An hardcore way (still without using HTTPS), would be to encrypt your password and username with a strong cypher (like AES or 3DES) and use a secure key echange algorythm (like the Diffie Hellman one) to exchange a random shared key.
This method won't block tampering, but will screw the attacker, because he won't be able to decrypt the value (assuming he only is sniffing the network). The key is random and never hardcoded in any of your application, so even if someone reverse your client, he won't be able to retreive a key.
I would still recommend to store your password value has hash.
An extreme way would be to merge the 2 methods but would be completly overkill.
Hope this will give you ideas
The problem with your approach isn't whether you are using encrpyted passwords and usernames in the URL or not. If the user authenticates by sending the encrpyted strings to you, then I as an attacker can still sniff out those hashes, pass them to your application and authenticate. This is unless then, that you do some public key/private key exchange before hand, but that is just reimplementing HTTPS, so you might as well just use HTTPS.
What you should do is to send the request using POST over HTTPS.
POST: So that the authentication details will not be in the URL and show up in logs and referrer URLs.
HTTPS so that the content of the whole request is fully encrypted and can only be decrypted by the client application and the server side.
encryption with Javascript from client to server only prevent from non SSL posting fails.
I think you must use sessions instead of this type encryption .
Update:
You could add your own secret key in both scripts.
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.