Does anyone else had that issue?
In a php 5.4.9-4 environment when I call echo hash('tiger192,4','test'); I receive 14b5375c7b29cbf5f9e70a199a40e59dd4d5f1df218b5249 as response.
Now, in a php 5.3.10 environment when I call the SAME function I receive f5cb297b5c37b5149de5409a190ae7f949528b21dff1d5d4
I think is something with the tiger192 hash family because when using sha256, for example, it generates the same value.
I saw that in php 5.4 the tiger family is using big-endian byte ordering. Now, does anyone knows how to disable it to keep the compatibility?
Sadly there is no a compatibility setting for this, and you should not expect to be able to move between major versions of software without having to rework parts of your code.
If resetting the hashed data is not an option (but then i don't see why not? As inconvenient it may be, after that your hashes will be much more secure) then you could write your own function to do the hashing since algorithm is publicly available http://en.wikipedia.org/wiki/Tiger_(cryptography)#Algorithm.
Related
I have a WHMCS module and I am wondering if it's possible to encrypt it with SHA-256 or another form of uncrackable encryption.
I really know nothing about encryption but I want to ask is that possible? My plan is to encrypt it doing the following.
The top part of the script encoded with PHP > Ioncube will tell the script where to read the SHA-256 pass-phase either in a well hidden readable file or on our online servers. The rest of the script will be encrypted with three layers PHP > Ioncube > SHA-256.
Is that possible? If so would it slow the script down considerably?
First: SHA-256 is a hash algorithm, not an encryption algorithm. If you indeed know nothing about encryption, it's probably best that you either learn more about it before embarking on an encryption-heavy project, or avoid it altogether.
More generally: What you're trying to do is possible in principle, but probably a bad idea. Existing PHP loaders such as Ioncube already take appropriate steps to try to prevent source recovery; piling on additional layers of your own design is likely to make it less secure, not more so. (In particular: putting an extra decode/eval phase inside IonCube will make it trivial to recover your source code using a debugger.)
I have my own crypt/decrypt function in PHP which is on my server.
I feel it is not a safe thing to store it in my server as if one day we get to be hacked. The hacker can decrypt easily our datas.
Would like to know if is there is solution to this ? How can we protect our own PHP functions ? Is it better to store the decrypt function in another server.
Thank you in advance for your answers !
It looks like you want to disregard Kerckhoffs's principle and that is fine in some cases. If you want to encrypt data at rest, then there is essentially nothing you can do besides obfuscation (PHP code "encryption" techniques are nothing more than clever (?) obfuscation).
For example: Since every obfuscation can be reversed with enough time (but not so much time what would needed to break an encryption), a key that was used to encrypt the data and which is embedded in the code can be extracted and your data decrypted.
If the server only stores encrypted data (which I somehow doubt because that would make it not very useful) and never uses the decryption, only then it would add some security to your arrangement by out sourcing the decryption function. This would raise the bar, because the attacker would need to exploit (possibly other) weaknesses of the second server.
Do Not Implement Your Own Crypto
Never try to develop your own crypto. You should choose use one of tested and trusted by professional. Please watch this video I believe you will understand why you shouldn't implement your own crypto. ( https://www.youtube.com/watch?v=3Re5xlEjC8w#t=49 )
If you really want yo use your own crypto, you may want to encode your php application. Because likely to you are going to store your private key into your source codes.
Example for Plain-text form of PHP source code.
It will be something like when you encode your this php source code.
Further information : http://www.virtual-apps.com/post/security-and-performance-benefits-of-encoding-php-files
I am using a Postgres 9.3 database as a back-end for a web application. I use PHP 5.5.7 to connect to the database and return JSON for the front-end AJAX calls.
I'm trying to decide on where to put the user authentication logic.
I am not a security expert; however, I am familiar with PHP's new password_*() functions and I have a strong grasp of what is going on under the hood. I am also familiar with the Postgres Extension pgcrypto and the associated crypt() function.
My question is, does it make sense to use PHP or Postgres to hash passwords?
I was curious as to how these functions differ, so I made a password hash in PHP and then gave it to Postgres to see if Postgres uses the same algorithm. Given the same parameters, Postgres returned a different result when compared to PHP (not unexpected, but with noting).
PHP
password_hash('password', PASSWORD_BCRYPT, ["cost" => 15]);
output: $2y$15$o8JufrnVXoob2NKiEGx6.uI4O2D4VcaAmY7WtNq5zPFiJow4KohGu
Postgres
SELECT '$2y$15$o8JufrnVXoob2NKiEGx6.uI4O2D4VcaAmY7WtNq5zPFiJow4KohGu' = crypt('password', '$2y$15$o8JufrnVXoob2NKiEGx6.uI4O2D4VcaAmY7WtNq5zPFiJow4KohGu')
output: false
PHP vs. Postgres
Given that these processes are different, I wonder if one is better then the other? Is one more, or less, secure?
Some other thoughts:
I currently have all logic stored in the database (in views, functions, constraints, etc.) so if I ever need to use a different front-end I don't have to worry about missing logic. Calculating password hashes in PHP would effectively require all requests to pass through PHP to access the database.
On the other hand, putting the logic in the database would allow me the flexibility to use other connection options; however, all of the Postgres queries are logged. I can't disable the logs because of the WAL used in replication. This seems like a big security hole.
Am I on the right track here? What am I missing?
EDIT
I just looked at another message thread and found some more information.
Putting the logic in Postgres would require the database to processes and perform the hash operation. This would be a bad thing for other users and batch jobs that need those resources.
Not only would the hash slow down normal operations, it would make the whole system more vulnerable to DOS attacks.
Our simple web servers with load balancing would address both issues...
Again, am I on the right track here? What else am I missing?
For the difference between versions 2y and 2a, see this thread and the various links within it:
https://security.stackexchange.com/questions/20541/insecure-versions-of-crypt-hashes
My understanding is there was a problem with the 2a implementation in PHP until v.5.3.8, though only for strings that contained non-ascii chars. PgCrypto, as you noted, doesn't "speak" 2y for some reason, and I'd assume it suffers so such problem. (Perhaps report this as a bug?)
Apart from the points raised in the latter, you nailed the main security difference between the two in your question: systematically hashing the password within the database is convenient but implies that you send it to your database in clear text, where it can (and will) be logged — or snooped at outright, if your DB connection is not encrypted.
In an ideal world, you'd hash the password in the client app using javascript before it's even sent to PHP. The next best thing is to send it using SSL to PHP, then hash it using PHP before sending it to the DB.
Aside: I'm pretty certain that PHP's crypt can generate a (secure) 2a version hash if you need interoperability for some reason.
I need to up the security of our website, and is currently using the guide here: http://crackstation.net/hashing-security.htm, and also the generation of random passwords here: https://defuse.ca/generating-random-passwords.htm. I gather that both uses the function mcrypt_create_iv() for generating random bytes (or bits?), but for some reason, I encounter errors in installing php-mcrypt under CentOS 6. Fortunately, the first link said that openssl_random_pseudo_bytes() is a CSPRNG (and the PHP documentation and other sources also back that claim), and is available on the current server installation of PHP 5.4, so I have no choice but to use that at the moment. With these in mind, I would like to ask the following:
Does a direct code substitution suffice without affecting security? (That is, just replacing calls to mcrypt_create_iv() to openssl_random_pseudo_bytes() would do?)
About the constants mentioned in the code (http://crackstation.net/hashing-security.htm#properhashing), the guide says that "[m]ake sure your salt is at least as long as the hash function's output." Am I right in assuming that PBKDF2_SALT_BYTES and PBKDF2_HASH_BYTES are both set to 24 bytes since the output of the pbkdf2() function would be just 24 bytes, not 32 (for 256 bits) since the underlying algorithm used is sha256? (Yes, I am using key stretching too.) In a related note, is 24 bytes fine, or should be increased/decreased, and what effect would that have?
Advanced thanks for those who will answer.
I think the security will not be affected because both functions are just cryptographically secure pseudorandom number generators (NB: openssl_random_pseudo_bytes($len, true) and mcrypt_create_iv($len, MCRYPT_DEV_RANDOM)).
PBKDF2_SALT_BYTES is used only in the test function create_hash() and not in pbkdf2() itself. So you just need to implement your own salt generation function using those CSPRNGs.
I am migrating my PHP code to Google App Engine - Java.
Since I couldn't find an equivalent function of crypt in Java,
I can do without it if I find an equivalent function in actionscript.
Edit 1: Here is my php code for encrypting passwords :
$password = "test123";
$pwd = crypt($password,$password);
echo $pwd;
Output is (On Windows as well as a linux based server on HostMonser):
temjCCsjBECmU
as3crypto might be of help. It provides DES, and together with Base64, you should be able to recreate PHP's crypt function. OTOH, unless you really need the exact same behaviour, you might just as well take anything else the library offers.
greetz
back2dos
Don't think you'll find an exact analog. crypt() as exists in PHP is an artifact of its Unix heritage, and is usually just a wrapper around the base C library. It won't even behave identically between operating systems.
What you should do is define your password hashing practice clearly (e.g. SHA256 with 8 bytes of salt or something), and run it through a library providing the appropriate algorithm.
Google for com.adobe.crypto (pretty sure it's part of the as3corelib project), it has several cryptographic hash functions.
You can accomplish this same thing in Java as well (and probably better and faster), though I don't know any particular libraries off the top of my head, not having dealt much with Java.
Incidentally, you should probably read through these articles before going much further:
http://en.wikipedia.org/wiki/Cryptographic_hash_function
http://en.wikipedia.org/wiki/Crypt_(Unix)
http://en.wikipedia.org/wiki/Salt_(cryptography)