OSX専用の開発環境/エディターであるEspressバージョン2のα版が公開されてます。

http://macrabbit.com/espresso/2/

記者「ところでパスワードの保存はどうすればいいんでしょうね」

デスク「決まってるだろ、小沢だよ小沢」

記者「さすがデスク、情報通ですね」

デスク「いいから検索しろ！」

すみません、出だしから少し間違えました。

パスワードの保存は次3つののルールにのっとってやりましょう

ルール1

パスワードは平文で保存しないで暗号化する

ルール2

復号化できる暗号化をしない。

ルール3

パスワードは暗号化する

具体的にはこんな手順で

１.パスワードを暗号化するためランダムデータ(Saltとかいう奴)を用意します。

2.Saltを使って暗号化

3.保存

ユーザーがパスワードを入力したら

1.入力したパスワードを上と同じ手順で暗号化

２.データベースのパスワード(暗号化済み)と比較

以上

ちなみに、Saltはユーザーごとに用意する必要があるので、「パスワードを忘れたときのヒント」みたいな感じでユーザーに入力させる方法もとれます。

その場合はSalt自体も暗号化する必要があるから、Saltを暗号化するSaltもほしくなっちゃう。

塩分とり過ぎ。

なんつって。

結論

システム開発を依頼してて、相手が「ユーザーがパスワードを忘れたときはメールでパスワードを送ります」とか言い出したら、危険信号。

ウェブから流出して困る個人情報の最右翼はもちろん｢カード番号｣ですが、それ以外の個人情報はどうでしょうか？

電話番号とかは嫌ですね。住所とかも。

でも、実際のところ、ウェブサイトで収集しなければならない個人情報は

・問い合わせなどのユーザーからのアクションが可能なら「メールアドレス」

・ログインするサービスなら「パスワード」

・課金するなら「決済の時に必要な情報」　:カード番号、有効期限、カード名義、セキュリティーコード

くらいのはずです。

課金に必要な情報は決済サービス業者に管理を任せるとすると、一般的にウェブサイトで収集「しなければならない」情報は「メールアドレス」「パスワード」くらいになります。

(逆にいえば、今多くのウェブサイトで収集している個人情報は、「本来そのサービスを提供するうえで不要なのにサイト運営側の都合だけで収集している」といえます。)

メールアドレス

ログインする必要がないサービスであれば、最悪流出するのは「メールアドレス」だけです。

想定できる被害は迷惑メールが増える、とかでしょうか？

でも、それって○天とかに登録しても同じことが起きたりしますね。

それはともかく、ウェブサービスを考えるなら、「どうすればログインしないですむか？」ってことを真剣に考えるべきですね。

ログインしなくても、ある程度のセキュリティーを担保することは可能なはずです。

パスワード

どうしてもログインしてもらわなければならない、となったら「パスワード」の登場です。

そして、ここがウェブサービスを考える上で一番の山場です。

個人情報が流出するとき、パスワードがそのまま、つまり平文のまま流出することが結構あります。ヘブンじゃなくてね……

開発する側からすると、パスワードが平文で保存されてるって、ちょっとあり得ない話です。

データベースにパスワードが暗号化されないで保存されているということは、こういうメリットがあります。

・ユーザーがパスワードを忘れたときに、メールで送ってあげることができる

逆に

・ハッカーに侵入されたときに、パスワードをそのまま見られちゃう

という心配もあるわけで、そんなのちっともメリットじゃない。

パスワードを忘れたらパスワードを再発行するためのワンタイムURL(期限付きの一意のURL)を送ってあげればいいだけです。

ところで、なんでパスワードが他人に知られると困るかというと

・多くの人が複数のウェブサービスで、同じパスワードを使っている

からなんです。

つまり、流出したサイトだけの問題ではなくなっちゃうのです。

・gmailのパスワードを勝手に変えられて

・Amazonの住所とメールアドレスを変えられて、知らないうちにいろいろ購入されて

・楽天でいろいろ購入されて

・Google Analyticsでアクセス数をリセットされて

・facebookのプロフィール写真をアニメ画像にかえられて

もうしらんがな。

パスワードが平文とか……

マジなんですかね。

もういっそのこと、個人情報はできるだけ収集しない方向でいったほうが、ウェブサイトはいいんじゃないでしょうか。

マーケティングにはメールアドレスさえ分かれば十分だと思いますよ。いやほんと。

などと言いつつ、個人情報の流出というのはひと事ではないわけで、ソニーを批判する勇気などまったくなく、明日は我が身かなどと、いつも思いながら開発するわけで、母さん、東京は星が見えません。

「ひと事ではない」とか言いつつも、結局今のところひと事なので、流出したパスワードの分析とか見ておもしろがったりするわけで、母さん、もうちょっとしつこいですか。

http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html

これを見るとパスワードというのは、だいたい

・6〜8文字

・英数字だけ

らしいですな。

もうパスワードって仕組みもなんとかならないかな。

配布されている公式のパッケージをそのままインストールするとエラーが発生します。

現象としては、いくらがんばってもMySQL君が起動してくれない、そんな感じです。

原因はmy.cnfのオプション設定がよろしくないようで、エラーが出ている箇所をコメントアウトしたら動き出しました。

CodaとかEspressoとかね。OSX専用ですが。

うちは数年使っていたBBEditからCodaに乗り換えました。

BBEditは、phpのプログラミングにはいいけどHTMLとかCSSになるとちょっと弱々しい感じ。

デザインも古くさいし。

CodaはTransmitとかSubversionと連携できるのでいいと思います。

まさか、いまだにWindowsでFTPとかしてないですよね？

いま仕事が忙しいので手短に書いときますが、

1.　自社サイトのコンテンツをCMSとかで動的に生成。このときfacebook表示用に調整しとく。

2.　1のページをfacebookのアプリとして登録

3.　公式ページにアプリ登録。なんなら最初に表示するページとして、そのアプリページを設定しとく。

これだけで大丈夫

たぶん。。。

たぶんっていうのは、ほら、facebookとかgoogleとか平気で仕様変更するから。じゃんじゃんするから。

仕様変更の2ヶ月前くらいに電話してきて

「あのぉ、フェイスブックだけど」

「なに、ひさしぶりじゃん」

「言いにくいんだけどさ、こんど仕様変更するから」

「え！」

「ごめん」

「え〜」

「ほんとごめん」

「このあいだ変えたばっかりじゃん」

「しょっちゅうアップデートしないと、いつ飽きられちゃうかって心配でさ。こっちだっていろいろ大変なんだよ！このあとも200件くらい電話しなくちゃならないし。じゃあね」（ガチャン）

「フェイスブックぅ〜」（ツーツーツー）

みたいな会話があるならいいんだけど。

例えば、あなたがfacebookに新規登録して、勤務先を入力したとします。

するとどうでしょう！

まだ、その勤務先のページができていないときは、勝手に「コミュニティページ」なるものが作成されてしまいます。

最初は、別に問題ないような気がします。

でも、あなたの会社の上司が「うちの会社も、facebookに公式ページとかを作るべか」なんて言い出すとめんどくさいことになります。

だってね、もうこの時点であの勝手に作られちゃった「コミュニティページ」のほうで「いいね」ボタンを押した人が5人くらいいるからです。

かくして、公式ページを作成しても、コミュニティページはそのまま生き残り、せっかく「いいね」を押してくれても２つのページで分散してしまうことになります。

例えば「IBM」のページを見るとわかりますが、公式ページのほうは約5万人以上が「いいね」と言っていて、コミュニティページのほうは5千人以上のひとが「いいね」と言っています。なんだかもったいないですね。英語で言うと「Mottainai !!」ですね！

でも、ご安心を、どうやらコミュニティページと公式ページは統合ができるらしいですよ。

たとえば、ここを見て下さい。

http://www.facebook.com/help/new/?page=1155&hloc=ja_JP

「統合できます」って言ってますね。

「統合する」ボタンを押せばいいんだ！

簡単ですね。

あとは、そのボタンがどこにあるかわかれば完璧です……

どこだろう……

なんか、facebookってこんなのばっかりですな。

驚くほどわかりにくい。

軽くて安心して使えてJQueryなリッチテキストエディターelRTE。

バグがありました……

どんなバグかというと、XHTMLで「area」タグを使うと、エンドタグの「/>」が「>」に勝手に変えられちゃうってこと。

修正は簡単で、elrte.full.jsなら3041行目あたり

xhtmlTags : function(html) {

    return this.xhtml ? html.replace(/<(img|hr|br|embed|param|link)([^>]*\/*)>/gi, "<$1$2 />") : html; 

}

を

xhtmlTags : function(html) {

    return this.xhtml ? html.replace(/<(area|img|hr|br|embed|param|link)([^>]*\/*)>/gi, "<$1$2 />") : html; 

}

に変えるだけ。

ほかのタグも必要なら同様に追加すれば大丈夫です。

CMSの編集画面には、だいたいリッチテキストエディターがついてますね。

「ワープロ感覚で使えますよ」ってやつ。

代表的なのは次の２つでしょうか。

1.　TinyMCE

2.　FCKEditor改め CKEditor

区別がつかない？

はい、その通り。機能も大差ありません。

多くのCMSに搭載されているのは、この２つのうちのどちらかと言っても過言ではありません。

でも、どちらもフル機能を無料で商用で使おうとするとちょっと無理があります。

そこで、いま弊社のCMSでは違うヤツを使ってます。

それがこれ

3.　elRTE

JQuery UIを使っているので、見た目のカスタマイズは簡単そうです。

ライセンスは「三条項BSDライセンス」。

使っていて、上のふたつより軽い印象です。