hidekiy blog

潔癖な方は外出先でちょっとだけ使った Wi-Fi プロファイルなどもう二度と使うことのないことがはっきりしている Wi-Fi プロファイルを削除したいと考えると思います。 しかし Windows 8 の標準の Wi-Fi 接続インターフェースでは通信エリア外のアクセスポイントの設定は表に現れず削除する方法がなくなってしまい大変困りました。仕方なくヘルプを検索すると、 ワイヤレス ネットワーク プロファイルを管理する を発見し、コマンドラインインターフェースを使えという説明を得て無事削除できました。 ネットワークの新機能 を読むと接続プロファイルの優先度設定を抜本的に改善して操作用の GUI すら要らない状態まで持って行けたという感じに読めますが、ちゃんと消せるようになってた方が心の平穏を保てると思います。 他にもヘルプで言及されていない注意点があり、PC 設定の同期をオンにした状態で Wi-Fi プロファイルを削除しても、同期機能がそそくさと復活させてくれるので、あらかじめ同期機能全体もしくはパスワードの同期機能を切る必要があるようです。この動作 (エントリの削除を紛失と同じものとして処理する) はバグっぽいので今後のアップデートに期待します。

Windows 8 の新機能である PC 設定の同期機能でサーバー側に保存されたデータを削除する方法は、こちらの少し面白いタイトルの公式情報ページで案内されています。 PC 間で設定を同期する必要があるかどうか - Microsoft Windows 少し下の方の [すべての設定の同期を停止するには] を押して出てくる文書の一番下にある 個人設定をクラウドから削除します をクリックすると、SkyDrive のそれっぽいページに遷移します。設定データが存在している Microsoft ID でログインして削除を行ってください。 削除の確認ページで注意されているとおり、この削除機能はサーバー側で恒久的に同期機能を停止する機能ではないので、情報の再アップロードを防ぐには全てのPCの設定の同期設定を無効にする必要があります。

あるユーザーが事前に設定したパスワードを入力したこと確認するための情報を安全に保管するには、保管する際に 一方向性関数 を通せばよいことは誰もがご存知だと思います。この一方向性関数をより強力 (より計算時間がかかる) なものに更新しようとする際、ユーザーからの生のパスワードが必要なのかについて議論します。ソルトの有効性については議論しません。 いまもしイテレーション回数を増やすことができるならば、パスワード用ハッシュ関数のストレッチ度を上げることでパスワードハッシュ値へのオフライン攻撃を企む攻撃者に必要となる計算能力を世の中の進歩に合わせて増やしていくことができるので、安心してユーザーのパスワードを預かることができそうです。 例えば素朴なところで f(x) = sha256(sha256(sha256(x))) (ただし x をユーザーが入力した生のパスワードとする) のように sha256 関数に n 回通すような関数を用いているとします。この関数はユーザーからの生のパスワードを得ずとも、既に n 回通したハッシュ値にさらに m 回 sha256 に通してイテレーション回数 n + m のより強固なハッシュ値にアップグレードできるので、イテレーション回数は好きなだけ更新可能と言えます。 次に既にパラメータにイテレーション回数を持っているような鍵導出関数 PBKDF2 を使う場合でも、f(x) = PBKDF2(PBKDF2(x, salt, 100), salt, 10000) のような一方向性関数を考えれば先ほどと同様に、イテレーション回数 100 から、10100 ほどにハッシュ値の強度を強化できると言えます。 残念なことに PBKDF2(PBKDF2(x, salt, 100), salt, 10000) = PBKDF2(x, salt, 10100) みたいにはならないようですが、どの一方向性関数を通したハッシュ値なのかという情報は保持するべきで (例えば $1$saltsalt$hashhashhashhashhash の形式の 1 はハッシュ関数の種類)、保持すれば関数の使い分けに問題は無いでしょう。 またもしユーザーから入力されたパスワードを既知とするならば、ユーザー認証後に好きな一方向性関数でハッシュ値を導出しなおすことが...

C:\ESD\Windows が存在するのにシステムから認識されなくなってしまった場合、以下のレジストリ断片を結合すると再度認識されるようになりました。 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\WebSetup] "ImageIndex"=dword:00000001 "ImageLocation"="C:\\ESD\\Windows\\sources\\install.esd" "MediaLocation"="C:\\ESD\\Windows" このまま foobar.reg などと保存して結合できます。 Windows ESD インストールファイル C:\ESD\Windows はインストールディスクの内容をコピーしたり、 Windows8-Setup.exe を実行後プロダクトキーを入力して再ダウンロードすることで再取得できます。 Windows8-Setup.exe は自動的に既存の C:\ESD\Windows とレジストリの WebSetup キーをクリアするようなので既に利用可能な Windows ESD インストールファイルを壊したくない人は実行に注意してください。 関連情報 プロダクト キーのみを使用して Windows 8 にアップグレードする方法 - Microsoft Windows hidekiy blog: Windows 8 のリフレッシュ機能を試してみました

Node.js は基本的にはサーバーサイドで使うものなので、まともなホスティング業者のサービスを利用する限りは通信環境についてそこまでセキュリティリスクは高くないと思います。しかしナントカ API に https でアクセスしているから安全に違いないと信じ込むのは考え物で、 HTTPS Node.js Manual & Documentation - https.request(options, callback) rejectUnauthorized: If true, the server certificate is verified against the list of supplied CAs. An 'error' event is emitted if verification fails. Verification happens at the connection level, before the HTTP request is sent. Default false. を見ると分かりますが、Node.js v0.8.18 時点で未だに rejectUnauthorized のデフォルト値が false なのでデフォルトのまま使うと中間者攻撃の余地があります。 証明書の検証をしない SSL なんて存在しない方がましだと思うので、きちんと検証できているかどうかを必ず確認しましょう。例えば https://www.l.google.com/ など接続はできて証明書の検証に失敗するアドレスにリクエストして、エラーになることを確認すると簡単だと思います。さらに心配性な方は Node.js が正当なルート証明書を使っているかどうかも調べておきましょう。

Windows 8 Pro にしたら一緒に付いてきた、保護されないアクセスからデータを守ってくれるらしい BitLocker を有効にしてみました。 保護されないアクセスとは例えば以下のようなアクセス許可が正常に適用されない状況です。 LiveCD で起動して USB メモリにデータをコピーして持って帰る HDD を取り外して持ち出し、別の OS からアクセス許可を無視してオフラインアクセスする オフラインで OS にルートキットを秘密裏に書き込んでおきパスワードを盗む 暗号化の処理について、作業を中断することなくバックグラウンドで処理が進行し、暗号化が途中まで完了しているという状態が許容されているようです (暗号化進行中にシャットダウンしても大丈夫)。暗号化も Low-Priority I/O でおしとやかに処理されるのでとても良くできている印象を受けました。 BitLocker による保護とは意図したとおりの OS のみがディスクにアクセスするよう制限することにあるので、TPM 付きのマシンなら同じマシンで起動していることを自動的に確認できるので起動時のパスワード入力は無しにできます (PIN も設定可能)。TPM 無しの場合でも USB メモリもしくはパスワードでも BitLocker を有効にできます (要ポリシー変更) また起動時に起動用のパスワードを打ち込めば必ずフルアクセス出来るようになるのではなく、正常に保護されない恐れのあるアクセス (正規の Windows 以外からアクセスされる場合) の時は回復キー (数字48桁) を要求されます。この理由はフルコントロール可能な回復キーは管理者が管理し、標準ユーザー権限のユーザーは正規の認証を経ることになっているからだと思います。 この仕組みはデータが複数個に増えるわけではなく、データを暗号化する鍵を別々の方法で暗号化して保管することで実現されています。内部で実際にデータを暗号化しているマスターキーは目に見える形では表示されません。 WinRE を使いたい時も回復キーを要求され少しめんどくさいですが、あらかじめ Windows 内で「保護の中断」を管理者権限で実行しておくと回復キー不要でアクセスできます。BIOS のアップデートも回復キーを要求されるはずなので、行う際は同様に保...

Windows 本体が起動しない場合は WinRE もしくはインストールメディアから利用可能なスタートアップ修復によって自動修復することができます。しかしインストール済みの WinRE 自体が起動しなくなった場合は自分で修理する必要があるようです。 winre.win の入ったパーティーションの開始位置をずらした場合や、BCD (ブート構成データ) から WinRE 自体のエントリをうっかり消去してしまった場合は、bootrec /rebuildbcd を使っても自動修復できません。そこで bcdedit を使ってちまちま再設定するのではなく reagentc を使うと以下の手順で簡単に再設定出来ることが分かりました。 winre.win というイメージをインストールディスクから抽出するか設置先から救出してきて、C:\Windows\System32\Recovery に戻します reagentc /enable というコマンドで BCD エントリとディスクイメージの設置 (winre.win のコピーではなく移動ｗ) が完了します 内部状態 ReAgent.xml には設定していると記録されていて、実際には BCD エントリが存在していない矛盾した状態になっているとエラーが出ます。その場合は ReAgent.xml を初期化すると無事動きます。 初期状態の ReAgent.xml は C:\Windows\WinSxS 内のどこかにあるようなので検索してみてください。手元の Windows 8 では C:\Windows\WinSxS\x86_microsoft-windows-winre-recoveryagent_... みたいな所にありました。 Windows 回復環境の現在の設定状況については reagentc /info で調べることができ、WinRE の無効化は reagentc /disable で行えます。 壊れる原因について Windows において MBR 経由の従来型のブート方式ではパーティーションごとの UUID 的な何かではなく、ディスク内でのパーティーションの開始位置によってどの OS を起動するべきかを BCD 内で指定しています。 よって gparted などで C:\Windows の入った領域の開始位...