Question

I would like to store sensitive user information in an object which would be saved as a file on the server (rather than in a database).

The user’s password or other key would be used to generate an encryption key.

The data object would be loaded from the server whenever the user logs in and provides the correct key, it would be then stored in the Session. All of this would happen other SSL.

I am not familiar with serialization but I would imagine it would work something like this.

function loadData($id, $key)
{
    //open file from storage
    $fh = fopen("data/" . $id);
    $obj = fh->read //not sure what the read function would be....
    $obj = decrypt($obj, $key) // some sort of decryption function using openssl_decrpt
    $obj = unserialize($obj
    if ($obj != null) //if successful...
    {
        session_start();
        $_SESSION['data'] = $obj;

        return true;
    }

    return false;
}

function saveData($id, $key)
{
    //open file from storage
    $fh = fopen("data/" . $id);
    $obj = serialize($_SESSION(["data"]);
    $obj = encrypt($obj, $key);
    $obj = serialize($obj

    if ($obj != null) //if successful...
    {
        fh->write($obj) //not sure what the write function would be....

        return true;
    }

    return false;
}

Also, would this be this method be secure?

Answer 1

The weak point is your server. If someone has access to your server, he/she can:

1. Run a dictionary attack on the encrypted object (which can be very effective if the key is a short password).
2. Attach to your server process during request handling and get the decrypted object (or the key) from memory.

To mitigate the first problem you should use salt, but there is really not a lot you can do about the second problem- just make sure your server is not compromised…

(Note that running a dictionary attack is much simpler than reverse engineering a process and requires fewer permissions. So, depending on your use-case, it may be reasonable to ignore the second problem)