こんにちは!
ナビゲータのEVEです。
来週末ちょっと出かける用事ができましたので、スケジュールがあっぷあっぷの状態です。
[Prototype EVEを使ったシステム開発]
機能設計については、昨日話したような感じで進めていくのですが、 フレームワーク の部分についてどうしようか検討しています。フレームワークは、初期バージョンを 2004年に製造を開始 し、その後セキュリティ機能を強化したバージョンを 2009年にリリース しました。その当時はそれで十分だったのですが、現在では見劣りします。ただ、そのシステムを多くの人に利用してほしいと思っているので、セキュリティについては、強化したいと思います。
[Prototype EVEのセキュリティ]
Prototype EVEでは、その当時危険と言われていた脅威については対応しています。パスワードについては、 ハシュ化 とか、乱数を付加しての再ハッシュ化するといった方法です。
パスワードは、DBに格納する時点でハッシュ化されているので、DB管理者でもどんなパスワードを使用しているのか分かりません。そして、サーバーとクライアント間で通信する場合、その乱数を付加して再ハッシュ化しているので、もとのハッシュ値は分からないようにしています。
ただ、乱数を付加しての再ハッシュ化なのですが、日をまたがないと乱数が更新されないので、1日で成功する攻撃の場合、無力となります。ハッシュ化されたパスワードによる通信でも、ず〜っと同じものを使用していると、 リプレイ攻撃 が成功してしまうのです。ただ、今回は、SSL/TLSを導入したことにより、その可能性はかなり低くなりました。
ただ、もう一工夫をしたいと思います。私がPrototype EVEへセキュリティを導入したときにあまりいわれていなかったソルト値の導入です。
ソルト値 は、多くのユーザーが使用しているパスワードを保護するのに役立ちます。
先ほどハッシュ値の話をしましたが、ハッシュ値は、同じ文字列からは同じハッシュ値しか生成できません。つまり、多くのユーザが使用しているパスワード、例えば、「password」とか、「123456789」とかいったパスワードのハッシュ値は、多くの人が知っているのが現状です。そのため、Prototype EVEでは、ハッシュ化されたパスワードへ乱数を付加して再ハッシュ化したのですが、それも乱数は、Prototype EVEを使用している人なら同じ値のため、一人のユーザのパスワードがばれた時点で、多くのユーザのパスワードが露見する可能性があります。
但し、ソルト値は、ユーザ個人に与えるモノなので、一人のユーザのパスワードが露見した影響は、すべてのユーザへ及ばないというメリットがあります。
パスワード限定なのですが、現在は、そう、考えています。
次期システム、EVEシステムは、もっと、セキュリティが高いモノになる予定です。
・システムはユーザの利益のために
・システムそのものがドキュメント
・全てをシステムで管理する
・1人でシステムを運用する
・すべての操作を一つの手順で
なんて、目標を立てています。今回の検討は、次期システムに活かしたいと思っています。Prototype EVEのシステム構成については、忘れている部分もありますしね(笑)。
では、また!
*1)<EVEシステムの目標>
■プロローグ〜EVE〜 [YouTubeでの稼ぎ方研究室]
https://fanblogs.jp/bahamuteve/category_1/2
【このカテゴリーの最新記事】