OpenVPN&セキュリティ情報
2011-06-28
ネットワークからの攻撃より危険!? 拾ったUSBメモリを使う人は少なくないらしい
Human Errors Fuel Hacking as Test Shows Nothing Stops Idiocy から。アメリカの国土安全保障省が行った実験の結果です。
政府や民間の建物の駐車場にCD-ROMやUSBメモリを置き去りにし、それを拾った人の行動を調査したものです。その結果、その記憶デバイスを拾った人のうちの60%のユーザーがデバイスを自分のPCに接続し、そのデバイスやCDケースに公式のロゴが入っている場合は90%のユーザーがインストールした、ということです。
制御機器を攻撃することで知られるStuxnetもUSBメモリを媒介にして広まりましたが、人間の好奇心という脆弱性はなかなか対策が難しいようです。
Read More
政府や民間の建物の駐車場にCD-ROMやUSBメモリを置き去りにし、それを拾った人の行動を調査したものです。その結果、その記憶デバイスを拾った人のうちの60%のユーザーがデバイスを自分のPCに接続し、そのデバイスやCDケースに公式のロゴが入っている場合は90%のユーザーがインストールした、ということです。
制御機器を攻撃することで知られるStuxnetもUSBメモリを媒介にして広まりましたが、人間の好奇心という脆弱性はなかなか対策が難しいようです。
2011-06-26
Dropbox 認証バイパス事件 続報
Dropboxのシステムのバグで認証がバイパスされていた問題について、TechCrunchで続報が報じられています。この続報の根拠は被害者宛にDropboxから送信されたメールです。
そのメールによれば、被害を受けたユーザーは100人未満だったとのこと。そして、少なくともファイルの改変は行われていないようだ、とのことです。これはそれほど規模が拡大しなかったという意味ではいい内容です(と言ってもその100人の中の1人であれば大問題なわけですが...)。
一方の悪いニュースは、被害者全員のアカウントにアクセスしていた1人のユーザーがいる、ということです。つまり、タイプミスなどでうっかり他人のアカウントにアクセスしたわけではなく、このバグを利用して意図的に他人のアカウントにアクセスしていたユーザーが存在した、ということです。
被害者宛のメールでは、被害者が取る必要のある対策の概要が記載されています。また、DropboxのCEOであるDrew Houstonの電話番号が載せられており、質問などがあれば遠慮なく電話して欲しいとも書かれています。この問題に対してDropboxが危機感を持っている表れとも言えるかもしれません。
ただ....やはりこの情報もTechCrunchという外部の情報源からとなってしまいました。Dropbox Blogにも被害者の人数が100人未満だったことなどは追記として記載されていますが、あくまでもそれだけ。おそらくDropboxとしては、直接の被害者以外には細かい情報提供は行わないという方向性で進めているように見えますが、これが吉と出るか凶と出るか。
Read More
そのメールによれば、被害を受けたユーザーは100人未満だったとのこと。そして、少なくともファイルの改変は行われていないようだ、とのことです。これはそれほど規模が拡大しなかったという意味ではいい内容です(と言ってもその100人の中の1人であれば大問題なわけですが...)。
一方の悪いニュースは、被害者全員のアカウントにアクセスしていた1人のユーザーがいる、ということです。つまり、タイプミスなどでうっかり他人のアカウントにアクセスしたわけではなく、このバグを利用して意図的に他人のアカウントにアクセスしていたユーザーが存在した、ということです。
被害者宛のメールでは、被害者が取る必要のある対策の概要が記載されています。また、DropboxのCEOであるDrew Houstonの電話番号が載せられており、質問などがあれば遠慮なく電話して欲しいとも書かれています。この問題に対してDropboxが危機感を持っている表れとも言えるかもしれません。
ただ....やはりこの情報もTechCrunchという外部の情報源からとなってしまいました。Dropbox Blogにも被害者の人数が100人未満だったことなどは追記として記載されていますが、あくまでもそれだけ。おそらくDropboxとしては、直接の被害者以外には細かい情報提供は行わないという方向性で進めているように見えますが、これが吉と出るか凶と出るか。
2011-06-24
流出したパスワードから傾向を読み取る
A brief Sony password analysis から。Sonyのパスワード流出事件で公開されたデータをもとに、ユーザーがどんなパスワードを使っているかという統計です。
詳細な分析結果は元記事を見ていただくのが一番ですが、ちょっと要約するとこんな感じです。
元記事のコメント欄でも活発な意見交換が行われていて、なかなか興味深いですよ。
Read More
詳細な分析結果は元記事を見ていただくのが一番ですが、ちょっと要約するとこんな感じです。
- 長さは6文字と8文字が多い
- 英大文字、英小文字、数字、記号のうち3つ以上を使っているのは4%程度
- よく使われていたパスワード TOP10は以下の順序(元記事ではTOP 25が挙げられています)
- seinfeld
- password
- winner
- 123456
- purple
- sweeps
- contest
- princess
- maggie
- 9452
- インターネット上に公開されているパスワード辞書に合致したものは36%
- Sony内の複数サイトで共通したパスワードを使っていたケースが92%。
- ハッシュ解読で使用されるRainbow Tableで簡単に解析される「9文字以下の英小文字パスワード」を使っていたのは82%(つまり、流出したパスワードが仮にMD5などでハッシュ化されていたとしても、82%は解読可能だった可能性が高い、ということになります)
元記事のコメント欄でも活発な意見交換が行われていて、なかなか興味深いですよ。
2011-06-21
もう一つ、Dropboxの今回の対応について
Dropbox Blogのコメント欄でもかなりコメントされていますが、今回の問題に対するDropboxの対応はちょっと問題がありそうです。公式の見解はBlogのこのポストのみ、トップページはもちろん、Twitterですら取り上げていません。ユーザー登録時にメールアドレスを登録していますが、注意喚起のメールが来ることもありません。
「無料で使っているユーザーだったら文句は言えない」という考え方もあるかもしれませんが、せめて注意を促す対応は必要でしょう。
起こした問題だけでなく、その後の対応がユーザーの印象に大きな影響を与えることはたくさんの事例が証明しています。Dropboxが今後どのように対応していくのか、注目したいと思います。
Read More
「無料で使っているユーザーだったら文句は言えない」という考え方もあるかもしれませんが、せめて注意を促す対応は必要でしょう。
起こした問題だけでなく、その後の対応がユーザーの印象に大きな影響を与えることはたくさんの事例が証明しています。Dropboxが今後どのように対応していくのか、注目したいと思います。
これは大変だ! Dropbox 認証バイパス事件
数時間前にTwitterではつぶやきましたが、この問題はさすがに取り上げないわけにいきませんね...。Dropbox Blogで公式に発表されています。
Dropbox Blogでの記述をもとにすると、6月20日午後1時54分(太平洋標準時。日本時間では21日午前5時54分)にDropboxのシステムのコードに変更を加え、その際に認証メカニズムにバグが入り込みました。その後、午後5時41分(日本時間 午前9時41分)に問題が発覚、5分後の午後5時46分(日本時間 午前9時46分)に修正を完了した、としています。この4時間の間は、パスワードによる認証なしでユーザーのファイルにアクセスできる状態になっていた、ということです。
Dropbox Blogによればこのタイミングでログインしたのは「少数のユーザー(A very small number of users)」で「1%に遠く及ばない(much less than 1 percent)」としていますが、利用しているユーザー数を考えれば「少数」と片付けられる数ではないかもしれません。
ここしばらく続いているLulzsecなどによる情報流出問題とは異なり、これは完全にDropbox単独のミスによるものです。なんで認証に影響を与えるほど重要なコード修正で(しかも5分で修正できるような)バグを残したままProduction環境に投入したのか、コードレビューはなかったのかなど、気になるところは山積みですが、まずはユーザーとして対策を考えましょう。
Dropboxは、侵入された可能性のあるユーザーには個別にメールを送信するとしていますが、まずは重要なデータが入っているようであればすぐにでも退避させておきましょう。また、Dropbox上のファイルにパスワードなどの機密情報が含まれていた場合は、含まれていたパスワードを変更するなどの対策も必要です。
この手のシステムはどこか不安だったので、個人的にはTrueCryptで暗号化したファイルをDropboxにアップしていたのですが、その不安が的中してしまったのは残念です。暗号化をする手間がかかる分、面倒な部分もあるのですが、安全性には代えられません。クラウドを使ったファイル保存サービスはDropbox以外にもありますが、こういったオンラインサービスを利用する際には、重要なファイルだけでもクライアント側で暗号化してからファイルをアップするという慎重さが求められますね。できることなら、第三者の管理するサーバーではなく、自分の管理するサーバーで安全に管理できるのが望ましいですけど...。
nakedsecurityのDropbox lets anyone log in as anyone - so check your files now! には、こういったサービスの特徴である、どんどんアップデートしていく『ずーっとβ版(eternal beta)』スタイルに潜む危険性も触れられています。システム構築に関わる人間として、この点は常に意識しておかないといけないですね...。
2011-06-19
セキュリティエキスパートのように対応するための6つの方法
Smoothwall Blogの 6 Easy Ways To Look Like A Security Expert から。要は「セキュリティに詳しくない人でもエキスパートのように対応するには」という内容です。こんなことを知っておくと「お、エキスパート!」と呼ばれるようになるかもしれませんね。かえって仕事が増えてしまう危険性をはらんでいますが...。
Read More
- ウィルスですか?と聞かれたときには
自信がなくても大丈夫。virustotalを使いましょう。 - 映画のようなハッキングは意外と簡単です
定番のnmapにはとてもいいGUIがあります。zenmapを使いましょう。iPhoneやAndroidには簡易版のようなOverlook Fingがありますよ。 - セキュリティに関する最新のニュースを常に追いかけるのは大変ですよね
1つお勧めするとしたらBruce Schneierのニュースレター「Cryptogram」です。毎月配信されるニュースレターです。 - リンク先の安全性をチェックするためにVM(仮想マシン)を使って1つずつ調べるのも大変です
リンク先に関するレポートを表示してくれるwepawetを使いましょう。 - パケットアナライザであるWiresharkを使いましょう
ネットワークで何が起きているのかを的確に把握できます。また、暗号化されていないパスワードが参照できることを見せるのはいいデモになるでしょう。 - WindowsだけでなくLinuxも使ってみましょう
まだ使ったことがなければ、インストールせずに使えるLive CDから使ってみましょう。セキュリティという観点から興味深いのはパスワードを復旧するために使用できるTrinity Rescue Kitです。またペネトレーションテストに特化したディストリビューションであるBackTrackもあります。
2011-06-16
iPhoneでよく使われるパスコードとは?
Most Common iPhone Passcodes より。iPhoneアプリケーションの「Big Brother Camera Security」の作者のブログですが、そのアプリケーションのユーザーが設定したパスコードの統計だそうです(匿名とはいえ、こうやってパスコードを集めているというのもなんだかビミョーな気が...)。総数 204,508 を数えるパスコードの中でよく使われていたものトップ10は...?
堂々のトップは、さすがの「1234」に! 第2位に3,000票以上の大差をつけての大勝利です。
第2位は「0000」。これも5,000票を超える優秀な成績です。
第3位に食い込んだのは「2580」。いかにもよくありそうな「1111」や「5555」を上回っての勝利は価値がありそうですが、この番号はどんな意味が...? あ、単純にキーパッドを上から下にってことですね。7位の「0852」はこれの逆で、下から上にということです。
興味深いのは第7位の「5683」です。「ごろーやーさん」とかって語呂合わせではなく、アルファベットの「love」を数値に置き換えたもののようです。他にもなかなか興味深いデータがたくさん出ていますので、関心ある方はこちらからどうぞ。
しかし、今回の統計で集まった20万以上のパスコード全体の中で、よく使われるパスコードの上位10位以内のいずれかを使っていたものが15%もあった、という結果はちょっと考えさせられますね...。
Read More
堂々のトップは、さすがの「1234」に! 第2位に3,000票以上の大差をつけての大勝利です。
第2位は「0000」。これも5,000票を超える優秀な成績です。
第3位に食い込んだのは「2580」。いかにもよくありそうな「1111」や「5555」を上回っての勝利は価値がありそうですが、この番号はどんな意味が...? あ、単純にキーパッドを上から下にってことですね。7位の「0852」はこれの逆で、下から上にということです。
興味深いのは第7位の「5683」です。「ごろーやーさん」とかって語呂合わせではなく、アルファベットの「love」を数値に置き換えたもののようです。他にもなかなか興味深いデータがたくさん出ていますので、関心ある方はこちらからどうぞ。
しかし、今回の統計で集まった20万以上のパスコード全体の中で、よく使われるパスコードの上位10位以内のいずれかを使っていたものが15%もあった、という結果はちょっと考えさせられますね...。
2011-06-13
[OPENVPN TIPS] VPNクライアントに固定IPアドレスを割り当てる
OpenVPNでは、接続してきたクライアントのVPNアドレスは動的に割り振られます(その際に割り振られる際のアドレス範囲はOpenVPNサーバー側設定ファイルに基づきます)。特定のVPNクライアントに特定のVPNアドレスを割り振りたい場合、OpenVPNでは以下の2つの方法で設定することができます。
- client-connectディレクティブで指定されたスクリプトによって生成される設定ファイルを使う
- client-config-dirディレクティブで指定されたディレクトリにクライアント構成ファイルを配置する
まず、サーバー設定ファイルのclient-config-dirディレクティブでクライアント構成ディレクトリを指定します。クライアント構成ディレクトリは、VPNクライアントごとの個別の設定ファイルを格納するディレクトリです。たとえば、クライアント構成ディレクトリを
/etc/openvpn/ccd
にする場合は、以下のようにディレクティブを設定します。client-config-dir /etc/openvpn/ccd
次に、クライアント構成ファイルを作成します。クライアント構成ファイルは、特定のVPNクライアントにのみ適用したい設定を記述しておくファイルで、ファイル名はその設定を適用したいクライアントの証明書の共通名と同じものにします。たとえば、クライアント構成ディレクトリは前述のように
/etc/openvpn/ccd
で、設定したいクライアントの共通名が「client1」であれば、クライアント構成ファイルは /etc/openvpn/ccd/client1
になります。このクライアント構成ファイルに、クライアントに割り当てるVPNアドレスを設定するためのipconfig-pushディレクティブを記述します。TAPを使用している場合で、そのクライアントに 192.168.5.123 を割り当てたい時には
ifconfig-push 192.168.5.123 255.255.255.0のようにIPアドレスとネットマスクを記述します。TUNを使用している場合は、クライアントに割り当てたいアドレスとサーバー側にあたるアドレスをセットで指定し、
ifconfig-push 10.8.2.5 10.8.2.6のように記述します。
クライアント構成ファイルを使う際の注意点を。クライアントごとに適用したい設定ファイルを証明書の共通名で判別するため、複数のVPNクライアントが同一の証明書(同じ共通名の証明書)を使って接続することはできません。したがって、duplicate-cnディレクティブとの併用はできません。
2011-06-08
[OpenVPN TIPS] OpenVPNのIPv6対応
今日は「World IPv6 Day」。というわけで、OpenVPNのIPv6対応について公式FAQから。
Read More
OpenVPNでのIPv6サポートはどうなっていますか?
OpenVPN 2.2-RC2以前のバージョンでは限定されたIPv6対応が行われています。IPv6 TUNドライバがサポートされているOS(LinuxやBSDなど)では、PtoP IPv6トンネルがサポートされています。IPv6 over TAPはEtnernet上の他のプロトコルと同様、常にサポートされています。OpenVPN 2.0がサーバーモードで実行されている場合は、IPv6はTAPモードでのみサポートされます(TUNモードではサポートされません)。VPNのキャリア接続はIPv4エンドポイントを使用する必要があります。
OpenVPN 2.2-RC2では、Windows TAPドライバ用のTUNモードでのIPv6対応が実装されました。
完全なIPv6のサポートはGitの「allmerged」ブランチで利用可能になっており、OpenVPN 2.3で組み込まれる予定です。
2011-06-07
パスワードをどう保持するか ー それが問題だ
ログイン機能を持つWebシステムはたくさんあります。各ポータルサイトやオンラインショップなど、私たちが日常的に使っているものだけでもいくつかありますよね。特定のユーザーだけが使用する業務システムのようなものも含めれば、それほど膨大な認証システムが存在していることになります。
Sony Pictures Entertainmentのユーザー情報が流出した際にパスワードがプレーンテキストだった、という問題がありましたが、これは論外としても、システムを作る開発者としてユーザー認証のための情報をどう保持するか、という点は設計時によく検討しなければならない点の1つです。もちろんデータの流出自体を避けなければならないわけですが、万が一データの流出が発生したとしても、重要なデータはそのままではわからないようにしておく必要があります。
先週末にはFBIの関連組織であるInfragardのユーザー情報がクラックされたというニュースがありました。パスワードは暗号化されていたものの、復号されてしまったようです。saltが適切に設定されていなかった、または簡単に分かるsaltが使われていたのではないかと言われています。暗号化のアルゴリズムの弱点というよりは、システム自体の作りの甘さを示す一例といえます。
一般的には可逆性のある暗号化ではなく、非可逆のハッシュを使ってパスワードを保持しておくという方法がよく使われますが、これにもちょっとした落とし穴が。MD5やSHA1は既に破られる可能性があるので、もう使わないほうが安全です。たとえばMD5なら、ここやここ、ここなどのサイトで解読できるか試すことができます。現時点ではSHA1よりも安全性が高いといわれるSHA2を使うことが多いと思いますが、こういった仕組みはいつかは破られる宿命にあるものと考えて、常に新たな取り組みも含めて検討していく必要がありますね。
前述のMD5の解読サイトでいろいろ試していると、ひとつの重要な傾向に気づきます。それは、一般的な単語の組み合わせや、アルファベットだけの組み合わせだと本当に簡単に解読されることです。日本語の名前のアルファベット表記や、それをちょっといじったぐらいのものでも解読されるケースがあります。記号を含めたり長いパスワードにしたりといった複雑なパスワードにすると、解読される可能性が大幅に下がることが実感できます。
ユーザーとしてはそのシステムでどんな仕組みでパスワードが保護されているのかわからないわけで、とにかくパスワードを複雑にすることが唯一の自衛手段ですね。
2011-06-05
[ブックレビュー] 電話はなぜつながるのか
Asteriskを使ってIP内線網を構築したりといった経験はあるものの、改めて電話の基本を知っておこうと思って手に取った本です。
固定電話から携帯電話、IP電話の概念や仕組みが幅広く取り上げていますが、特に固定電話を中心に書かれています(といっても、IP電話などについても、使う上で押さえておくべき基本的な知識は十分書かれており、知識の整理に役立ちます)。
固定電話に関する情報は特に充実しており、NTTの電話回線網の仕組みがわかりやすく説明されています。この本はこの「わかりやすく」がポイントで、写真や図に加え、例えなども活用した説明が繰り広げられていて、私も含め、電気通信にそれほど詳しくない人でも抵抗感なく読み進められます。内容としてはかなりマニアックな領域まで踏み込んでいるのですが、知っておくと「なるほどね」と思える情報が随所に散りばめられています。
300ページを超える本なのでちょっと腰を据えて読むことになりますが、テレコミュニケーションは(形や仕組みは変わっていくでしょうが)今後も使い続けられていくものですし、そもそも「ネットワーク」=「網」として私たちにとって一番身近だったのは他でもない電話回線網。ネットワークの大先輩のこと、改めて知っておくのもいいかもしれません。
2011-06-03
さすがにこれは... Sony Pictures Entertainmentのデータ流出問題
Sony関連の情報流出が続いていますが、今日はSony Pictures Entertainmentで発生です。しかも件数が100万件を超える模様です。
今回の最大のシステム上の問題はこれでしょう。
今どき誰もが知っているべきレベルの簡単なSQLインジェクションでデータを取れた("SonyPictures.com was owned by a very simple SQL injection, one of the most primitive and common vulnerabilities, as we should all know by now.")という彼らの言い分が事実ならそのシステムの作り自体も大問題ですが、パスワードがデータベース上にプレーンテキストで保存されていたというのは弁解の余地がありませんね...。盗まれたデータも既にインターネット上に公開されており、メールアドレスとパスワードの組み合わせで第三者に流出してしまったことになります。他のサイトでも同じパスワードを使っているようなケースがあるとしたら...と考えると非常に危険なことがわかります。
PCWorld Security Alertでは、自分の情報が流出している可能性がある場合はすぐに次のように対応するよう勧めています。
Read More
今回の最大のシステム上の問題はこれでしょう。
今どき誰もが知っているべきレベルの簡単なSQLインジェクションでデータを取れた("SonyPictures.com was owned by a very simple SQL injection, one of the most primitive and common vulnerabilities, as we should all know by now.")という彼らの言い分が事実ならそのシステムの作り自体も大問題ですが、パスワードがデータベース上にプレーンテキストで保存されていたというのは弁解の余地がありませんね...。盗まれたデータも既にインターネット上に公開されており、メールアドレスとパスワードの組み合わせで第三者に流出してしまったことになります。他のサイトでも同じパスワードを使っているようなケースがあるとしたら...と考えると非常に危険なことがわかります。
PCWorld Security Alertでは、自分の情報が流出している可能性がある場合はすぐに次のように対応するよう勧めています。
- とにかくパスワードをすぐに変更する。同じパスワードを使っているサイトがあればそのサイトのパスワードも変える。
- フィッシングメールが急増する可能性があるので十分注意する。怪しいメールは絶対に開かない。
- メールだけでなく、通常の郵便も同様の危険がある。住所も流出している場合は特に注意する。
- クレジットカードや銀行の使用状況に注意する。これらの情報が流出した可能性がある場合は口座やカードを作り直したほうがいい。
- 流出した個人情報をもとにクレジットカードや口座が作成される恐れがあるため、詐欺に使用されないように注意する。
- (アメリカ国民の場合)毎年送られるクレジットカードの利用レポートをよく確認する。
2011-06-02
Gmailアカウントのフィッシング攻撃
Official Google Blogで取り上げられたこの問題、日本の各メディアでも取り上げられていますね。
ただ、その記事のタイトルが「Googleへの攻撃」といったニュアンスのものもあり、セキュリティに関する情報提供の難しさを感じさせられます。Official Google Blogでもあえて「Gmail自体のセキュリティの問題ではない」と書かれていますね。
今回の問題はGmailのシステムに攻撃が加えられたということではなく、一部のユーザーがフィッシングサイトに引っかかってしまい、フィッシングサイト上でGmailにアクセスするためのIDとパスワードを入力してしまったことが原因です。攻撃者はそのIDとパスワードを利用してGmailにアクセスし、メールの転送設定を追加することでメールの内容を盗んでいた、ということです。対象となったユーザーが米政府高官や中国の政治活動家などだったことから、特定の対象を狙ったものであることが推測できます。攻撃手法についてはこちらにまとめられています(今年の2月に報告されているものです)。
この問題に対して、Googleは2段階認証(ワンタイムパスワード)を使うことを推奨しています。この方法は今回のような問題の対策としてとても有効なものです。ただ、この設定は初心者にはちょっと敷居が書く(日本国内の場合はSMSを使った認証なども使用できないため、より条件が難しくなります)、広く普及させるのはなかなか難しいと思われます。
Gmailのようなフリーメールアカウントに限らず、各プロバイダから提供されるメールアドレスでもWebメールが提供されることが一般的になっています。どこからでもWebサイトにさえつながれば利用できるという利点もあり、特にライトユーザーがWebメールを多用する傾向が強いようです。セキュリティに関する知識をそれほど持ち合わせていないユーザーを対象にする場合は、セキュリティを向上させるために設定を変更させたり、手順を増やして対応させたりするのはあまり現実的ではありません。この問題、いろいろな企業システムでも同じように直面している問題です。
企業においては、システム側の対応を進めることはもちろんのこと、「怪しいメールは開かない」「怪しいリンクはクリックしない」「機密情報はメール以外の方法(または暗号化するなどの対策を取る)でやり取りする」といった基本的なユーザー教育を徹底するのが最初の一歩かな、と思います。攻撃するのも人間なら、身を守れるのも人間、ですもんね。
2011-06-01
OATHによるワンタイムパスワードの仕様 - 3
前回は2つのワンタイムパスワードの生成方法について取り上げました。今回はいよいよ実際の生成アルゴリズムを取り上げましょう。TOTPをベースに説明します(ただ、前回も解説したように、基本的なロジックはTOTPとHOTPで同じです)。
参考としてpythonのコードも併記してみます。
※ OATHの仕様ではタイムステップとして30秒が推奨されています。
※ なお、ハッシュの算出にはSHA-1だけでなく、SHA-256やSHA-512なども使用できます。
OATHの仕様には、Javaで記述されたリファレンスコードが掲載されています。また、生成されたワンタイムパスワードの値が正しいかどうかをテストするための値のリストも載せられていますので、独自に実装した際の確認のために使用することができます。
今回説明したように、ワンタイムパスワードの生成自体はそれほど難しいものではなく(計算は少々ややこしいですが…)、スクリプト言語でも比較的簡単に実装できます。PHPやpythonなどで開発されたWebアプリケーションに組み込むことも容易ですし、スマートフォンを使ったソフトウェア・トークンもいろいろと出てきていますので、Webアプリケーションのセキュリティを高めるためにも取り組んでみるいい機会かもしれませんね。
Read More
参考としてpythonのコードも併記してみます。
1. タイムステップを考慮したカウンタの算出
TOTPの場合、カウンタはunixtimeになります。しかし、これをそのまま使うとワンタイムパスワードが毎秒変わってしまうことになり、さすがにこれは実用的ではありません。それで、ワンタイムパスワードが切り替わる間隔としてタイムステップ (Time-Step) を設定し、unixtimeをタイムステップで割った値をカウンタとします。messagetime = unixtime / timestepこれにより、タイムステップが30なら、30秒間は同じワンタイムパスワードが生成されることになります。
※ OATHの仕様ではタイムステップとして30秒が推奨されています。
2. HMAC (SHA) の算出
まず、1.で生成した値を16バイトの16進数表記に変換します(バイト数が足りない分はゼロ埋めします)。その16バイトをASCII文字列に変換したものをデータとし、パスコードをキーとしてHMACダイジェストを算出します。message = '%016X' % messagetime h = hmac.new(key, message.decode("hex_codec"), sha) d = h.digest() hmac_result = [] for c in d: hmac_result.append(ord(c))これにより、20バイトのハッシュ文字列が生成されます。この文字列の文字コードを1文字ずつ配列に格納しておきます。
※ なお、ハッシュの算出にはSHA-1だけでなく、SHA-256やSHA-512なども使用できます。
3. オフセットの算出とビット演算
2. で生成されたハッシュの最後のバイト(20バイト目)を 0xf でマスクした値をオフセットとし、そのオフセットに基づいてビット演算を行います。offset = hmac_result[19] & 0xf sn = (hmac_result[offset] & 0x7f) << 24 | \ (hmac_result[offset+1] & 0xff) << 16 | \ (hmac_result[offset+2] & 0xff) << 8 | \ (hmac_result[offset+3] & 0xff)
4. ワンタイムパスワードの出力
3. で計算された値を 10のn乗(nはワンタイムパスワードの桁数となります)で割ります。その余りがワンタイムパスワードとなります。8桁の場合はこのようになります(桁数を合わせるためにゼロ埋めが必要です)。result = '%08d' % (sn % 10**8)
OATHの仕様には、Javaで記述されたリファレンスコードが掲載されています。また、生成されたワンタイムパスワードの値が正しいかどうかをテストするための値のリストも載せられていますので、独自に実装した際の確認のために使用することができます。
今回説明したように、ワンタイムパスワードの生成自体はそれほど難しいものではなく(計算は少々ややこしいですが…)、スクリプト言語でも比較的簡単に実装できます。PHPやpythonなどで開発されたWebアプリケーションに組み込むことも容易ですし、スマートフォンを使ったソフトウェア・トークンもいろいろと出てきていますので、Webアプリケーションのセキュリティを高めるためにも取り組んでみるいい機会かもしれませんね。
登録:
投稿
(
Atom
)
Profile
- 山崎 太郎 (Taro Yamazaki)
- プラムシステムズ株式会社所属。 主にVPN(OpenVPN)やセキュリティ関連技術、Webアプリケーションを手がけています。
Page Views
Popular Posts
-
「VPNっていろいろあるけど、OpenVPNのメリットって何?」 という疑問は多くの方が持たれますよね。この点は公式サイトなどにもいろいろ書かれているのですが、実際に使ってきたユーザー側としてメリットと思う部分をまとめてみました。
-
現在ダウンロードできるOpenVPNでは、今まで認証局の構築で使用していたeasy-rsaが含まれなくなっています。 OpenVPN.netのダウンロードページ にも Note that easy-rsa is no longer bundled with OpenVPN...
-
Jan Just Keijser氏の記事「 Optimizing performance on gigabit networks 」については こちら でも概要を取り上げましたが、記事全体にいろいろなヒントが含まれていますので、全文の日本語訳を掲載しています。意訳している部分も...
-
OpenVPNでは、接続してきたクライアントのVPNアドレスは動的に割り振られます(その際に割り振られる際のアドレス範囲はOpenVPNサーバー側設定ファイルに基づきます)。特定のVPNクライアントに特定のVPNアドレスを割り振りたい場合、OpenVPNでは以下の2つの方法で設定...
-
では、いよいよiPhone構成ユーティリティでVoDの設定をしてみましょう。あ、 前の記事 での準備はきちんとやっておいてくださいね!
-
前回 は2つのワンタイムパスワードの生成方法について取り上げました。今回はいよいよ実際の生成アルゴリズムを取り上げましょう。TOTPをベースに説明します(ただ、前回も解説したように、基本的なロジックはTOTPとHOTPで同じです)。 参考としてpythonのコードも併記してみま...
-
OpenVPNはLinuxをはじめとした幅広いプラットフォームで動作実績があるのが特徴の一つです。 今回は、最近の電子工作ブームでも話題のシングルボードPC 3機種をOpenVPNサーバーとしてセットアップし、OpenVPNのVPNパフォーマンスを測定してみましょう。
-
現時点においてはマニュアルやHowToにも記載されていない(ChangeLogにちょっとだけ出てきます)あまり知られていない機能なのですが、「設定ファイルで鍵ファイルや証明書ファイルのパスを記載する」という通常の方法とは別に、「鍵ファイルや証明書ファイル内のデータをそのまま設定フ...
-
前回 はワンタイムパスワードの基本的な仕組みについて説明しました。サーバー側とクライアント側で、それぞれ共通のルールに基づいてパスワードを生成させる必要があることを取り上げましたが、今回は OATH が規定しているその生成ルールについて具体的に説明します。 ワンタ...
-
OpenVPN Connect for iOSがリリース されましたので、それを記念(?)して、OpenVPNサーバーにiPhoneから接続する手順をまとめてみましょう。
© yamata::memo 2013 . Powered by Bootstrap , WebLyb