0

(データベースではなく) サーバー上にファイルとして保存されるオブジェクトに、機密性の高いユーザー情報を保存したいと考えています。

ユーザーのパスワードまたはその他のキーは、暗号化キーの生成に使用されます。

ユーザーがログインして正しいキーを提供するたびに、データオブジェクトがサーバーからロードされ、セッションに保存されます。これはすべて、他の SSL で発生します。

私はシリアライゼーションに慣れていませんが、このように機能すると思います。

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;
}

また、これはこの方法が安全でしょうか？

4

1 に答える 1

0

弱点はサーバーです。誰かがあなたのサーバーにアクセスできる場合、その人は次のことができます。

  1. 暗号化されたオブジェクトに対して辞書攻撃を実行します (キーが短いパスワードの場合、これは非常に効果的です)。
  2. リクエスト処理中にサーバー プロセスにアタッチし、復号化されたオブジェクト (またはキー) をメモリから取得します。

最初の問題を軽減するには、saltを使用する必要がありますが、2 番目の問題についてできることはあまりありません。サーバーが危険にさらされていないことを確認してください...

(辞書攻撃の実行は、プロセスのリバース エンジニアリングよりもはるかに簡単であり、必要なアクセス許可も少ないことに注意してください。したがって、ユース ケースによっては、2 番目の問題を無視するのが妥当な場合があります)。

于 2013-02-03T15:38:31.410 に答える