はてなブックマーク

（サーバでない）DNSリゾルバ 全てのPCやブラウザアプリに内蔵されているツール。サーバではない。普通後述するフルリゾルバではなく、単にドメイン名をISPのDNSキャッシュサーバに問い合わせるだけ。 DNSフルリゾルバ・DNSキャッシュサーバ ドメイン名をルートからたどって最終的に解決するツールを内蔵したサーバ。ISPが提供するサーバーはフルリゾルバ機能がオンになっている。キャッシュ機能を持つため、キャッシュサーバとも呼ばれる。プロバイダと契約すると、書面やDHCP経由で提供されるDNSサーバはこれのことを指す。もちろん自分のPCに内蔵して名前解決を高速化することも出来る。 ドメイン名とIPの対応関係を変える権限は無いので無権限Non-authorizedサーバや、キャッシュからの応答を無権限 Non-authorized answerと呼ばれる。 DNS権威サーバ ドメイン名の情報を提供

VPSプロバイダのDigitalOceanがシンガポールリージョンをリリースした。 DigitalOceanは標準でSSD、snapshotに対応、時間課金なのでAnsibleのテスト環境として利用している。ストレージがSSDだとテスト時間が大部分ネットワークレイテンシなので確認してみた。 レイテンシ 国内からのtracerouteは良い時に85msくらい。 AS133165 NTT経由のときはいいけれど、telia.netに行ってしまうと西海岸経由で悲惨なことになる。経路依存なので、必要な場所から ping speedtest-sgp1.digitalocean.com してチェックしたほうが良さそう。 7 xe-7-4.a16.tokyjp01.jp.ra.gin.ntt.net (61.213.145.93) 12.994 ms 13.205 ms 13.757 ms 8 ae-6.

いかにしてパスワード認証を脆弱にするか。プログラミング黎明期からずっとデベロッパーの頭を悩ませ続ける問題です。 ここでは脆弱なパスワード認証を実現するための方法を紹介します。 パスワード自動入力の禁止 不届きなブラウザがパスワードを記憶してしまうことがあります。 パスワードは間違いの無いように、ひともじひともじ、人間が入力するべきです。 <input name="pw" type="password" autocomplete="off" /> とするのは常識ですね。ブラウザのパスワード管理機能より、脳内の文字列の方がずっと安心です。 フォームを動的生成、AjaxでPOST cursor: textスタイルで偽input などで、ブラウザのパスワード保存をスキップする方法もあります。 パスワード貼り付けの禁止 貼り付けも自動入力と同罪です。onpaste属性を利用して <input nam

次の記事でMarkDownで書きなおしてみた 理由が記載されていない設定例しか見当たらなかったのでメモしておく。2013/9時点の理解。 Apacheでも名前の読替えで全て同じ設定が可能。 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers AESGCM:SHA384:SHA256:@STRENGTH:RC4:HIGH:!EXP:!LOW:!MD5:!aNULL:!eNULL:!KRB5:!PSK:!SRP;ssl_prefer_server_ciphers on; ssl_stapling on; add_header Strict-Transport-Security max-age=31536000; 暗号方式は ・RC4 ＞ CBC （BEASTの方が重大と考える）なら、上記の通り。 ・CBC ＞ RC4 （RC4の危殆化が

ファイルシステム上のエンコード 最近のファイルシステムはユニコードで決め打ちされているので考慮する必要はない。FATなどの古いファイルシステムでのみ問題になる。（厳密にはUCS-2でUTF-16非対応だったりするけど。） FAT32ショートファイル名ならShift_JISなど（正確にはcp932）。ロングファイル名（8.3形式でない名前）は後付け規格なので問題ない。

SSLサーバー設定のテスト目的で使っている人も多いと思う Qualus Security Labsの記事 https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat で、SSL CheckerからBEAST脆弱性の判定(TLS1.0以下でCBCモードを使っている)を外す、というのが有ったのでメモ。 BEASTは成功すると数分から数十秒程度でクライアントのセッションが解読されるため、非常に危険なものと考えられている（orた）。 TLSv1.0以前ののCBCモードでは、セッションを再利用してリクエストを送る際、最後に送信された暗号ブロックが、次のHTTPリクエストの最初のブロックのIVとして使われている。攻撃者が送信済みの最後の暗号ブロックを傍受した後で、リクエストの先頭ブロックにあたる平

Bitcoinでは公開アドレス間の送金を全て検証することで、仮想通貨としての一貫性 ・資金を持っている人だけが送金できる ・架空の資金を送金することはできない（残金ゼロなのに送金したり、同じ資金を二人対して使うことができない） を実現している。 まず前者は非対称暗号による署名で実現している。 まず財布を作りたいユーザは秘密鍵と公開鍵をつくる。このペアから更に、アドレスと呼ばれる使い捨ての財布を生成する。 この公開されるアドレスからの送金情報を、秘密鍵で署名しP2Pネットワークに放流することで、送金を宣言できる。 検証するには、送金元アドレスに対応する公開鍵で送金情報を検証すれば良い。 つぎに架空の送金や二重送金はチェックは少し複雑になる。これはハッシュブロックのチェーンと呼ばれる一貫性のある送金情報のデータベースをP2Pネットワーク全体で維持することで実現される。 さらにこのときこの一貫性

Djangoフレームワークのドキュメントを信用しない、大抵の開発者には無関係な話。 PythonのウェブフレームワークDjangoは他のフレームワーク同様、cookieによるセッション機能が実装されている。 セッションのハイジャック手法の一つにSession Fixation攻撃があり、対策としては、セッションIDに紐ついた権限の変更（または昇格）時にセッションIDを再生成するのが一般的と思う。 DjangoのSession周りのドキュメントにも、Session Fixation対策が示唆されているのだが、あたかもフレームワーク側で対策済みかのように書かれている。 In order to prevent session fixation attacks, sessions keys that don’t exist are regenerated: しかし、有効なセッションIDは攻撃者が普

データを暗号化して保存している、と謳うオンラインストレージサービスは多い。 ウェブサイトでは直接ファイルを閲覧できず、ユーザーのPCやスマートフォンの内部で暗号化してからサーバーに送るので安全性が高い、と主張している場合もある。 しかし、オンラインストレージの多くはウェブサイトのログインにパスワードを要求したり、ログインするだけでファイルにアクセスできたり、パスワードを忘れた時のためのリセット機能があったりする。こういったサービスでは、サービスを提供する側が、ユーザーの保存したファイルを秘密裏に閲覧することができ、ユーザーにプライバシーはない。強制力を持つ政府機関が命令すれば、サービス提供者はデータを復号して提供せざるをえないだろう。 だれかに見られても困らないデータを置くには便利なサービスだが、多数の個人情報や企業秘密のように、第三者への漏洩その自体が重大なデータを保存する場所としては不

少し思う所があってメモ OpenIDが出来る事 ユーザーが「あるOpenIDプロバイダにアカウントを持っていること」をウェブアプリに証明する 基本的にはたったこれだけ。OAuthとの違いウェブアプリに何らかの権限や、ランダム生成された識別子以上の情報を渡すことはない。 OpenIDログインを利用するウェブアプリ（リライングパーティー）が知ることができるのは ・ユーザーがどのプロバイダのIDを持っているか ・ユーザーの所有する識別子（乱数） OpenIDを発行する側（OpenIDプロバイダと呼ばれる）が知ることが出来るのは、 ・ユーザーがどのウェブアプリ（リライングパーティーと呼ばれる）にアクセスしたか だけになる。正しく実装されたOpenIDでは、OpenIDプロバイダにどのような情報が登録されているか（メールアドレスやパスワードなど）は、リライングパーティにはわたらない。 仕組み Ope

ロリポップでの大規模なWordPressサイトの改竄について http://lolipop.jp/info/news/4149/ ロリポップからのリリースでは、管理パスワードとログインへのアクセス制限の強化を推奨して、パーミッションの変更と全体のウイルスチェックを行うとしている。WordPressそのもののアップデートはマニュアルに方法が記載されているものの、リリースでは触れられていない。 このことから、被害が大きくなったのは、ロリポップの提供していたWordPressのインストール手順に問題があり、wp-config.phpなどのファイルのパーミッションが不適切だったためではないかと推察出来る。 いくつかのアカウントだけWordPressの管理パスワードが突破される、というのであれば、世界中でほぼいつでも起こっている。 もし、あるユーザーの管理パスワードが脆弱で推測することが出来てしまう

Androidスマートフォンでのアプリの通信をブロックするアプリの動作原理分類 プロセスID/iptables方式 低負荷・アプリ別・root必須 ・DroidWall https://play.google.com/store/apps/details?id=com.googlecode.droidwall.free&hl=ja アプリごとにiptables（AndroidOSのベースのLinuxに組み込まれているファイアーウォール）でフィルタする。 iptableを制御するためにroot化が必要で、アプリのIDからフィルタルールを動的生成するために、常駐して実行中アプリを監視する必要がある。原理的に起動直後の通信を取りこぼす場合がある。 フィルタリング自体はAndroid自体アプリではなく、OS側が行なってくれるので、CPU負荷は少ない。 接続先や内容でフィルタすることも不可能ではない

https://twitter.com/a4lg/status/279543990972461056 http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ あたり経由でカーネルのBtrfs実装に関するHashDoSの話。を経由して SipHash https://www.131002.net/siphash/ について流し読みした。何故暗号論的ハッシュが必要か指摘していたのでめも。 SipHashは、HashDoS耐性のある高速ハッシュアルゴリズムとして使える暗号論的擬似乱数生成器。 高速性は主に、 ・128bitの生成鍵（salt相当）からコストの大きな拡張関数を使わずそのまま初期状態を作れる。 ・ブロックは64bit単位と小さく、状態空間は64bitx4 ・ルックアップテーブルを使わない あたりで実現されていて、 一方で暗号論的

http://extensions.fenrir-inc.com/dev.html ほぼgreasemonkey互換。HTTPS上でも動作する。 .slex.jsを拡張子にすることで任意ドメインからの自動インストールが可能。ユーザーは悪意あるスクリプトを間違ってインストールしないよう注意が必要。 scriptロードタイミングはwindow.onloadの後なので、再描写が必ず生じてしまう。 例えばDOMの除去は透明化などボックス配置の再描写が起こらないよう注意しないと、ユーザーの操作を妨げる

Keccakをもう少しよく見てみた感想。スポンジ関数はなるほどよくできている。 以前のエントリ、 Keccak自体は「SHA-3に選出されたKaccakのスポンジ関数方式」http://causeless.seesaa.net/article/295263150.html を参照。 強衝突耐性 ハッシュCについて、C=H(M1)=H(M2)となる異なる2つのメッセージM1とM2を推定できないこと。 言い換えると、秘密のメッセージM1のハッシュC1=H(M1)について、C1だけが与えられた時、H(M2)==C1になるようなメッセージM2を推定できないこと。

前エントリの続き。プラス、平文パスワードを復号できる必要性が、某氏に理解してもらえなかったようなので。 一般に、OSサポートの無いサードパーティの認証ソフトウェアは、平文のパスワードを何らかの方法で復号する必要がある。(追記：もし平文パスワード無しにログインできるなら、OSの認証機構それ自体が脆弱であり、考慮する意味が無い。) つまり「暗号化されたパスワード」という、総当りで簡単に平文を得られる可能性の高いデータを保持する必要があり、十分なパディングなど総当り耐性を高める適切な暗号化を施す必要がある。 暗号専用ハードウェアなどに保存されていたり、十分なDRMで見つからないよう保護されているならともかく、windowsレジストリなどの他のユーザからアクセス出来る場所に置くなんて論外だ。そのうえ、件の認証ソフトウェアは暗号化方式が酷かった。（恐らく56bit鍵だが直ぐ分かったということなので、

UPEK Protector Suiteなる指紋認証が、あまりにも馬鹿馬鹿しい実装だったらしいので解説しておく。 http://blog.crackpassword.com/2012/08/upek-fingerprint-readers-a-huge-security-hole/ 生体認証は ・生体データが本当に生体から得られているかチェック（例えば偽造指紋スタンプではなく生きた指かどうか） ・生体データから得られる鍵が十分な長さを持つ（他の人と一致しない） ・認証プログラム自体が保護されている（ブルートフォース対策） ことの組回せで成り立っている。 正しく実装すれば、生体データから鍵を作り、秘密データを復号することで、秘密データを安全に復元できる。 このうち生体データには、ノイズ以外にも体調・成長による変化といったゆらぎがある為、十分大きな鍵を作ることは難しい。 普及レベルに実用的な生

CSRFはユーザーに意図せず他のサイトの機能を使わせてしまう攻撃だ。 対策が不完全だと例えば、とある掲示板のリンクをクリックしたら、twitterで罵詈雑言を投稿してしまった、なんてことが起こる。 twitterでは、”いまどうしてる?”という投稿確認ページを入れ、”投稿内容を確認したユーザー”と”投稿内容をツイートボタンを押したユーザー”と”twitterが認識しているユーザー”が一致することを保証して回避している。 この対策にはワンタイムトークンが必要になる。ワンタイムトークンの原理は省略。いろんなところで対策自体はすでに十分述べられている。（追記：正しいCSRF対策のまとめ2012年版  http://causeless.seesaa.net/article/288690661.html でいくらか解説しました） ワンタイムトークンを正しく実装すると、サービス提供側からみれば完全にC

SHA-3コンペで選出されたKaccakは、旧来の構造とは異なるスポンジ関数という考え方で構築されている。 古い設計のハッシュ関数は、入力圧縮関数、内部状態バッファ、撹拌関数で構成されていた。（丸めやパディングのような雑多な処理は略す） 入力圧縮関数は、撹拌関数の呼び出し回数を減らすため、また前処理として大きな入力ブロックを内部状態サイズ以下に不可逆に縮めるために使われ、 可能な限り撹拌関数の対象となる内部状態サイズ＝必要レジスタ数を小さくして、その分撹拌関数一回あたりの複雑性を高めることで安全性を担保しようとした。 http://sponge.noekeon.org/ 一方スポンジ関数方式では、大きな内部状態＝スポンジを用い、複雑な圧縮関数を不要にする。入力は単に、内部状態の一部（例えばKeccakでは1600bit中の1024bit）にXORするような方法で行われる。最後に出力圧縮関数

ブロック目的などで度々編集するhostsファイルに、悪意あるIPが入ると、例えばgoogle.comを攻撃者のサーバIPに向ける、というような場合があるので、注意する必要がある、という話。 ウイルス対策ソフトのブラックリストに間違った情報が入ったら問題が起こる、というのと同じなので、信頼出来ないソフトやhostsファイルを使うな、という趣旨の話でまったくもってそのとおり。

Androidスマートフォンで広告をブロックしようとすると、root化してadawayのようなhostsファイル変更が必要。そう思っていた時期が僕にもありました。

そしてその手段としては iframeとjavascriptによってGETやPOSTをユーザーのクリックなしにエミュレートするcssで偽装したiframeによって、ユーザーが意図しないクリックを行うよう誘導するscriptタグによってJSONや部分的にjavascriptとして解釈可能なページを（攻撃者のサイトのページ内に）読み込むflashなどを使ってヘッダをエミュレートしたリクエストをブラウザ経由で行うがある。 他の手法はほとんどブラウザ側のsameoriginポリシー（ほかドメインに対するjavascriptでのajax要求は禁止される）で排除されるはずである。 これら全てを回避する方法として 何らかの処理を起動するような、ユーザのクリック（＝意思あるいは同意）を確認すべき全ての画面遷移とその前後で（ログインパスワード入力フォームを含む）で、ワンタイムトークンを発行・検証する。ワンタイ