- PR -

パスワードの暗号化の方法について

1
投稿者投稿内容
POTETO
常連さん
会議室デビュー日: 2003/10/06
投稿数: 41
投稿日時: 2003-11-03 01:07
はじめまして。POTETOと申します。
WebシステムでユーザーIDとパスワードをDBに持ち、ログイン画面で
ユーザーIDとパスワードを入力させたいのですが、
パスワードに関して２つ質問があります。
①パスワードをDBに格納するときは平文ではなく暗号化するのが一般的？
②暗号化すべきならパスワードを暗号化する手法は何が良いでしょか？
言語はJAVAで作ります。MD5ハッシュ関数(メッセージダイジェストを作るという点では、
暗号化とは言わないかもしれませんが。)などが一般的なのでしょうか？
セキュリティー関連の知識が乏しいものでどなたか御教授ください。
Gordie
ベテラン
会議室デビュー日: 2003/10/14
投稿数: 64
投稿日時: 2003-11-03 02:05
どうもはじめまして。

まず、DBに格納するときのお話ですが、残念ながら平文のまま格納する例のほうが多いように思います。でもセキュリティ面を考えると是非にも暗号化するべきでしょうね。
手法はMD5でいいと思います。私が以前いたプロジェクトでもMD5使ってましたよ。ただ、そのプロジェクトではちょっと変わったことをしてました。SQL Server 2000を使っていたんですが、認証ロジックをDB側に持たせていたんです。Visual C++で書いた拡張ストアドプロシージャという形で。
平文のIDとパスワードを引数に渡して拡張ストアドプロシージャをコールすると、認証に成功した場合は登録情報を取得でき、失敗するとnullが返ってくるというシロモノでした。

Webアプリの場合、(Appletとかを使わない限り)、ブラウザから送信されたパスワードは平文のままネットワーク上を流れますので、DB側のセキュリティだけでなく、こちらのほうも気をつけないといけません。たとえばSSL化するとか。

追記：なるべくなら丸つき数字等は使わないようにお願いします。Macで見たりすると化けますので。
　　　(私の環境だと、Web上の丸つき数字は黒い菱形の中に？の文字、メールの丸つき数字は(月)、(火)、・・に化けます。)


[ メッセージ編集済み 編集者: Gordie 編集日時 2003-11-03 02:10 ]
POTETO
常連さん
会議室デビュー日: 2003/10/06
投稿数: 41
投稿日時: 2003-11-03 04:42
Gordieさん、返信ありがとうございます。

引用:

まず、DBに格納するときのお話ですが、残念ながら平文のまま格納する例のほうが多いように思います。

「暗号化する必要あんの？」ってな感じで反論を受けていたもので。やっぱり平文で格納するケースが多いんですね。UNIXのパスワードなんかのイメージでいたので、暗号化は必須だと思っていました。

引用:

手法はMD5でいいと思います。私が以前いたプロジェクトでもMD5使ってましたよ。

参考にさせていただきます。Javaだとcryptoパッケージが用意されていて、ハッシュ関数をDESやMD5などが指定できるので何がいいのか迷っていたところです。

引用:

Webアプリの場合、(Appletとかを使わない限り)、ブラウザから送信されたパスワードは平文のままネットワーク上を流れますので、DB側のセキュリティだけでなく、こちらのほうも気をつけないといけません。たとえばSSL化するとか。

今回のシステムではSSLを考えています。

引用:

追記：なるべくなら丸つき数字等は使わないようにお願いします。Macで見たりすると化けますので。

特殊文字は以後気をつけます。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-11-03 10:12
unibon です。こんにちわ。

＃セキュリティのことはあまり良くはわかりませんが。

引用:

POTETOさんの書き込み (2003-11-03 04:42) より:
引用:

Webアプリの場合、(Appletとかを使わない限り)、ブラウザから送信されたパスワードは平文のままネットワーク上を流れますので、DB側のセキュリティだけでなく、こちらのほうも気をつけないといけません。たとえばSSL化するとか。

今回のシステムではSSLを考えています。

ちなみに Java で一方向ハッシュの利用は非常に簡単にできます。
http://www.google.co.jp/search?hl=ja&q=java%2Esecurity+MessageDigest+getInstance

なお、Web アプリケーション等において、一方向ハッシュを使いたい場面としては主に、
(1) DB に格納する際のハッシュ化
と、
(2) サーバ・クライアント間の通信の際のハッシュ化
の2つの場面がありますが、これらは一方向ハッシュの原理上、
両方同時にはできないという制約があることに注意する必要があります。

もし、上記の(1)でハッシュ化をやってしまうと、(2)でハッシュ化できないので、(2)では
おっしゃるように SSL などを使う必要がでてきます。
逆に、もし、上記の(2)でハッシュ化をやるならば、(1)ではプレーンなパスワードを
保管せざるをえません。

結局、上記(1)をやると、メモリ上や通信経路上でプレーンなパスワードが一時的に流れますし、
その一方で、上記(2)をやると、DB(のディスク上)にプレーンなパスワードが永続的に保管されますし、
考えようによっては、どっちもどっち(さほど違いはない)とも言えます。
突飛な考えかもしれませんが、
前者を SSL との併用で解決するのなら、後者も DB の暗号化との併用も検討したほうが、
公平で良いと思います。


＃以下、あとで追加。
上記中、末尾の「DB の暗号化との併用」とは、たまたま見つけた一例にすぎませんが、
http://www.oracle.co.jp/9i/fact/security.html
のようなことを指します。

[ メッセージ編集済み 編集者: unibon 編集日時 2003-11-03 10:17 ]
MM
会議室デビュー日: 2003/06/07
投稿数: 9
投稿日時: 2003-11-04 06:10
unibonさんの書き込み (2003-11-03 10:12) より:
> なお、Web アプリケーション等において、一方向ハッシュを使いたい場面としては主に、
> (1) DB に格納する際のハッシュ化
> と、
> (2) サーバ・クライアント間の通信の際のハッシュ化
> の2つの場面がありますが、これらは一方向ハッシュの原理上、
> 両方同時にはできないという制約があることに注意する必要があります。
・・・
> 逆に、もし、上記の(2)でハッシュ化をやるならば、(1)ではプレーンなパスワードを
> 保管せざるをえません。

同時にできないことはないと思いますよ。
認証時に DB に格納されているデータがハッシュ化されていることをクライアントも
想定しておけば（つまり入力されたパスワードのダイジェストを得てから、以降の作業を行う）
何ら問題ないはずです。


unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-11-04 10:11
unibon です。こんにちわ。

引用:

MMさんの書き込み (2003-11-04 06:10) より:
unibonさんの書き込み (2003-11-03 10:12) より:
> なお、Web アプリケーション等において、一方向ハッシュを使いたい場面としては主に、
> (1) DB に格納する際のハッシュ化
> と、
> (2) サーバ・クライアント間の通信の際のハッシュ化
> の2つの場面がありますが、これらは一方向ハッシュの原理上、
> 両方同時にはできないという制約があることに注意する必要があります。
・・・
> 逆に、もし、上記の(2)でハッシュ化をやるならば、(1)ではプレーンなパスワードを
> 保管せざるをえません。

同時にできないことはないと思いますよ。
認証時に DB に格納されているデータがハッシュ化されていることをクライアントも
想定しておけば（つまり入力されたパスワードのダイジェストを得てから、以降の作業を行う）
何ら問題ないはずです。

すみません。前提条件を書くのを飛ばしていました。
DB にプレーンの文字列がなくハッシュの文字列しかないと、
通信時にチャレンジ&レスポンス方式でハッシュすることができないということです。
通信時に DB に入っているハッシュの文字列を
そのまま(変な言い方ですがハッシュをプレーンで)送っても良いですが、
それだと無意味なので。

投稿の意図としては、パスワードを加工してしまうと、
あとから使える手法の自由度が減ってしまうので、
たしかにパスワードをハッシュして保持するのは枯れた手法ではあるものの、
それ以外に、一応 DBMS のレベルでの暗号化も検討の余地があります
(その場合はパスワードはプレーンで保持する)、
ということです。
＃SSL を使うということが背景にあるのならば、あまり固執してもしかたないのですが。
MM
会議室デビュー日: 2003/06/07
投稿数: 9
投稿日時: 2003-11-04 12:27
引用:

unibonさんの書き込み (2003-11-04 10:11) より:
すみません。前提条件を書くのを飛ばしていました。
DB にプレーンの文字列がなくハッシュの文字列しかないと、
通信時にチャレンジ&レスポンス方式でハッシュすることができないということです。
通信時に DB に入っているハッシュの文字列を
そのまま(変な言い方ですがハッシュをプレーンで)送っても良いですが、
それだと無意味なので。


クライアント側のソフトをブラウザにしてしまうとその通りなんですが、クライアント
側でパスワードを入力した際に、MD5 や SHA でハッシュを算出して、そのデータを
元ネタにしてチャレンジ＆レスポンスを行うようにすると、サーバ側DBはハッシュ化
されたデータを格納でき、かつ、ネットワーク上を流れるデータは「チャレンジ＆レス
ポンス加工（ハッシュ加工（入力データイメージ））」の形態になりますよね。
と、ここまで書いて気付いたのですが、こうやって頑張っても、DB 内のハッシュ化さ
れたデータを盗まれ、クライアント側認証処理の一部をスキップするようなソフトウェ
ア改竄がなされたら無意味ですね。 ^^;

引用:

＃SSL を使うということが背景にあるのならば、あまり固執してもしかたないのですが。


実際問題、DB のハッシュ化＋BASIC認証と SSL の併用が最も安全確実なやり方かもしれません。
CLIENT-CERT 認証も捨てがたいけど。 ^^;
POTETO
常連さん
会議室デビュー日: 2003/10/06
投稿数: 41
投稿日時: 2003-11-04 13:09
POTETOです。こんにちは。
セキュリティーっていろいろ難しいですね。今回はクライアントはブラウザ(Applet無し)の予定なので、通信路はSSLを用います。
皆さんのレスで私の知識不足で一部ついて行けなかったのですが、
Gordieさん、unibonさん、MMさんの投稿を元にもっと勉強しようと思います。
ありがとうございました。
1

スキルアップ／キャリアアップ（JOB@IT）