Information on Data Security

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 by accident 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, that is client information such as names, email and IP addresses, or domain names. Due to their nature, these algorithms create outputs that cannot be reversed to access the original information.

We never require unsecured client information, we only need the hashed version of client information. Our database only stores 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 when submitting or querying client information:


    FUNCTION fraudrecord_hash ( value )

        value = LOWERCASE( value )
        value = REPLACE( value, ' ' => '' )
        value = TRIM( 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 vulnerabilities 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 of client data before hashing:


        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
        Address:            123 Example Street, Example City, EX 12345

        Reason:             Fraudulent activity
        Severity:           7 out of 10
        Description:        Client has conducted fraudulent activity, chargebacks and false claims.

Any billing system integration must convert the data values to a lowercase raw data with spaces removed, to standardize processing:


        name    = johnsmith
        email   = john.smith@example.com
        email2  = jsmith@example.net
        ip      = 11.22.33.44
        phone1  = +10001112233
        phone2  = +15551234567
        domain  = www.example.com
        address = 123examplestreet,examplecity,ex12345

Before sending this information to us, any billing system integration runs the one-way hash algorithm on the values, so we receive these, and only these values in a report:


        name    = ac2c739924bf5d4d9bf5875dc70274fef0fe54cf
        email   = 34efd0a968b48cbf9a43ac3e73053e4f343234e4
        email2  = 2a1ab4a6ed14713d0e26127c1920417e4b193924
        ip      = f25c0306279af0bd9faf1caf0549daedb3472b7f
        phone1  = 3f09086d8d4e4019eb534ce28e6b64c8ef563ec9
        phone2  = d542e4bad3dbb13bcf0e31f484394997cd969b18
        domain  = ff07748b4d4b8f08f21499e078ef792fded46641
        address = 4b7ae31360c7a1eaa7e9aec748a7f1876b598808

        Reason      = Fraudulent activity
        Severity    = 7
        Description = Client has conducted fraudulent activity, chargebacks and false claims.

In fact, our API won't even accept any data field that is not a hexadecimal string of 40 characters, which is the length of a SHA-1 hash. This way, we ensure that no plaintext data is ever sent to us, and we only store the encrypted versions of the data.

Data Matching in Queries

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.

Anyone without the precisely same client data for a field will not be able to match the report, even if they have a similar client. For example, if you submit a report for "John Smith", neither "John" nor "Smith" can match the report alone. Only the exact match of the full name will return the report.

Reports can be matched by any of the fields, such as name, email, IP address, phone number, or domain name. Even if one of the fields match, the report will be returned in the query results, and the result page will show exactly which fields have matched.

Fraud Watches and Personal Data Monitors

The same one-way encryption algorithm is used for fraud watches and personal data monitors as well. When you create a monitor or a watch, you can choose to submit encrypted versions, or let us encrypt the plaintext in our dashboard. The system will encrypt the data using the same algorithm and monitor the hashed value against the reports containing the same hashed value.

Web Interface and API

Our API and billing integrations are designed to work with the encrypted values only. The client data is encrypted on your end before sending it to us, and we never see the original data.

Our web interface allows you to submit reports and query the database using plaintext data, but it automatically hashes the data before storing it in our database. We purge the logs of the original data immediately after encryption, so we never have access to the plaintext data later. This applies to every piece of information in reports, queries, fraud watches, and personal data monitors.

See sample reports Learn more about how everything works

FraudRecord Service

Features