いくつかのメソッドをクライアントに公開するために作成した WebService プロジェクトがあります (具体的には、クライアントがメソッドの 1 つを呼び出した場合、サーバー上でイベントがトリガーされます)。これを独自の C# プロジェクトで呼び出すことができます (一部のクライアントはは Web フォーム アプリを実行しており、一部は内部サイトで実行しています)。
メソッドの性質上、パラメーターの 1 つはクライアントが誰であるかを識別する文字列です (適切なイベントをトリガーできるようにするため)。有効な識別子の 1 つに。
このようなものを虐待から守る標準的な方法は何ですか? 私が見つけたチュートリアルのほとんどは、それらを安全に保つことについて何も言及していないようです. ありがとう！
ダニエル・ヴァサロは正しいです。X509 証明書を使用して、サービスを呼び出している人物が正当であることを確認する必要があります。ただし、これはソリューションの複雑さを大幅に高めます。Microsoft WSE と、おそらく購入したサード パーティ製コンポーネントを使用する必要があります。
それがなければ、渡されたユーザー名とパスワードを使用できます。ただし、日付、時刻などに基づいて情報をハッシュするための共有アルゴリズムが必要になります。ハッシュがないと、ハッキングにさらされる可能性が高くなります。ないより。SSL を使用しても、最終的には辞書攻撃が侵入する可能性があります。
WS-Securityプロトコルを確認することをお勧めします。
このプロトコルには、Webサービスメッセージングに整合性と機密性を適用する方法に関する仕様が含まれています。
プロトコルの一部として、乱数をクライアントに送信できます。次に、クライアントは識別子をその乱数でソルトし、組み合わせた値をハッシュします。その組み合わせた値をサーバーに返すことができます。
次に、サーバーは同じ ID+Number ハッシュを計算し、2 つの値を検証します。
これは事実上パスワードです...ただし、1つのフィールドにユーザー名とパスワードがありません。
ユーザー名とパスワードを 1 つのフィールドに結合してはならないという技術的な理由はありませんが、慣例により、追加の秘密鍵がない場合は 2 つのフィールドになります。
これには、次の 3 つのビジネス上の理由があります。
アカウント ID は、ユーザー ID (ユーザー名?!) を知っている必要があるがパスワードを持っていない人々の間で明確に議論できます。
アクセス プロトコルが従来型である場合、判例法が適用される可能性が高くなり、状況が明確になる可能性が高くなるため、これが必要になった場合に不正アクセスを証明するのが法律上最も簡単です (そして、より小さな訴訟費用につながる可能性があります! ）。商用システムのパブリック ネットワーク上でユーザー名を持たないことは前代未聞ではなく、一部のシステムでは良い考えです (しかし、一般的には単純にそうではありません... 良い考えではありません)。
一般的なセキュリティおよび特定のプロセスにおけるベスト プラクティスに関するガイドラインでは、可能な場合は複合フィールドではなく、ユーザー名とパスワードを使用することを前提としています。コンセンサスポリシーを策定するのが難しくなる可能性があります。
パスワード (または、ユーザー名とパスワードを組み合わせた文字列を使用する場合はパスワード部分) は、変更ポリシー、非開示、複雑さ、および長さに関するセキュリティに関する通常のすべての推奨事項の対象となります。SSL と WS-Security も使用することをお勧めします。これは、セキュリティ領域で可能な限り慣習的であるようにするためです。おそらく、ネットワーク上での暗号化が必要です。
編集
SSLではなくTLSを書くつもりでした。
編集
申し訳ありませんが、TLS または WS-Security のいずれかを意味していました。