作成者別アーカイブ: todkm.admin

「パスワードの定期的な変更は不要」は大ウソ、NISTの原文を読め！

先週くらいから、突然大手紙が「パスワード定期変更不要」のニュースを流し始めて、今ごろ何を言っているんだろう。

しかも単に政府が参考情報として出している資料の内容が変わっただけで、別にパスワードに関する法律があるわけでもないのに、「国が方針変更」というのは意味不明だ。

さらに言えば、定期変更を不要としたおおもとの米NISTのガイドライン「NIST Special Publication 800-63B」を読まずに書いている記事ばかり。

同NISTガイドラインのAbstractには「連邦政府機関」向けと明記されている。

もちろん「パスワード定期変更不要論」はNISTガイドライン以前の、技術者の間での議論がベースになっているけれど、まずはNISTのガイドラインが米国連邦政府機関むけであることは明記すべきだろう。

米国連邦政府機関に求められるセキュリティレベルが、無条件に、あなたの使っているシステムよりも高いと前提するのはやめるべきだ。

米国連邦政府機関なんて、まだまともなエンドポイントセキュリティ製品がない時代に「BYOD（私物の業務利用）」を認めていたくらい、セキュリティはある意味に「ゆるゆる」だ。

また、日本政府や日本のセキュリティ関連団体が、なぜNISTガイドラインを鵜呑みにする必要があるのか。

日本が欧米より高いセキュリティガイドラインを設定することに、何か問題でも？こんなところでも無条件に欧米に追従しようというわけだろうか。

もう一点、NISTガイドラインの「SHALL」「SHOULD」の使い分けが無視されている。

ガイドラインの中に定義がある。「SHALL」は逸脱を許さない必須の規定、「SHOULD」は他の選択肢を排除しない推奨だ。

「SHALL」は「～でなければいけない」、「SHOULD」は「～であるべきだがその他の選択肢も排除しない」という意味だ。

「パスワード定期変更不要論」について、NIST Special Publication 800-63Bの該当部分は「5.1.1.2 Memorized Secret Verifiers」にある以下の段落だ。

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

この段落の中だけでも必須の「SHALL」と推奨の「SHOULD」が使い分けられている。

定期的にパスワードの変更を要求することは「しないのが望ましい SHOULD NOT」としか書かれていない。

他方、この段落の中で「SHALL」になっていることがある。「認証機能が被害を受けた証拠がある場合は、パスワードの変更を強制しなければならない」という一文だ。

こちらのほうは必須なのである。

つまり、たとえばあなたの会社で、「新聞のニュースにパスワードの定期変更は不要って書いてあったし、国の方針も変わったようだから、うちの社内システムも定期変更はやめようよ」ということになったとしよう。

その場合、前提条件として「5.1.1.2」の中で「SHALL」になっていることをすべて実現する必要がある。

認証機能が被害を受けた証拠がある場合、パスワードの変更を強制しなければならないことは「SHALL」なので、認証機能の被害を検知し、即座にユーザにパスワード変更を要求するシステムか体制を整備する必要がある。こちらは必須なのだから。

それをやらずに、パスワードの定期変更だけをやめるのは、NISTの主旨に完全に反している。

もっと言えば、「5.1.1.2」のパスワードに関するガイドラインには、他にも「SHALL」がたくさんある。

いくつか抜粋する。

・パスワードは最低8文字。

・パスワードのヒントを認証前に表示してはいけない。

・よく使われるパスワードのリストを準備しておき、ユーザが使おうとしているパスワードをそのリストと対比しなければならない。

・そのリストにユーザが使おうとするパスワードが見つかった場合は、そのパスワードを拒否する理由を表示し、異なるパスワードにするようにユーザに要求しなければならない。

・認証の失敗回数を制限する機能を実装しなければならない。

・パスワードを入力させるとき、中間者攻撃を避けるために、通信の暗号化を行わなければならない。

・パスワードを蓄積するとき、一方向のハッシュ化などでオフラインの攻撃にも耐えるようにしなければならない。

・そのときの鍵は承認済みの一方向の機能を使わなければならない。

・ハッシュ化のソルトは少なくとも32ビットでなければならず、ソルトの衝突を最小化するために任意に選ばなければならない。

・ソルト値とその結果のハッシュ値はユーザごとに認証システムを使って保存しなければならない。

・ソルト値を利用する場合は、認証済みの乱数bit発生アルゴリズムを使わなければならない。

・秘密のソルト値はハッシュ化されたパスワードとは別に保存しなければならない。

これらの「SHALL」をすべて満たしたうえで、パスワードの定期変更を要求することはしない方がいいですよ（SHOULD NOT）と書いてあるのだ。

ところが日本の大手新聞や三流IT情報誌の記事は、これら必須要件である「SHALL」をぜ～んぶ無視して、「パスワード定期変更なんてしなくていいんだ！」と、都合のいい部分だけを取り上げている。英語のメディアにも同じような記事がたくさんある。

まあ、オンラインメディアなんて、その程度ですわ。

金融機関のウェブサービスは、連邦政府機関の一般業務より高いセキュリティが求められるかもしれないでしょ？

ふつうの企業で、社内の認証機能が破られたことを即座に検知して、ユーザにパスワード変更を要求する仕組みを導入してる会社なんてどれくらいあるの？

上記の「SHALL」をすべてクリアしていないなら、パスワードは定期変更しなきゃダメなんです。

総務省も一部のセキュリティー識者も、海外メディアの記事も、あてにならないので困ってしまう。

A Japanese Health Insurance Society Web Site Kosmo Communication Web Vulnerable to POODLE

Every Japanese company has its own health insurance society for employees and some IT vendors provide cloud services that naturally contains employee’s sensitive personal information, such as when you are prescribed medicine in which pharmacy.

One of such self service health insurance web portals is still vulnerable to POODLE attack found four years ago. The web portal, called Kosmo Communication Web, is provided by Daiwa Institute of Research Business Innovation, affiliate of Daiwa Securities.

Why I found this web site is vulnerable? That’s because I’m a user of this sevice. I’m working for the company, listed on Tokyo Stock Exchange first section, which is using this cloud service.

The English promotion page of Kosmo Communication Web doesn’t provide useful information while Japaneses page says more than four hundreds Japanese companies uses this cloud service to manage their employees medical history.

When you search the keywords “Kosmo web”, you will find several Japanese large companies use this cloud sevice.

This service doesn’t provide option of two factor authentication for employees to protect their sensitive data. However, the data processor Daiwa Institute of Research Business Innovation is certified with ISO27001 and provides several services concerning securities, banking and asset management.

My company doesn’t allow employees to stop processing their sensitive data on this service and didn’t request employees consents before implementing this cloud service.

This is one example of processing personal sensitive data in Japanese large companies.

When Your Android Phone App Doesn’t Work, Just Install GApps Again

If you unlock your Android phone and install custom ROM and some basic Google apps don’t work properly, just reinstall GApps in recovery mode.

The Open GApps Project

In my case Google standard phone app can make a call but cannot hang up because the calling mode screen doesn’t appear, so the only choice is restarting phone. In addition, it cannot answer any call because the screen doesn’t switch to answering mode.

So I reboot to TWRP recovery, wipe nothing and just reinstall GApps stock version. After rebooting, everything OK. No need to set up Google account or other Android settings.

Google Chromeのディベロッパーツールをカスタマイズする方法のメモ

Google ChromeでWindowsのディベロッパーツールに独自のタブ（パネル）を追加できると最近知ったので備忘のために書いておく。

Google Chrome拡張機能として作成する。

最低限のmanifest.jsonファイルは以下のとおり。permissionは、この拡張機能を実行させたいWebサイトのURLを指定する。

{
	"manifest_version": 2,
	"name": "Hoge Hoge",
	"version": "1.0",
	"devtools_page": "devtools.html",
	"permissions": [
		"https://hogehoge.com/*"
	],
	"icons" : {
		"128": "icon.png"
	}
}

ポイントはdevtools_pageにHTMLファイルを指定すること。このHTMLファイルはmanifest.json他のファイルを同じフォルダに、テキストエディタでいいので新規作成する。ファイル名は何でもいい。ここでは分かりやすくdevtools.htmlという名前にした。

そしてそのdevtools.htmlの中身は以下のとおり。

<!doctype html>
<html>
  <head>
    <script src="./devtools.js"></script>
  </head>
  <body>
  </body>
</html>

何もしていない。ただ同じフォルダにあるdevtools.jsというJavaScriptを呼び出しているだけ。名前はdevtools.jsでなくてもいいが分かりやすいようにこうしておく。

そのdevtools.jsの中身で、パネルを作成することになる。

chrome.devtools.panels.create(  
	"HogeHogePanel",
	"", // icon画像を指定できる
	"./panel.html",
	(panel) => {} // callback
);

このJavaScriptはGoogleディベロッパーツールのElements、Console、Sources、Network等々のタブ（パネル）に、自分の好きなパネルを追加している。

chrome.devtoolsというのはGoogleが提供しているGoogleディベロッパーツールAPIで、Google拡張機能からはすでに存在するオブジェクトとしていつでも呼び出せる。

ここではchrome.devtools.panelsのcreateメソッドを呼び出して、Elements、Console、Sources、Network等々のパネルに、もう1枚パネルを新規作成している。

1つ目の引数がパネルのタイトル。ElementsパネルならElements、ConsoleパネルならConsoleにあたる名前。好きな名前をつければいい。ここではHogeHogePanelという名前にした。
2つ目はアイコンを指定できるが、なくていい。
3つ目がポイント。この拡張機能のフォルダ内に、テキストエディタでも何でも良いのでpanel.htmlというHTMLファイルを作成して指定すればいい。ファイル名はpanel.htmlでなくても何でもいい。
4つ目はコールバック関数の指定だが、筆者は何に使うのか分からなかった。指定なしでもここから書くことは実現できる。

ではそのpanel.htmlには何を書けばいいか。

<!DOCTYPE html>  
<html>  
  <body>
    <div id="container"></div>
    <script src="./panel.js"></script>
  </body>
</html>

このHTMLも基本的にpanel.jsというJavaScriptを呼び出しているだけ。中身は用途によっていろいろだが、ここではpanel.jsの実行結果をこのHTMLに動的に表示させたいので、そのためのコンテナとしてdivタグでcontainerというidの容れ物を作っておくことにする。

ここまでで準備ができた。Googleディベロッパーツールに独自に追加したHogeHogePanelというパネルに、このpanel.htmlが表示され、panel.jsの実行結果をcontainerにJavaScriptで動的に書き込めば、panel.jsの実行結果を動的に確認できるパネルが出来上がる。

あとはpanel.jsにやりたいことをひたすらコーディングしていく。

たとえばブラウザで読み込んだページが、WebサーバにGETメソッドで要求しているデータのURLをすべて列挙する、ネットワークアナライザ的なことがやりたけれは、chrome.devtools.networkというオブジェクトのonRequestFinishedメッソドを使って以下のように書けばいいらしい。

chrome.devtools.network.onRequestFinished.addListener(
	function(request) {
		var geturl = request.request.url;
	}
);

処理はWebページを読み込みつつ非同期で実行されるので、Webサイトへのデータ要求が終わるたびに関数が呼び出されるように、addListenerでリスナーを追加、そのリスナーの中にonRequestFinished、つまりデータ要求が終わるごとに呼び出される関数を書く。

その関数にはデータ要求の結果、戻ってきたデータがrequestオブジェクトとして渡されるので、それを引数にして、無名関数として記述する。 function(request)の部分がそれにあたる。

あとはこのrequestオブジェクトにたくさんある属性の中から、取り出したいデータを取れば良い。

ここでは戻ってきたデータの中に含まれるURLリンクアドレスを取り出したいので、request.request.urlとし、アドレスの文字列をgetrulという変数に代入している。（geturlという変数名は適当に付けただけなので、何でもいい）

Google ChromeがWebサーバに要求しているURLを列挙して何がうれしいのかというと、Google ChromeでWebページを表示させた時に表面上見えているデータ以外に、裏側でそのWebページがWebサーバに要求しているデータのURLアドレスを取り出せるから。

WebページはWebサーバからもどってきたデータをそのまま表示せずに、いったんJavaScript等で加工してからWebページを組み立てて表示させていることがほとんどだが、裏側で要求しているデータを生のままつかまえたい場合は、この方法が役立つ。

panel.jsの中身を地道にコーディングして、処理結果をpanel.htmlに表示するようにできれば、あとは目的のWebページを開いて、かつGoogleディベロッパーツールの画面を、WindowsならCtrl+Shift+Iで表示させればいいだけ。

そうするといちばん右側に、自分の作った「HogeHogePanel」というタブでパネルが追加されている。そのパネルはpanel.htmlなので、そこに自分の欲しいデータが書き出される。

ただ、じゃあpanel.jsがうまく動いているかどうかは、どうやってデバッグすればいいの？という話になるが、それもGoogleディベロッパーツールを使えばいい。

自分が新規作成したHogeHogePanelの動作を確かめるために、そのパネルを表示させた状態で、再びCtrl+Shift+Iを押すと、もう一つGoogleディベロッパーツールが開く。

この2つ目のGoogleディベロッパーツールは、最初に開いたWebページではなく、自分が作ったHogeHogePanelに対するGoogleディベロッパーツールなので、panel.jsに何かエラーがあれば、こちらの2つ目のGoogleディベロッパーツールのConsoleタブにエラー表示される。

なので二重に開いた2つ目のGoogleディベロッパーツールのConsoleタブを見ながら、panel.jsをデバッグできる。

…といったことができるのを、つい最近知った。

VLC media player cannot play some URLs of YouTube movies

VLC media player forum provides a solution for this problem, that’s to copy an updated youtube.lua file to /VideoLAN/VLC/lua/playlist/. However, this doesn’t solve the problem any more in March 2018.

If you get the error message containing word “MRL”, the true solution is to change configurations of Windows firewall.

In case of Windows 7/10, go to advanced settings of Windows firewall and change both of Inbound rules and Outbound rules of all “VLC media player” profiles into “Enabled=Yes” and “Action=Allow”. This means every profile of VLC media player will be turned into green.