FraudRecord is a service that helps companies share their experiences about unpleasant clients. To do that, we need some sort of access to sensitive client information, which should never be made public, even through accidents or intrusions. So we developed a system that uses one-way encryption to securely store client information.
One-Way Encryption, or Hash Functions, are mathematical algorithms that create a digital signature of a given piece of information, in our case, client information like names, email and IP addresses, domain names. Due to their nature, these algorithms create outputs that cannot be reversed to access the original information.
We never accept unsecured client information, we only accept the hashed outputs of client information. Our database only stored the encrypted version, which cannot be reversed back to the original, even by us. We utilize a salted SHA-1 algorithm, iterated 32,000 times. Here is a pseudo-code of the function that needs to be used:
FUNCTION fraudrecord_hash ( value ) FOR 32,000 TIMES LOOP value = "fraudrecord-" + value value = SHA-1( value ) END LOOP RETURN value END FUNCTION
This function adds 15-bits of extra security on top of SHA-1 against brute-force attacks, and since it is salted at each iteration with our custom string, it is safe against all existing rainbow tables. Any existing vulnerability of the popular SHA-1 function won't apply in this case, since our system deals with known-input cases, and generating collisions is of no importance.
Our system only accepts hashed versions of the client information. Here is an example client:
Name: John Smith Email: email@example.com Secondary Email: firstname.lastname@example.org Registration IP: 22.214.171.124 Cell Phone: +1 000 111 22 33 Landline: +1 555 123 45 67 Domain: www.example.com
Before sending this information to us, any billing system integration runs one-way encryption algorithms on the values, so we receive these, and only these:
name = ac2c739924bf5d4d9bf5875dc70274fef0fe54cf email = 34efd0a968b48cbf9a43ac3e73053e4f343234e4 email2 = 2a1ab4a6ed14713d0e26127c1920417e4b193924 ip = f25c0306279af0bd9faf1caf0549daedb3472b7f phone1 = 3f09086d8d4e4019eb534ce28e6b64c8ef563ec9 phone2 = d542e4bad3dbb13bcf0e31f484394997cd969b18 domain = ff07748b4d4b8f08f21499e078ef792fded46641
Since we only have these values stored in our database, any other company who wants to access to our reports about a client must also have the actual values of the information on file. They can run that information through our one-way encryption algorithm, and generate the encrypted values. Then we try to match the two encrypted values, and if we find a match in our database, we generate a report.
We never have access to the actual client information. We only accept the final result of the encryption, not the sensitive source information. If all guidelines are followed by our users, unsecured and sensitive client information never reaches our servers, and we have no way of storing or using unsecured information. Current industry standards and professional opinions of the experts in the field of data security all agree that an iterated and prefixed SHA-1 hash system is a one-way encryption, and there is no way to retrieve actual client information from a hashed result.
We also implemented 256 bit SSL protection to all our access routes, so that any information submitted to us are secured against man-in-the-middle attacks.