from electron 2 web

インターネットのリソースを無駄遣いして検索におけるUXを下げてごめんなさい

圧倒的文章力のNASAでゴミみたいなチラ裏のようなメモを量産してしまい全ての"Web開発者"にごめんなさい

セキュリティ復習

ココの所記事が3つも死んで死にそうになってる大沼です。せっかく某アドオン作ったのにね。

DBは割りと行けるようになってきたけどセキュリティが辛いのでやる。

仮眠好き攻撃

初めて聞いたので調べてみる。DNS関係も好きだしね。

キャッシュDNSって聞いたことあるなと思ったらフルリゾルバのことか。

ていうか文字だけだとめっちゃわかりづらいな。某先生の神解説あってよかった。

同じドメインだけど違うホスト名をフルリゾルバにめっちゃ送りつけて(DoS目的じゃないけど)んで権威鯖が返す前に攻撃者がフルリゾルバに返すっぽい。

ん?でもたしかソルトみたいなの付けて送るから無理じゃね?あと確か最近のDNSは証明書付きって聞いたんだけど?

ソースポートランダマイゼーション

受け付けるポートを変えること。DNSは確かudpの53だけど810とか114とか使うこと。

他のポートと被った時にバグの特定がしにくそうだ。あとこのポート変わったってことはどうやって相手に伝えるのかな?

ソースポートを変えてるっぽい。宛先ポートじゃなかった。

このソースポートランダマイゼーションってやつはDNSでしか使われないっぽい。

フルリゾルバは権威鯖への送信履歴を覚えてる。ソースポートも

フルリゾルバのアドレス(図1の「FullResolver」、通常は1つ

ってどういうことなんだろ。

ソースポートと宛先ポート、宛先ドメイン、ソースドメイン、クエリID?、内容っぽい。

クエリID

うえで言ってたソルトもどきがこれっぽい。んでこのソルトもどき(クエリID)は65535通り。

現在のコンピューターやネットワークの処理能力では100万パケット程度の生成は容易であるため、攻撃は容易に成立する。

マジかよwwww死ゾ

んでこれを回避するためソースポートも変えると。ソースポートは65535のうちwellknownポートをはずすんで64000くらい。

対策としてはDNSSECを使う。あたってた。今日は冴えてる。まあDNS好きだしね。秘密のノートに4ページぐらい書いてあるしね。

ポート

そういえば色々種類あったよなとか思ったのでメモ。

なお、Unix系のOSでは、0〜1023番のポートを使用するには、通常、root権限が必要で、予約ポートとも呼ばれる。

へえ。

  • 登録済ポート番号

1024~49512。どっかのソフトとかぶるかもねって話。んなもんそれ以降だって被る可能性あるでしょ。

IANAが利便性を考えて公開しているポートらしい。

ascii.jp

  • ダイナミック/プライベートポート番号

これが頭をよぎったから調べた。

49152以降。

ローカルで遊ぶポートでありダイナミックかプライベートかとかは関係ないっぽい。

公開鍵秘密鍵共通鍵

応用受かるなら完璧にしとかなきゃいけないらしい。

公開鍵方式を使いn人が通信する時鍵の数は2n。

共通鍵方式の場合はn(n-1)/2。公式丸暗記とかまるで数学みたいだな。

通信するときにも認証局の公開鍵を使う。この目的は複合のためではなく検証の為。

証明書の中に、サーバー側の公開鍵自体もはいってる。

vpn張ってみたい。。。

3way-handshake

  • シーケンス番号とかwindowとか

タイムスタンプ

タイムビジネス認定センター|JADAC

初めて聞いた。

認証局とか証明書が「誰」が作ったかに対してタイムスタンプは「いつ」を保証する。

タイムスタンプは「タイムスタンプ認証局(TSA)」が保証する。

タイムスタンプはRFC3161で規定されてる。X509 PKI,TSP(time stamp protocol)って名前。

掲示板とかの法的証拠とかで真価を発揮しそう。あと魚拓とか。

タイムスタンプの有効期限は10年程度と長い。

電子証明書の有効期間は、通常1-3年程度であるのに対し、タイムスタンプの有効期間は10年程度(本認定制度の場合)と長く、電子文書の長期保存にタイムスタンプが有効なことが分ります。また、電子証明書は失効により有効期間が短くなることがあり得るので、完全性を確保して電子文書を保存する場合、通常電子署名とタイムスタンプとの併用が必要となります。

タイムスタンプは作成時時点の存在性、及びその後の完全性を保証します。

チャレンジレスポンス

認証要求、鯖がチャレンジ乱数を返す。クライアントがそれともともとあるパスワードとかをごちゃ混ぜにしてレスポンス。

ソルトはレインボー攻撃を避けるための鯖側のソルト。

レスポンスの生成は一方向関数などによって行われ、レスポンスだけを入手しても元のパスワードを割り出すことができないようになっている。平文のパスワードではなくチャレンジとレスポンスを送受信することにより、パスワードなどが盗聴されるのを防ぐことができる。

www.atmarkit.co.jp

レインボーテーブルはハッシュ2パスの逆引き表を圧縮したやつ

ちなみにSSLNetscape社が作ったから!!

ついでにelectronのセキュリティにも調べたけど長くなったので別にまとめた。

PS.

2段階認証とFIDO

FIDOには1.0と2.0がある。ちなみに1.0はwin10にも実装されてるらしい。

通信、デバイス、鯖の3つの部分がある。

たくさんパスワードとかを管理する必要がなくなる的な?

2段階認証、2要素認証は3つのうち2つを使う。

ユーザーが知っているもの(password)

ユーザーが所有しているもの(device)

ユーザーの特徴

大抵上2つ。deviceについてはdeviceで作成されてチャレンジとか。

twitterだとパスワード+SMS認証(デバイス)で2FAしてるな。

FIDOはファイドと読む。

FIDOにはUAFとU2Fがある。

FIDOは一切の個人情報を鯖に送らない。

FIDOによるチャレンジは

Webサイトからユーザーの端末へ「チャレンジ」と呼ばれるデータが送信される

パット見だと相当むずいんだけど極力抽象化させてユーザーにはなるべく内部を見せないような感じだ。

自分の理解のために書いてみる

1、ユーザーがサイト登録ボタンを押す。デバイス情報的なのを送る

2、サイトはデバイスに認証の方法(指紋とか)を送る。

3、オーセンティケータがユーザーを登録してコイツが秘密鍵と公開鍵を作成して公開鍵側を鯖に送る。

4、ユーザーがログインする時はオーセンティケータに認証させてオーセンティケータの中のソルトとかしたやつを解除して秘密鍵で暗号化して送る。

5、

ちょっと良くわからないから

Authentication is done by the client device proving possession of the private key to the service by signing a challenge

認証はクライアントデバイスがサービスに(サービスから帰ってきたチャレンジを署名して(レスポンス))秘密鍵を所持していることを証明することで終わります。

FIDO Alliance » Download Specifications

ブラウザ用jsapiとか青歯APIとかいろいろ決めてるんだな。

Universal 2nd Factor (U2F) Overview