6

私が理解していることから、ServiceStack の認証を使用する場合、通常はセッションの開始時に認証し、サーバー側のセッションを認証済みとしてマークします。後続の Web サービス要求はそのセッション ID を使用するため、再認証は必要ありません。（これまでのところ間違っている場合は修正してください）。

新しいセッション ID の生成は、 SessionExtensions.csのGuid.NewGuid() を使用して実行されますが、これは暗号学的に幻想的な値を生成しません。RNGCryptoServiceProviderを使用するなど、暗号的に安全な値を使用するように切り替えない理由はありますか?

アップデート：

実際、もう少し考えてみると、ASP.NET はセッション ID を使用してリクエスターが認証されていることを確認しません。これは、マシン キーで暗号化され、ハッシュされた FormsAuthenticationTicket を使用します ( ASP.NET 2.0 のプロセスの説明はこちら)。

私はセキュリティの専門家ではないので、ASP.NET Forms Auth によって提供されるセキュリティのレベルとランダム値によって提供されるセキュリティのレベルを比較した場合、これがどのような意味を持つのかわかりません。それはすべてキーとデータの長さに帰着すると思います...しかし、フォーム認証でブルートフォース攻撃を仕掛けるのに必要な時間は、乱数のヒープ全体を試すだけでなく、おそらくはるかに長くなりますか?

4

1 に答える 1

7

適切なServiceStackは、認証 + セッション Cookie の設定という標準的な HTTP アプローチを使用して、後続のリクエストに対して認証済みセッションをセットアップします。これは、すべての Web フレームワークで共通のアプローチです。

GUID を予測してリバース エンジニアリングできるという .NET の脆弱性については聞いたことがありませんが、 ASP.NET 自体の SessionId は Guid ほど強力ではないようです (エントロピーの 2^120 対 2^128 ビット)。 ）。しかし、完全にランダムではないため、次のリリースでは完全にランダムな識別子を使用するように ServiceStack の実装を変更します。

于 2013-02-18T22:25:34.870 に答える