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

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.

Hash Examples

Our system only accepts hashed versions of the client information. Here is an example client:

					
	Name: 			John Smith
	Email: 			john.smith@example.com
	Secondary Email:	jsmith@example.net
	Registration IP: 	11.22.33.44
	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.

SSL Encryption

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.