パスワードのセキュリティの検討　[システム開発研究室]: ゼロからはじめるシステム開発

<< 2024年04月 >>
日	月	火	水	木	金	土
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

2023年02月05日

パスワードのセキュリティの検討　[システム開発研究室]

　こんにちは！
　ナビゲータのEVEです。

　来週末ちょっと出かける用事ができましたので、スケジュールがあっぷあっぷの状態です。

[Prototype EVEを使ったシステム開発]
　機能設計については、昨日話したような感じで進めていくのですが、フレームワークの部分についてどうしようか検討しています。フレームワークは、初期バージョンを2004年に製造を開始し、その後セキュリティ機能を強化したバージョンを2009年にリリースしました。その当時はそれで十分だったのですが、現在では見劣りします。ただ、そのシステムを多くの人に利用してほしいと思っているので、セキュリティについては、強化したいと思います。

[Prototype EVEのセキュリティ]
　Prototype EVEでは、その当時危険と言われていた脅威については対応しています。パスワードについては、ハシュ化とか、乱数を付加しての再ハッシュ化するといった方法です。
　パスワードは、DBに格納する時点でハッシュ化されているので、DB管理者でもどんなパスワードを使用しているのか分かりません。そして、サーバーとクライアント間で通信する場合、その乱数を付加して再ハッシュ化しているので、もとのハッシュ値は分からないようにしています。
　ただ、乱数を付加しての再ハッシュ化なのですが、日をまたがないと乱数が更新されないので、1日で成功する攻撃の場合、無力となります。ハッシュ化されたパスワードによる通信でも、ず～っと同じものを使用していると、リプレイ攻撃が成功してしまうのです。ただ、今回は、SSL/TLSを導入したことにより、その可能性はかなり低くなりました。
　ただ、もう一工夫をしたいと思います。私がPrototype EVEへセキュリティを導入したときにあまりいわれていなかったソルト値の導入です。
　ソルト値は、多くのユーザーが使用しているパスワードを保護するのに役立ちます。

　先ほどハッシュ値の話をしましたが、ハッシュ値は、同じ文字列からは同じハッシュ値しか生成できません。つまり、多くのユーザが使用しているパスワード、例えば、「password」とか、「123456789」とかいったパスワードのハッシュ値は、多くの人が知っているのが現状です。そのため、Prototype EVEでは、ハッシュ化されたパスワードへ乱数を付加して再ハッシュ化したのですが、それも乱数は、Prototype EVEを使用している人なら同じ値のため、一人のユーザのパスワードがばれた時点で、多くのユーザのパスワードが露見する可能性があります。
　但し、ソルト値は、ユーザ個人に与えるモノなので、一人のユーザのパスワードが露見した影響は、すべてのユーザへ及ばないというメリットがあります。
　パスワード限定なのですが、現在は、そう、考えています。

[次期システム]
　次期システム、EVEシステムは、もっと、セキュリティが高いモノになる予定です。

　そして、以前ブログには以下の内容を目標に掲げています。2022年08月05日アップロードしたブログ(*1)には、

・システムはユーザの利益のために
・システムそのものがドキュメント
・全てをシステムで管理する
・1人でシステムを運用する
・すべての操作を一つの手順で

なんて、目標を立てています。今回の検討は、次期システムに活かしたいと思っています。Prototype EVEのシステム構成については、忘れている部分もありますしね(笑)。

　では、また！

*1)＜EVEシステムの目標＞
■プロローグ～EVE～　[YouTubeでの稼ぎ方研究室]
https://fanblogs.jp/bahamuteve/category_1/2

タグ：ハッシュ値リプレイ攻撃ソルト値