Strong Strings

StrongStrings are hardened string objects for handling sensitive data, such as passwords, ciphered data fields, deciphered data fields and finally StrongStrings are re-used heavily in our application programming to support cryptographic operations and their secrecy.

undefined

How does it work?

StrongStrings extend the string object in PHP, and provides memory walling techniques against process dumps displaying the protected information, or a connected debugger process attempting to view the innards of PHP processes.

To accomplish this task, StrongStrings will :

  1. Assign a no-execute memory space for variable holding
  2. override the __debugInfo() object method to block against dumping
  3. override the __destruct() object method to sanitize the memory space (memzeroing with libsodium or overwriting with random data when libsodium is not available.)
  4. override the __toString() method to avoid returning information to the caller unless we've activated this feature within the class's internal parameters. (De-activating inline data returns has the side-effect of blocking programmers from using if ( myvalue == StrongString ), instead one must retrieve the StrongString's value using its getString() method, and compare that value. ) (see note1)

  5. implement a getString() method for safely returning the stored value

  6. implement a safeStrcpy(), safeStrlen(), safeSubstr() and xorStrings() methods which allows for truncating and safely importing/exporting and Xorring values without generating processor data side-leaks.

Developer notes; using StrongStrings when inline access is denied categorically in a system requires a bit more rational thinking and sometimes circumventions. The theory though is that if you're relying on StrongStrings to store data that should be marked with such a protection, then chances are you shouldn't access them in inline fashion in the first place. Passwords that get stored in StrongStrings should NEVER be compared within an if (submittedPassword === storedPassword), since passwords are typically Argon Hash computation derived from the original password. In this case the submittedPassword should be compared to the storedPassword using either the PHP built-in Password_Hash comparison routines, or the one we supply in our Crypto classes, such as CORE\SodiumCrypto\Password_Match() method or CORE\Session\Password_Match() (which is really a proxy to the current cryptographic module's Password_Match() ).

Another scenario for using StrongStrings is for storing sensitive information like submitted email addresses, web submitted public keys (or private keys!), credit card numbers and so on. Again, in most of these scenarios the data is and should never be compared to other variables really. It's just better security theory if one is NOT depending on such sensitive fields for keying material in a database, prefer to rely on Hashes of such variables, if you really need to. (See the QueryDB->Field_Digest() method which provides a safe Hashing algorithm for data storage and indexing).

How to use StrongStrings

Normally you should initialize your StrongString objects as soon as possible, to the closest you can to the data source. If capturing web input in the form of a login credential for example, you should check if the $_REQUEST[param] exists, and if yes, immediately initialize your StrongString using it's value; as in 

$myparam = new \CORE\StrongString($_REQUEST["param"]);

All of our cryptographic methods impose the use of properly declared StrongString objects for parameter inputs, when logic dictates it. So you never have to worry about converting StrongStrings to their text equivalents, most of the subroutines already do it for you.

Late developer note; you might want to filter & parse your _REQUEST input before initializing the StrongString object with the value, for example; 

$myparam = new \CORE\StrongString(\CORE\Session::filter_Param($_REQUEST["param"]) );

Reading values stored in StrongStrings: 

$value = $myparam->getString();

That's all there is to using StrongStrings. :) In their most basic form.

How not to use StrongStrings

Say if you were to dump your listing of client emails using StrongStrings into a public web page. Then your use of StrongString would pretty much defeat the purpose of keeping Personally Identifiable Information "private". At this moment in time, our StrongString objects don't attempt to detect such situations, and don't detect either the final use or environment where they are used. One day perhaps we'll revise and extend this class object to make it possible to move StrongStrings between the client environment and the server environment (between PHP and JS effectively) while maintaining the StrongString hardened nature in both environments. We see this as a possibility using encryption on the client-side and one-time-use decryption keys retrieved from the server in parallel requests. We have a chapter coming up on this subject under our BlackCipherBox R&D.