プログラマでありたい

おっさんになっても、プログラマでありつづけたい

普通の人の為のパスワード運用の話


 ID,Passwordの漏洩・アカウントハッキングなど、インターネットの世界も物騒になってきました。Yahooを始め身近なサービスの利用者も被害が出ているので、一般の方々でもID,Passwordの運用を考える必要が出て来ました。ここで言う一般の方々は、GmailやYahooを始め、10個程の会員制のシステムを利用している人のことを想定しています。
 それでは、何をすれば良いのでしょうか?最低限、下記の3つをしてください。

  • 簡単なパスワードを設定しない
  • パスワードの使い回しをしない
  • 2要素認証(2段階認証)の設定が出来るものは、必ず設定する

簡単なパスワードを設定しない



 基本的なことですが、大切なことです。ところで、簡単なパスワードとは何でしょう?それは、辞書に載っている単語や数字の並び順の羅列です。流出したパスワードを調査した米国の事例がありますので、見てみましょう。

最も安易なパスワードは? 流出情報の分析結果を発表 

1.「123456」
2.「12345」
3.「123456789」
4.「Password」
5.「iloveyou」
6.「princess」
7.「rockyou」
8.「1234567」
9.「12345678」
10.「abc123」

 トップ10のうち、半数が数字の並びが占めていることが解ります。ハッカーは当然ながらこの傾向を知っていますので、アタックの際の試行を試すことでしょう。とは言っても覚えられないよという人は多いと思います。生成例としては、単語と単語を結ぶ。さらにその間に数字を挟むなども、良いかもしれません。
例)princess0515baseball

パスワードの使い回しをしない



 次に、というより一番大事になってきたのが、パスワードの使い回しをしないということです。最近の傾向としては、別のシステムで漏洩したID,Passwordを利用して、色々なシステムでログイン試行をするものです。一昔前は強固なパスワードを1つ作って暗記して、全てのシステムで使いまわすというのが多かったかと思います。今では、まったく通用しません。同一のパスワードを使いまわすぐらいだったら、メモして保管しておく方がよっぽどましという状況にチェンジしています。
 となるとどうするか?ルールベースで、システム名+共通のパスワードの組み合わせというのも1つの手です。もう1つは人間系の管理を諦めて、パスワード管理ツールを導入するというのも1つの手です。私は以前エントリーを上げましたが、1passwordを使って全て管理しています。

2要素認証(2段階認証)の設定が出来るものは、必ず設定する



 最後に2要素認証(2段階認証)出来るものは全部設定していましましょう。Googleを始め大手のサービスでは、設定出来るものが増えて来ました。また、以前は専用のハードウェア・トークンを購入する必要があったのですが、今でだとスマフォで使える無料のソフトウェア・トークンがあります。(Google Authenticatorなど)
 2要素認証の生成キーを盗み出してハッキングするという手法もありますが、現状では個人のID,Passwordを盗む為にそこまでコストをかけないと思います。というところで、当面のところは最も有効な手段の1つだと思います。

1passwordに対する補足



 1passwordを勧めると、2つの懸念を提示されることがあります。一つ目は、インターネット同期をすれば1passwordのサービス側にパスワードを知られるにではないかという懸念です。これは誤解です。1passwordのインターネットの同期機能は、利用者側がDropboxなどの同期先のサービスを選択します。サービス側(1password)としては、利用者のインターネット上のパスワードにアクセス出来ません。
 2つ目は、インターネットを利用してのパスワード同期すること自体の危険性です。これについては、ある一定のリスクはあります。同期先に利用したDropbox等がハッキングされる可能性も充分ありえます。そこは、利便性とリスクを考えた上で、利用者自身に判断していただく必要があります。私は複数台のPC、スマフォを利用する都合上、同期のリスクをとっています。(一応、パスワードファイルはマスター・パスワードを使って暗号化はされています。)
 書いているうちに、1password自体が悪意のある会社になったらどうするのかという点も気が付きました。ここも信用次第ですね。現在のように伸び盛りの間はよいですが、落ち目になってオーナーチェンジが繰り返されたら、引越しも考えた方が良いでしょう。

まとめ



 残念ながら対岸の火事ではなくなったセキュリティ問題。私は関係ないと思わずに、早いうちから対策を考えましょう。何と今なら、1passwordが期間限定で半額キャンペーン中というステマで終わらせて頂きます。


1Password - AgileBits Inc.


See Also:
AWSの2段階認証 Multi-Factor Authentication(MFA)を導入する
今時のパスワード運用の仕方。或いは1Passwordの勧め。

Macのディスク使用状況を可視化するユーティリティ GrandPerspective


 以前、Windowsのディスク使用状況を可視化するユーティリティを紹介しました。Mac版もないかなぁと探してみたら、ほぼ同一のモノがありました。その名もGrandPerspective。使い方は簡単で、ダウンロード後にFile -> Scan Folderを押して、調べたい所を指定すれば良いです。全部調べたければ、Macintosh HDを指定すれば大丈夫です。ディスクの容量にもよりますが、割りとすぐに結果を出してくれます。結果は、冒頭の図のように大きな塊や個々の断片のファイルで表現されます。容量を減らしたい場合は、消せる大きな塊から潰していけばよいでしょう。


 そもそもの発端は、我が愛機MacbookのディスクをSSD化しようかなと思い立ったことにあります。今だと120GBくらいのIntel SSDで1万5千円くらいです。充分射程距離に入ってきたなという感触です。未だに次期Macbook Proを待ちつつ、SSD化でもう少しやり過ごしても良いかと悩んでいますw
 まぁディスクの中を綺麗に保つのは良いことだと思うので、一度GrandPerspectiveお試しあれ!!


See Also:
Windowsでディスクの使用量が可視化できるツール WinDirStat


Pivotal Tracker cloneのFulcrumを、Herokuにインストールする話

 Pivotal Trackerというアジャイル開発を手助けしてくれるツールがあります。シンプルかつ軽快なUIで、気持よくタスク管理が出来る優れたツールです。(詳しくはここをご参照ください。)
 SaaS形式で提供されていて、クレジットカード一つですぐ始められるという点もありがたいです。一方、有料であることやSaaSであるために社内規程等で利用出来ないという方もいると思います。そんな場合はCloneであるFulcrumがお薦めです。オープンソースとして公開されているので、自前でインストールできます。動作環境としては、Ruby1.9系のRails3ベースです。DBも必要です。


 しかし、今更サーバーを用意するのが面倒くさいという方にお薦めの方法があります。Herokuにインストールすれば、あっという間に構築出来ます。Herokuのアカウントが既にあるという前提だと、以下の手順で5分で作れます。

# githubからソースのチェックアウト
$  git clone git://github.com/malclocke/fulcrum.git
$ cd fulcrum

# Herokuにプロジェクト作成&設定
$ heroku create APPNAME --stack bamboo-mri-1.9.2
$ heroku config:add MAILER_SENDER=hogehoge@example.com
$ heroku addons:add sendgrid:starter
$ git push heroku master

セットアップ
$ heroku rake db:setup

上記のコマンドが無事に成功すると、http://APPNAME.heroku.comのアドレスで見れます。(APPNAMEの部分は置き換えてください)
Enjoy!!


MongoDBを入れてみた

 必要に迫られて、CentOS 5.4にMongoDBを入れてみました。

 # yum install mongodb-server mongodb-devel
 # /etc/init.d/mongod start
 Starting mongod:[  OK  ]


接続してみると、エラー。

#mongo
Sun Jun 26 21:53:49 *** warning: spider monkey build without utf8 support.  consider rebuilding with utf8 support
connecting to: test
Sun Jun 26 21:53:49 Error: couldn't connect to server 127.0.0.1 (anon):1154
exception: connect failed


ログ等を確認してみると、そもそも起動していないっぽい。
起動O.K.って出してたじゃないですか。。。

# /etc/init.d/mongod status
mongod dead but subsys locked

# cat /var/log/mongodb/mongodb.log
Sun Jun 26 21:52:22 MongoDB starting : pid=2052 port=27017 dbpath=/var/lib/mongodb 32-bit

** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
**       see http://blog.mongodb.org/post/137788967/32-bit-limitations

Sun Jun 26 21:52:22 db version v1.6.4, pdfile version 4.5
Sun Jun 26 21:52:22 git version: nogitversion
Sun Jun 26 21:52:22 sys info: Linux x86-12.phx2.fedoraproject.org 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 i686 BOOST_LIB_VERSION=1_33_1
Sun Jun 26 21:52:22 exception in initAndListen std::exception: dbpath (/var/lib/mongodb) does not exist, terminating
Sun Jun 26 21:52:22 dbexit:

Sun Jun 26 21:52:22 shutdown: going to close listening sockets...
Sun Jun 26 21:52:22 shutdown: going to flush oplog...
Sun Jun 26 21:52:22 shutdown: going to close sockets...
Sun Jun 26 21:52:22 shutdown: waiting for fs preallocator...
Sun Jun 26 21:52:22 shutdown: closing all files...
Sun Jun 26 21:52:22     closeAllFiles() finished

Sun Jun 26 21:52:22 dbexit: really exiting now


/var/lib/mongodbがありませんとの指摘です。インストール時に作ってくれよという気もします。
/var/lib/の下にmongodbディレクトリを作り、ユーザとグループをmogodbにします。


気をとりなおして再度起動&ログイン
UTF8絡みでWarningが出ています。
日本語を入れると、やっぱりエラー。

# mongo
MongoDB shell version: 1.6.4
Sun Jun 26 22:36:23 *** warning: spider monkey build without utf8 support.  consider rebuilding with utf8 support
connecting to: test
>  k = { name : "ほげほげ" };
error:non ascii character detected
>


SpiderMonkey(js)をUTF-8対応すれば良いらしいです。
Building Spider Monkey - MongoDB
上記の記事によると、jsをアンインストールしてから再度UTF-8版を入れてねと書いています。
ただし、MongoDBをyumで入れたい場合は、上記の方法ですると依存関係でrpm版のjsが勝手に入れられます。
解決策としては、何も考えずにyumでmongodb-serverとmongodb-develをインストールして(jsも一緒に入ります)
その後にソースからビルドしたjsを上書きしたら上手くいきます。

# curl -O ftp://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
# tar zxvf js-1.7.0.tar.gz
# cd js/src
# export CFLAGS="-DJS_C_STRINGS_ARE_UTF8"
# make -f Makefile.ref
# JS_DIST=/usr make -f Makefile.ref export
# mongo
MongoDB shell version: 1.6.4
connecting to: test
>  k = { name : "ほげほげ" };
{ "name" : "ほげほげ" }


ちょっと苦労しましたが、これでMongoDBで日本語が扱えます。
お試しアレ

必ずスパムと判定されるメールと、ウィルスの作り方

 メール本文中に下記の文字列をいれると、対応しているスパムフィルターはそのメールをスパムとして判定されます。このコードは、GTUBE(Generic Test for Unsolicited Bulk Email)と呼ばれ、テスト用のコードです。

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

GTUBE - Wikipedia
SpamAssassin: The GTUBE


 同様にウィルスにもEICARテストファイル(EICAR Standard Anti-Virus Test File)というテスト用のファイルを作ることが出来ます。空のファイルに下記の文字列を貼りつけると、あら不思議ウィルスファイルが作れます。(正確に言うとウィルスと認識されるファイルです。)

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

EICARテストファイル - Wikipedia
EICAR test string を使って Norton AntiVirus をテストする方法


 知っておいたら、人生で一度くらい役に立つことがあるかもしれませんw
お試しあれ

アプリ開発者から見たAndroidとiPhone

 未来の自分へのメモがてらに、アプリ開発者目線から見たAndroidプラットフォームとiOSプラットフォームについて。

私の両プラットフォームの経験は次のとおりです。
同等の開発経験をしていないので、多分に憶測も含まれます。
・iOSアプリについては何点か開発して、AppleStoreにも並べている
・Androidアプリについては、サンプルアプリを軽く作っただけ


 まずiOSですが、プラットフォームとしてのメリットは、何と言っても(ほぼ)単一機種向けに開発すれば良いことです。iPhone/iPad、OSのバージョンの違いはありますが、機器性能依存の強いアプリ(カメラアプリ等)を作らないのであれば余り気にする必要はないです。せいぜいOSのバージョンごとのAPIの存在の差異を気にするくらいです。また、単一機種に関わらず圧倒的なマーケットの大きさは魅力です。何も宣伝していないようなアプリでも、毎日コンスタントにダウンロードされます。この二つは大きいです。
 反対にデメリットですが、やはり審査制度です。審査時間が掛かるといったことや、非公式APIを使うと問答無用にリジェクトされるということもありますが、最大の問題はアプリのコントロールが開発者から奪われることでしょう。アップルの審査基準は基本的にAppleが考えるiPhone,iPadに適合するかです。ジョブズの美意識に反するエロアプリや、Appleの戦略に直接競合するアプリは出せないのです。どんなアプリを作るかは、開発者の自由。どんなアプリをインストールするかは、ユーザの自由。こうあって欲しいです。またアプリ間の連携の手段が少ないのも気になります。基本は1アプリ1機能に限定して、機能連携はユーザが好きなアプリと連携というのが望ましいですが、現状では難しいですね。


 次にAndroidアプリですが、メリット・デメリットはiOSアプリのほぼ反対となります。メリットとしてはプラットフォームの自由度の高さです。自由といっても端末によって色々制約があったりはするのですが、それは端末を選んで開発出来るというメリットがあります。また他アプリとの連携もiOSに比べて比較的やり易いです。
 反面、多様性は開発する上では大変です。建前はAndroidアプリだとどこでも動くというものでしょうが、実際はそんなことはないでしょう。やはり機種ごとのカスタマイズは必要になるかと思います。となると、Galaxy等の流通量の多い端末をメインのターゲットに開発することになるので、市場としては劣化iPhoneなんじゃないのとか思ったりします。


 上記を踏まえて今後どっちに注力するのと言われたら、恐らくどっちもそこそこと答えると思います。基本的なロジック・制御はサーバサイドでやって、iOS,AndroidはViewの部分だけを担当させるのが楽なんじゃないかなと思います。まぁそのViewの部分の最適化が一番面倒くさいんですけど。また使う人から考えたら、出来るだけローカルの端末で処理してもらえる方が早くて楽でよいはずです。ただ回線の進化等考えれば、やっぱりサーバで処理させても遜色ないんじゃないかなと思います。
 という訳で今年はGoogle App Engine等を使って、サーバ側がほぼ無限にスケールするアプリを作ってみたいですね。1年後全く違うことを言っていると思いますが、今のところの考えです。

Webのフロントエンドのボトルネックを探るなら、FireBug+YSlowで決まり

 WEB+DB PRESS Vol.59を読んでいたら、Webサイトのフロントエンドの高速化の特集でした。なるほどと思うことも多々あるので、Webサイトの制作に携わる人は一度は読んでおいたほうが良いといえる内容です。特にJavaScriptの遅延ロードやCSSの呼ばれ方などを考慮した書き方なの、最近の潮流が解るので情報のアップデートには最適です。
 そんな中で特集の一番最初に出ていたのが、ボトルネックの分析の仕方。ツールがなければ至難の技ですし、そもそもどんなツールが良いのか意外に知られていないと思います。そして、特集で挙げられていたのが、FireBug+YSlow。これは本当に良いと思います。何故ってFireBugで視覚的に把握出来るので、直感的に理解できるからです。その上で、YSlowで詳細を見ていくという形が良いです。まぁ文章で説明するより図で見たほうが早いと思うので、Yahoo! JAPANを解析したらどうなるかを載せてみます。
 まずはFireBugの接続画面。どの順番に呼ばれているかわかりますね。

 そしてYSlow。問題点を指摘してくれます。


 問題を解決するには、今何が起こっているかを把握するのが第一歩です。それを手助けしてくれるツールが出てきてるので、有り難い限りですね。他にもGoogleのPage SpeedやAOL Pagetestなども紹介されていました。GoogleのPage Speedは、YSlowよりもさらに細かいので次の段階で利用するのが良さそうですね。


WEB+DB PRESS Vol.59
WEB+DB PRESS Vol.59
posted with amazlet at 10.11.14

技術評論社
売り上げランキング: 2077