A requirement for the deployment of a PHP application I am working on is that is uses FIPS-140 validated cryptographic modules.
The customer has specifically flagged up that "PHP utilizes a cryptographically weak random number generator to produce session ID information" and cited this report: http://berlin.ccc.de/~andreas/php-entropy-advisory.txt
I have advised them on how to set session.entropy_length and session.hash_function to increase entropy, but they have not accepted this, specifically requiring that we use a FIPS-140 compliant RNG.
I'm not certain on the difference between the hash function and the RNG, so am struggling to respond. Can anyone suggest a way of using a FIPS-140 compliant function to generate session ids within php?
We're running PHP 5.4.16 on Windows + SQL Server, in case it matters.
Thanks
A requirement for the deployment of a PHP application I am working on is that is uses FIPS-140 validated cryptographic modules.
My condolences. A headache is to FIPS-140 what a drop of morning dew is to the ocean.
I'm not certain on the difference between the hash function and the RNG, so am struggling to respond. Can anyone suggest a way of using a FIPS-140 compliant function to generate session ids within php?
If you're using ext/mcrypt, mcrypt_create_iv() uses Windows' CryptGenRandom API which should be FIPS-140 compliant. (Or, at minumum, it should be possible to setup that way.) That function is the only good thing about mcrypt, and exists separatef from libmcrypt.
If you're using OpenSSL, and compiled OpenSSL in FIPS mode, you can similarly use openssl_random_pseudo_bytes() and it should use a FIPS-compliant generator.
Finally, if you upgrade to PHP 7+ and use random_bytes(), so long as Windows is FIPS-140 compliant, you're golden.
The hash function really doesn't matter here. You want to use a secure source and that's it. Hashing it doesn't buy you anything. If you're forced to use a hash function, use one of the SHA2 family hash functions (SHA256, SHA384, or SHA512) approved for use in FIPS-140 compliant software.
Session Generator that should pass FIPS-140 audits
<?php
/**
* #return string
*/
function session_id_fips140()
{
if (is_callable('random_bytes')) {
return session_id(bin2hex(random_bytes(32)));
}
if (is_callable('mcrypt_create_iv')) {
return session_id(bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)));
}
if (is_callable('openssl_random_pseudo_bytes')) {
return session_id(bin2hex(openssl_random_pseudo_bytes(32)));
}
// Fail closed. Maybe install random_compat?
throw new Exception("No suitable PRNG is available on the current system!");
}
Usage:
<?php
ini_set('session.
if (!isset($_COOKIE['PHPSESSID'])) {
session_id_fips140();
}
session_start();
Related
I'm working on implementing JWT verification in a client-side web-application that's using Webpack5. When a user is created on the backend running PHP, I create a public and private keypair for use in JWT like this and store them:
$keyPair = sodium_crypto_sign_keypair();
$privateKey = base64_encode(sodium_crypto_sign_secretkey($keyPair));
$publicKey = base64_encode(sodium_crypto_sign_publickey($keyPair));
Then with firebase/php-jwt create the request like this:
$jwt = JWT::encode($payload, $privateKey, 'EdDSA');
However, using jose I get the following error when attempting to verify the JWT:
import * as jose from 'jose';
const { payload, protectedHeader } = await jose.jwtVerify(response.token, window.atob(response.key));
console.log(payload);
console.log(protectedHeader);
TypeError: Key must be of type CryptoKey.
I'm not understanding how it wants the key as both the base64 string and base64 presentation of the publicKey is met with the same TypeError in node. What am I doing wrong here?
Edwards-Curve Digital Signature Algorithm (EdDSA in JOSE) is not supported by WebCryptography API, as such you won't succeed with any library that uses native browser crypto. Sadly.
There's a proposal for Ed25519, Ed448, X25519, and X448 to be added in WebCrypto but it'll take a while before adoption and then implementation. When that happens jose will support this action. That being said you'll need to pass a CryptoKey. That's either imported via crypto.subtle.importKey directly, or via jose's import key functions. SubtleCrypto supports raw public key imports, jose supports PEM key imports in its wrappers only.
See Browser Support for the browser algorithm support matrix, as well as Algorithm Key Requirements for algorithm key requirements, and Type alias: KeyLike for how to obtain the right key representation.
As for the other (now deleted) suggestions, they do not take into account the algorithm you use, suggesting to use Uint8Array instead of a CryptoKey is wrong, Uint8Array use is exclusive for symmetric algorithms. Likewise, using transpiled jsonwebtoken is only remotely reliable for HMAC based algorithms.
jose only uses the runtime's native crypto layer which is your best bet at conformance and secure implementation but when running cross-runtimes you need the consider the intersection of supported algorithms on the platform.
I'm not understanding how it wants the key as both the base64 string and base64 presentation of the publicKey is met with the same TypeError in node
It's supposed to be KeyLike (interface) - in Node that's KeyObject (see crypto documentation), in Web-like environments it's CryptoKey (see WebCryptoAPI).
We are building application where we need to store a data encrypted in database and instead of using MySql AES_ENCRYPT and AES_DECRYPT we are plaining to use laravel's inbuilt encrypt & decrypt functions.
Is it will be future proof as we don't want to loose data for future updates.
First of all, nothing is truly "future proof." In fact, we're on the verge of current encryption being rendered obsolete by quantum computing, making all current encryption methods very much not future proof.
Does Taylor have any plans of changing it in the foreseeable future? Maybe, maybe not, but the only real way of knowing is to ask him directly. He's quite active on Twitter and in other venues, so as far as business owners go, he's pretty approachable. He's also a generally nice person, so don't be afraid to ping him.
But let's take a look at the code:
public function encrypt($value, $serialize = true)
{
$iv = random_bytes(16);
// First we will encrypt the value using OpenSSL. After this is encrypted we
// will proceed to calculating a MAC for the encrypted value so that this
// value can be verified later as not having been changed by the users.
$value = \openssl_encrypt(
$serialize ? serialize($value) : $value,
$this->cipher, $this->key, 0, $iv
);
if ($value === false) {
throw new EncryptException('Could not encrypt the data.');
}
// Once we get the encrypted value we'll go ahead and base64_encode the input
// vector and create the MAC for the encrypted value so we can then verify
// its authenticity. Then, we'll JSON the data into the "payload" array.
$mac = $this->hash($iv = base64_encode($iv), $value);
$json = json_encode(compact('iv', 'value', 'mac'));
if (! is_string($json)) {
throw new EncryptException('Could not encrypt the data.');
}
return base64_encode($json);
}
That's the main encrypt() function from master in the repository, and from the looks of it, it's not likely to be changed too much without completely rewriting it. And while Laravel doesn't really follow the SemVer versioning spec, it does generally follow an internally consistent versioning scheme, making the most likely times for it to change are at the whole number and first-decimal change (i.e. - 5.4 to 5.5 or 5.5 to 6.0).
However, it's worth noting that it's actually accessed via contracts and the service provider pattern (so the only time the class is actually directly referenced is in its associated ServiceProvider class). This means that you can use this one for now and if a breaking change is introduced in the future, you can copy this version into your own encryption class, replace the reference in config/app.php to Illuminate\Encryption\EncryptionServiceProvider to your new encryption service provider, and you've now preserved that method and can use it throughout your application, without making any other changes to your application.
On a bit of a side note, you can also consider writing an "encryption converter" if you find you do need to change algorithms (such as if your original algorithm is insecure) by using the old system's decrypt method to decrypt everything, then re-encrypt it all with the new system and storing it again. The application would then just use the new algorithm going forward.
I´m trying to use PHP Imagick´s getImageSignature method to compare different images and see if they are equal, but I´m getting different signature even with same image file when the method is called from different computers with different versions of ImageMagick and OS.
Should I always get the same signature in these conditions?
Thanks a lot.
Should I always get the same signature in these conditions?
Short answer is no.
The Imagick::getImageSignature wraps MagickGetImageSignature which generates a signature at run-time based virtual pixels in memory & Quantum colorspace. The latter being influenced by the configuration options at compile time, or environment parameters. Differences in versions, and host architecture will contribute to the variations of the image signature.
As the signature is just a SHA-256 digest, it would be simpler to generate one yourself.
$signature = sha1($image->getImageBlob());
// or subclass the method
class MyImagick extends Imagick {
public function getMyImageSignature() {
return sha1($this->getImageBlob());
}
}
I am trying to test the password_hash method for this purpose i have created the following function hashPassword:
function hashPassword($string) {
$settings = array('cost' => 10, 'encryption_key' => 'thisIsMyEncryptionKey1234');
return password_hash($string, PASSWORD_BCRYPT, $settings);
}
Now if i test this with a random string like "test"
The result would be:
$2y$10$thisIsMyEncryptionKeyu5n3NNnKh3DjgJqgb5pE8YOLBclKrVWC
Or if i test it with helloworld:
$2y$10$thisIsMyEncryptionKeyuVw8QRVNw8HbEWHX2oQlArVtne2TzOpS
Can anyone tell me why this is happening? Or is it suppose to be like this?
You should never provide the encryption key manually unless you have a very good reason to do so. I'd recommend reading the docs on password_hash some more.
Proper usage just lets the system figure it all out on its own:
function hashPassword($password)
{
return password_hash($password, PASSWORD_DEFAULT);
}
PHP will then internally choose the best available algorithm and most fitting number of iterations for current hardware, and generate a safe and unique salt.
To validate the password, then use password_verify, and check for required rehashes, for example in a User class:
class User
{
...
public function verifyPassword($password)
{
if(!password_verify($password, $this->hash))
return false;
if(password_needs_rehash($this->hash, PASSWORD_DEFAULT))
$this->setNewHashAndSaveToDB(password_hash($password, PASSWORD_DEFAULT));
return true;
}
}
By using this construct, you ensure hashed passwords are always kept up to date and secure as hardware capacities progress, automatically when a user logs in.
The policy on what algorithm PASSWORD_DEFAULT chooses, and with which config, is as follows:
Updates to supported algorithms by this function (or changes to the
default one) must follow the follwoing rules:
Any new algorithm must be in core for at least 1 full release of PHP prior to becoming default. So if, for example, a new algorithm
is added in 5.5.5, it would not be eligible for default until 5.7
(since
5.6 would be the first full release). But if a different algorithm was added in 5.6.0, it would also be eligible for default at 5.7.0.
The default should only change on a full release (5.6.0, 6.0.0, etc) and not on a revision release. The only exception to this is
in an emergency when a critical security flaw is found in the
current default.
About Encryption key:
Best Encrуption kеy is a binary blob that's gеnеrated from a rеliablе random numbеr gеnеrator. Thе following еxample would bе rеcommеndеd (>= 5.3):
$keySize = mcrypt_get_key_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CFB);
$encryptionKey = openssl_random_pseudo_bytes($key_size, $strong); //$strong will be true if the key is crypto safe
But in your case you just set the string, use some random data for this.
I am building an iOS app for an already existing web application I created. The web app uses laravel and sentry to encrypt passwords. New users have to be able to be created from the iOS app.
The server that the web app talks to is written in php but does not use laravel or sentry.
The only sentry function I need is the one they use to encrypt passwords.
What function does sentry use to hash passwords? I am talking about Cartalyst\Sentry\Hashing\NativeHasher
I need to be able to duplicate this function and use it in a separate php file.
i've found this link : https://github.com/cartalyst/sentry/blob/master/src/Cartalyst/Sentry/Hashing/NativeHasher.php
and this code is what you want probably:
public function hash($string)
{
// Usually caused by an old PHP environment, see
// https://github.com/cartalyst/sentry/issues/98#issuecomment-12974603
// and https://github.com/ircmaxell/password_compat/issues/10
if (!function_exists('password_hash')) {
throw new \RuntimeException('The function password_hash() does not exist, your PHP environment is probably incompatible. Try running [vendor/ircmaxell/password-compat/version-test.php] to check compatibility or use an alternative hashing strategy.');
}
if (($hash = password_hash($string, PASSWORD_DEFAULT)) === false) {
throw new \RuntimeException('Error generating hash from string, your PHP environment is probably incompatible. Try running [vendor/ircmaxell/password-compat/version-test.php] to check compatibility or use an alternative hashing strategy.');
}
return $hash;
}