ゼロからはじめるシステム開発

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

　引き続きバッチ処理システムの解析、バグ修正、バージョンアップをしています。やっぱり、問題となるのは、連想配列の部分・・・。Prototype EVEでは、連想配列を多用していて、いろいろなところでエラーが出るうえに、関数をまたぐエラーの場合、ちょっと、解析に時間がかかってしまいます。

[Prototype EVEのセキュリティ的な問題]
　バッチ処理システムだけでなく、それ以外のシステムも、Prototype EVEを利用することになりそうです。ただ、セキュリティ的に何点か問題があります。

　まず、1つ目は、Salt値をシステム共通のものを利用している。

　Salt値の仕組みは、システムを改修する予定です。
　Prototype EVEでは、ユーザが初回ログインすることにより、パスワードのハッシュ値を求め、そのハッシュ値をシステムへ登録します。Salt値は、ユーザがログインするときに、パスワードのハッシュ値とSalt値を文字列連結した値から、ハッシュ値を求める時に利用しています。ただ、今後は、そうでない運用を考えており、3つのモードを用意しようと考えています。
　1つ目は、パスワードをそのままデータベースに格納するモード。これは、管理者が初期ユーザID、パスワードを登録する際に利用します。
　2つ目は、従来通りの運用・・・。
　3つ目は、ユーザ個別にSalt値を設定し運用する方法です。

　1つ目の運用はあるかどうか不明ですが、今後ビジネス的に利用するということを考えると、こんな運用しているところありませんか？管理者がユーザIDとパスワードを登録し、そのユーザIDとパスワードをユーザに知らせます。ユーザは、初回のログインにおいて、ユーザがパスワードを入力すると、従来の流れでハッシュ値を求め、データベースにハッシュ値が登録されるという流れになります。
　2つ目は、いきなり、ユーザ個別のSalt値を導入して、ログインできなくなったというのは困るので、当初は従来の運用を残します。そして、ユーザ個別に、3つ目のSalt値を利用する運用に移行するという流れにしようと考えています。

[あとがき]
　現在、いろいろシステムを作ることを考えていますが、同システム自分だけでなく、多くの人に利用してもらおうと考えています。その場合、やはり注意しなければならないのが、セキュリティ・・・。せっかくそのために知識を身に着けたので、身に着けたセキュリティに加え、自分で考えたセキュリティもシステム化していきたいと思います。
　以前も話しましたが、Salt値もストレッチングもセキュリティの本に書かれる前からやっていました。そういう意味では、先駆者的なことを今までしてきています。今後も、そんなシステム開発をしていきたいと考えています。

　では、また！