« 2013年3月 | メイン | 2013年5月 »

2013年4月16日

Perl QA Hackathon 2013 Satellite at Tokyoに行ってきた話

なんかやることとかもよくわかってなかったんですが、面白そうなので行ってきた。テスト関連とかそういう話だったので、とりあえずUkigumoでもいじってようかなーと。

出した成果?はUkigumo::Client をMinilla化して、Notify::Growlを追加してCPANに上 げたくらいです。Minillaだいぶ便利。minil migrateしたら挙動がよくわからなくて tokuhiromに色々直接教えてもらえたので良かった。

あとはherokでのperlのバージョン指定みたいなissue が上がってたので、ちょっとやってみようかと思いつつ調べて、herokuでUkigumo-server動かしたりしてた。

heroku-buildpack-perlは今はmiyagawaさんのやつでちゃんと動く模様。

http://ukigumo.herokuapp.com/

割と簡単に動いたんで、herokuでの動かし方のdocument追加したりした。

インスタンス1つだけだったら、お金かからないらしいんで、とりあえず立てたままに してある。

本題のherokuでのperlのバージョン指定に関しては、nodeの実装 見てみたら割とめんどくさい感じだったのでそっ閉じ。

僕自身はそんな成果出さなかったけど、tagomorisさんにFluent::AgentLiteをCPANに上 げてほしいって言ったらCPANizeしてくれたり、plenvとかcartonの話とかの現状の話を miyagawaさんとかtokuhiromとできたりしてだいぶ有意義だった。

00:28

2013年4月10日

パスワードはサーバー側で生成したほうが良いんじゃないかという話

いつまで文字列ベースのパスワードを使うんだって話は置いておいて、Webサービスのパスワードはもはや、人間には覚え切れない領域に達しているわけです。

  • サービス毎に異なるパスワード
  • 大小英数数字記号混じり12文字以上

みたいなのは必須で、それに加えて意味があるかどうかは甚だ不明ですが、定期的に変更必須みたいなポリシーがあるところもありますね。

言ってしまえば、もはや人間が覚えられる程度の強度のパスワードでは弱すぎるわけで、そうなるともう否応なしにパスワード管理ツールを使うしかありません。

そのような「パスワードは覚えきれない」という前提に立つと「もはや覚えやすいパスワードを使う必要がないという」逆説が生まれます。

となると、もう、パスワードはサービス側がランダムな文字列を発行してしまって、それを強制的に使わせる形で良いんじゃないかとふと思いました。以下の様な具合です。

  1. 大小半角英数数字記号混じり20文字程度の(サービス提供側が十分な強度だと認識できる)パスワードを生成
  2. ハッシュ化したものをDBに格納
  3. パスワードを画面に表示してユーザーに使わせる

サーバー側のDBへの保存方法等は従来と同様です。

これには以下の様なメリットがあります。

  • 覚えやすい強度の弱いパスワードを使われる危険性がない
  • 他のサービスで同じパスワードを使われる可能性が低い (発行したパスワードをその後別サービスで使われてしまう可能性はある)
  • パスワード定期変更ポリシーも適用させやすい

ユーザー登録や利用の敷居を下げたいカジュアルなWebサービスでは使いたくない手法でしょうが、業務アプリや管理ツール、Saas等では一考の余地があるのではないでしょうか。

ユーザー登録のフローなんかは以下のように考えてみました。

  1. ユーザー登録画面(メールアドレス必須)
  2. ユーザー登録確認メール送信確認画面
    ここで「秘密の質問」を出して、答えを入力してもらう
  3. サーバーでワンタイムURLを発行してメール送信。URLの期限はなるべく短く(30分程度)
  4. ワンタイムURLにアクセスすると、先ほどの「秘密の質問」が表示される。それに再度答えてもらう
  5. 秘密の質問の解答が正しければ、パスワード生成ボタンが表示される。
    生成前に「覗かれていないか周りを確認すること」等を注意書き
  6. パスワード生成ボタンを押すとパスワードが画面に表示される。再表示は出来ないので、必ず何処かにコピーするなりパスワード管理ツールに登録することを促す

秘密の質問はあくまでも、パスワードを発行するための一時パスワードに過ぎないので、強度はそれほど強くある必要はありません。「秘密の質問」形式をとっているのは「一時パスワード」という形で登録させてしまうと、それを「サイトログインパスワード」だと勘違いしてしまうユーザーが出てくる可能性があるので「秘密の質問」という形にしている次第です。

パスワード変更なども、自分の好きなパスワードを決められるのではなく「再生成」することになります。パスワードリセットなんかは登録とほとんど同じフローになるでしょう。

サーバーにパスワード生成させるのはどうなの？って話はあるかと思いますが、平文をどこにも保存しない作りにすれば良いだけなので問題ないかと思います。パスワードを平文保存してるかどうかなんてのはどちらにしたって信頼ベースなので。実際問題として今でも世の中の半数以上のサービスはパスワードを平文保存してると僕は思ってます。

カジュアルなWebサービスでいきなりそのフローを辿らせるのは敷居が上がるので採用しづらいとは思いますが、この方向性を指示する人に対してはオプションでこの登録方法を選んでもらうのはアリなんじゃないかと思います。

はてなさんとかが、そういう登録方法をオプション選択させるのはユーザー層のリテラシー的にもアリなのではないかと。そういうところからの草の根活動。

01:27