RSAセキュリティとNTTデータ、ケータイ版SecurIDの販売開始
RSAセキュリティとNTTデータは、ワンタイムパスワード製品「RSA SecurID」の携帯電話版を開発し、4月25日より販売を開始する。 RSAセキュリティとNTTデータは、ワンタイムパスワード製品「RSA SecurID」の携帯電話版を開発し、4月25日より販売を開始する。両社は2006年1月に、携帯版SecuIDを共同で開発、製品化することを発表していた。 RSA SecurIDは、60秒ごとに予測不可能なパスワードを生成することにより、本人認証の強度を高める製品。仮にパスワードを盗聴されたとしても、その再利用は不可能だ。生体認証に比べ導入コストが低い点もメリットだ。 これまでRSA SecurIDは、小型のハードウェアトークンの形で提供されるケースが多かった。これに対し携帯電話版では、携帯電話上で動作するアプリケーションとしてRSA SecurIDの機能が提供される。普段持ち歩いて
Sender ID：送信者側の設定作業 ― ＠IT
送信ドメイン認証は、Yahoo!やGmailで「DomainKeys」が、Hotmailで「Sender ID」が利用されているほか、多くのISPが対応を表明したことにより一段と普及が進んでいる。すでに米国などでは、送信ドメイン認証に対応しているドメインからのメールを優遇して通すなど、利用することのメリット、また利用しない場合のデメリットなどが現れてきている。 本稿では2回にわたって、IPアドレスベースの認証方式に分類される「SPF（Classic SPF）」およびSender IDについて解説する。前編では、SPFおよびSender IDを導入するに当たって、実際にどのように手を動かせばいいのかについて説明したい。 IPアドレスベースの送信ドメイン認証 まず、IPアドレスベースの送信ドメイン認証について説明する（図1）。送信側は、「Sender Policy Framework（SPF）
Sender ID：受信者側の設定作業
前回は送信側でのSender IDの設定を説明した。Sender IDのようなIPアドレスベースの認証方式においては、送信側はDNSへのSPFレコードの公開だけで運用が開始できるので作業は比較的簡単だといえる。 一方、受信側での作業は少し手間がかかる。実際にSPFレコードを読み出し、送信元サーバのIPアドレスを検査するプログラムを追加する必要があるのだ。今回は受信側での設定について説明する。 Sender IDの受信側での処理 Sender IDの受信側では、認証するときに受信する、あるいはしつつある「送信ドメイン」を特定する。送信ドメインとは、Classic SPFであればSMTP通信のMAIL FROM:コマンドの引数に与えられるアドレスのドメイン部分であり、Sender IDではFrom:やSender:、Resent-From:やResent-Senderなどのメールヘッダに指定さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
