1.チャレンジ・レスポンス認証
情報処理安全確保支援士試験の過去問（H21SC秋午前Ⅱ問2）では、チャレンジ・レスポンス認証は、「利用者が入力したパスワードと、サーバから送られたランダムなデータとをクライアント側で演算し、その結果を認証用データに用いる」方式と述べています。
ネットワーク上を流れるレスポンスが毎回変わるので、リプレイアタックにも強い仕組みです。
パスワードが暗号化されるとともに、ワンタイムパスワードの役割も有する。また、ユーザ名とパスワード以外に必要な情報もない。つまり、事前に秘密鍵を共有したり証明書を準備する必要ない。よく考えられた認証方式だと思います。
なぜチャレンジレスポンス認証が必要なのか、
あまりよく分かりません。
ネットワークを介してパスワードを送信する場合、第三者による盗聴の恐れがあります。最近のWebシステムのように、SSL/TLSで暗号化されていれば安全ですが、そうでない場合もあります。そこで、無線LANのWEP方式やSMTP-AUTH、APOP、IMAPなどでは、チャレンジ・レスポンス認証という技術を利用しています。
利用者は毎回異なるパスワード（下図でいう”レスポンス”）をサーバに送ることになります。仮に第三者にこのパスワード（レスポンス）を盗聴されたとしても、パスワード（レスポンス）は1回限りのものですから、不正利用される心配がありません。
チャレンジ・レスポンス認証の、具体的な流れは以下です。
①利用者は、ユーザIDを送信する
②サーバは、チャレンジ（乱数）を生成する
③作成したチャレンジを利用者に送信する
④利用者は、チャレンジと保有するパスワードからレスポンスを作成する（※ハッシュ演算により暗号化している）
⑤サーバに対し、レスポンスを送信する
⑥サーバは、受け取ったレスポンスと自ら作成したレスポンスを比較する。両者が一致すれば、正規の利用者とみなされ、認証が成功する。
2.MAC（message authentication code）
メッセージ認証にて、メッセージが改ざんされていないかの確認に使われる。
過去問（H18秋SU午前問27）では、MACに関して、「送信者と受信者の共通鍵を元に，メッセージにハッシュ関数を適用して生成したもの」と述べられている。
ハッシュは、送信者と受信者での共通鍵で行います。
MACによるメッセージ認証（改ざんがされていないか）の流れを、次の図とともに説明します。
①送信者と受信者は、あらかじめ共通鍵を共有しておきます。
②送信者は、メッセージのハッシュ値であるMACを計算します。
③受信者に対して、メッセージだけでなく、MACも送ります。
④受信者は、受信したメッセージからMACを計算します。
⑤この値と受信したMACを比較します。両者が一致すれば、改ざんされていないことがわかります。 
過去問を見てみよう。
| 問48 送信者がメッセージからブロック暗号（方式）を用いて生成したメッセージ認証符号（MAC：message authentication code）をメッセージとともに送り，受信者が受け取ったメッセージからMACを生成して，送られてきたMACと一致することを確認するメッセージ認証で使用される鍵の組合せはどれか。 送信者 受信者 ア 受信者と共有している共通鍵 送信者と共有している共通鍵 イ 受信者の公開鍵 受信者の秘密鍵 ウ 送信者の公開鍵 受信者の秘密鍵 エ 送信者の秘密鍵 受信者の公開鍵 （H18年春SM午前） |
MACは共通鍵を使う。証明書を使わない。その分、簡単ではある。
一方、否認防止などはできない。
なぜ？
不正な第三者は、共通鍵を入手できないはず。
だから、送信者しかそのメッセージを作れないから、否認防止効果があるのでは？
メッセージの受信者はそのメッセージを作ることができる。ディジタル署名の場合は、送信者の秘密鍵で暗号化するため、送信者でしか作成できない。だから、否認防止が可能になる。
前置きが長くなったが、この問題の正解はアだ。
3.CAPTCHA（キャプチャ）
過去問（H26春AP午前問36）では「人間には読み取ることが可能でも，プログラムでは読み取ることが難しいという差異を利用して，ゆがめたり一部を隠したりした画像から文字を判読させ入力させることで，人間以外による自動入力を排除する技術」と述べられています。
私のサイトから、私へメッセージをお送りいただく場合も、以下のようなCAPTCHA画面が表示されます。
ツールよる不正は投稿を防ぐためです。
4.Oauth2.0
Oauth（Open Authorization）とは、複数のシステム（Webサービス）間で、APIを使ってアプリケーションを連携させる仕組みです。
言葉がオープンな（Open）な許可（Authorization）が意味するように、安全に連携させるアプリケーションを許可します。
一方のOpenIDの場合は、認証の許可だけになります。
情報処理安全確保支援士試験の過去問（H27秋SC午前2）を見てみましょう。
| 問17 OAuth 2.0において, WebサービスAの利用者Cが, WebサービスBにリソースDを所有している。利用者Cの承認の下, WebサービスAが，リソースDへの限定的なアクセス権限を取得するときのプロトコルOAuth 2.0の動作はどれか。 ア WebサービスAが，アクセストークンを発行する。 イ WebサービスAが，利用者Cのディジタル証明書をWebサービスBに送信する。 ウ WebサービスBが，アクセストークンを発行する。 エ WebサービスBが，利用者Cのディジタル証明書をWebサービスAに送信する。 |
正解はウです。以下に図にしてみました。
利用者は、WebサービスAを利用します。これは、知名度があまり高くないサービスとしましょう。このサービスには、マッシュアップとして、WebサービスBのリソースDが組み込まれています。リソースとは少し違いますが、SNSのコメント機能が組み込まれてることを思い浮かべてください。
このとき、利用者Cは、WebサービスAにユーザIDやパスワードを渡すのは危険だと考えるでしょう（下図①）。それに、WebサービスA側としても、余分な処理が増えます。そこで、Oauthを使い、APIとして連携します。利用者にはWebサービスBからのメッセージでログインをさせ（下図③）、WebサービスAにはトークンを払い出します（下図③）。トークンは、許可証みたいなものです。セキュリティの観点から、WebサービスA側には、利用者のIDやパスワード情報は渡しません。
こういう仕組みで、利用者Cは、WebサービスAのリソースDにアクセスができます（下図④）。
ちなみに、Oauth1.0はセキュリティ上の欠陥があり、Oauth2.0で改良されました。
以下のサイト、実際のOAuthを体験できるので、とても分かりやすいです。
https://contents.saitolab.org/oauth/
5.ベーシック認証とダイジェスト認証
認証にはBASIC認証(ベーシック認証）とDIGEST認証（ダイジェスト認証）があります。
前者はIDおよびパスワードがbase64で（暗号というか、）エンコードされて送られます。エンコードしているだけなので、平文のようなものです。後者は暗号化されます。なので、BASIC認証の場合、HTTPで通信する場合はパスワードが漏えいする危険があります。
DIGEST認証は、チャレンジレスポンス認証と同じやり方で通信を暗号化していると考えてください。つまり、チャレンジとレスポンスを交換して通信を暗号化します。
チャレンジレスポンス認証に関しては、以下に記載しています。