調べてみた＞「PaloAlto Networks製品のSAML認証に危険度最大の脆弱性米サイバー軍も注意喚起」
去る7月1日に次のような記事が流れてきました。 ただ、この記事からだけだと、結局どういう脆弱性なのかわかりませんし、Palo Alto Networks のサイトの当該ページに行っても同様です。ここのところ忙しくてなかなか手が回らなかったのですが、今日土曜日は仕事をしないと決めていたのでちょっと調べてみました。といっても、他の文献をあたっただけですが。 その中で詳しくて良いと思ったのが、tenableの解説です。 攻撃成功の前提条件 それによると、この攻撃が成功するためには次の２つの前提条件があります。 SAML認証をおこなっていること。IdPの証明書の検証を行わない設定になっていること。 (図1) SAML Identity Provider Server Profile configuration画面 (Source) tenable 「IdPの証明書の検証を行わないなってことあるの
印鑑業界「代理決済」のメリットを強調。デジタル法案骨抜きに？
TV東京モーサテ「“デジタル法案”骨抜きに？ 印鑑業界が反発」によると、3月7日に自民党が部会で了承した、行政手続きの100％オンライン化を目指す「デジタル手続法案」からは、当初案に入っていた法人を設立する際に必要な印鑑の届け出の義務化をなくす案が、印鑑業界の反発などを受けて見送られましたとのことです 。ただ夏の参議院選挙後の臨時国会には、再び押印の簡略化に向けた議論が行われるとみられるとのことです。 印刷業界から提出された要望書がこれです。 『デジタル・ガバメント実行計画』に対する要望書」 これによると、 当該の計画書には、行政手続きをオンライン化する上で大きく以下の3点につきまして印鑑不要となる施策を考えておられるようですが、現在、日本国民が使用している印章を、製造、販売する業界団体としてこれを看過することは出来ません。 ① 行政手続きにおける本人確認での押印の見直し。［計画書4.2
「Initiative Q」に対するわたしの考え方 – @_Nat Zone
いろいろと「Q」が飛んでいる「Initiative Q」に関する私の考えを述べます。 Initiative Q は、クレジットカードなどの既存決済システムを引きずらない、次世代の決済ネットワークをデジタル通貨ベースで作ろうという試みです。ある意味、仮想通貨にも近いようにも思われますが、Bitcoinなどとはアプローチが全く異なります。特徴は以下のようになります。 1. トラスト・チェーンの生成 親が子供の本人性を確認し、子供が孫の本人性を確認していくという、「トラスト・チェーン」を作ります。これは、匿名性を重んじたビットコインなどとは真逆のアプローチで、正しく本人確認をして行くときの定石です。 2. ソーシャル・グラフを使った急速な拡大による「にわ・たま問題」の解決 同時に、初期メンバーに対してリワードを約束することによって、急速に広げることを行っています。これはDropboxなどが当初や
セミナー：企業にとっての実践的プライバシー保護～個人情報保護法は免罪符にはならない
明日3/2、OpenID BizDay #8 で、「企業にとっての実践的プライバシー保護の考慮点」について、新潟大学の鈴木正朝教授と、産総研の高木浩光先生をゲストにお迎えして座談会を行います。わたしが司会者としていろいろ質問していく中で、企業活動として、プライバシーにどのように向き合っていったら良いのかということを浮かび上がらせて行くことができればと思っています。ちなみに、OpenIDファウンデーション・ジャパンでなんでこんなことやるかというと、OpenIDというのは、同意取得のフレームワーク＋属性提供のフレームワークだからですね。 予定は未定にしてしばしば変更す、ですが、今のところ以下の様なことをお聞きする予定です。これだけ見ても、ワクワクするでしょ？！ あ、ちなみに、有料イベントです。イベント申込みはこちら。 Q.1 個人情報保護法（今年改正予定）、刑法、消費者契約法、債権法（今年改正
API Days Berlin 2017 プレゼンテーション
去る11月8日に、ドイツ・ベルリンで行われた「APIDays Berlin 2017: Banking APIs and PSD2 — The finish line for PSD2 and Open Banking」で講演を行ってきました。 その時のスライドです。 セッション中幾つかの質問が出てきました。 Q.1 codeとstateを保護することの意味は? A.1 RFC6749では、認可サーバーは認可応答としてcodeとstateを返します。この返答を改変から保護するには、これらに署名を施す必要があります。分離署名(detatched signature)はこれらのパラメータの値のハッシュをペイロードに入れ、署名を作成し、これらを返答と一緒に送ることに実現します。この分離署名のことを ID Tokenと呼びます。名前はあまり良くないのですが、仕方ありませんね。 Q.2 どうしてst
EU司法裁判所判断：IPアドレスは個人情報だがログなどへの保存は合法～Legitimate Interest
Business Newsline日本語版『EU: IPアドレスも個人情報とする新判断・承諾なしでのアクセスログの保管は違法に』(2016/10/20) <http://business.newsln.jp/news/201610201826390000.html> (2016/10/21取得)Der Standard「EuGH entscheidet über Speicherung von IP-Adressen」(2016-10-18)<http://derstandard.at/2000046081816/EuGH-entscheidet-ueber-Speicherung-von-IP-Adressen> (2016-10-21取得) ちなみに、日本の経済団体の方々へ。 もう何年も前から言い続けてるけど、法改正にあたっては、個人情報の範囲を絞ることを狙うのではなく（←国際的な趨勢
OAuthに対するWPAD/PAC攻撃と対策
8月3日のBlackhat 2016で発表された、HTTPSのURLが読めるというWPAD/PAC Attack1、なるほどねぇ、と思わせるアタックですな。 HTTPS自身を攻撃するわけじゃなくて、HTTPSのhostに対するproxy resolveの時に、PACファイルを使ってURLの内容をフィルタリングして攻撃者のホストに送るというやり口。 毎回proxy resolveが走るブラウザ（例：Firefox, Chrome）とそうでないブラウザがあって、後者だとあまり攻撃は成功しないが、FirefoxやChromeなどでは効果的。ただし、LANのProxy設定などで、「設定を自動的に検出する」がオンになっていなければならない。でもこれは、企業システムなどでは割りとONになっていることが多いのではないだろうか。
Let’s Encrypt で名前ベースのHTTPSバーチャルホスト(SNI)を設定してみる
Let’s Encryptは米国のInternet Security Research Group (ISRG)という財団が提供している、無償のTLSサーバ証明書提供サービスです。無償・自動・安全・透明・オープン・協調をモットーにするサービスで、財団自体は501(c)3の非営利団体1になっています。Technical Advisory Board のメンバーを見ると、Joe Hildenbrand とか Karen O’Donohue のようなお友達が並んでいますね。sakimura.org も、www.sakimura.org はTLS対応をしてきているのですが、証明書代をケチって＆設定が面倒で、nat.sakimura.orgなどはTLS対応してきていませんでした。でも、こんなのが出てきたらもう言い訳できません。それでは、設定をしてみましょう。 Let’s Encrypt のインストー
だだ漏れている企業ビッグデータ
どうやら、多くの企業の「ビッグデータ」はだだ漏れているようです。スイス・チューリヒのセキュリティ企業BinaryEdge[1] の調査の結果[2]、大量のデータがそのままインターネットにさらされているようなのです。その総量はなんと1.1ペタバイト。 同社の調査は、Fortune 500企業からベンチャーまで幅広い企業のインターネットに晒されているホストをスキャンし、公開されているMongoDB, Memchached, Elastic Search, Redis Cache などからメタデータを引き抜いてくるというものでした。（同社は、データ自体は取得していないことを明言しています。） それによると、 35,330件のRedis Cache、 39,134件のMongoDB、 118,574件のMemcached、 8,990件のElastic Search が、認証・認可無くデータを全世
Internet Identity年表
そろそろ知っている人がだんだんいなくなってきそうなので、Internet Identity年表をまとめ始めました。個人的に重要だと思うイベントを独断と偏見で収録しています。まだまだ不完全ですので、「ここにこんなのがあったよ」などは、日付、見出し、出典（リンクなど）、それが重要だと思う理由をこちらのコメント欄に書き込んでください。 1998: XNS Project 開始 1999: Microsoft Passportサービス開始。(https://news.microsoft.com/2001/08/12/microsoft-passport-brings-convenience-safety-to-e-commerce/) 2000: XNS ORG 設立 2001/1: SSTCがOASISで始まる。(SAMLの標準化) 2001-03-19 Microsoft’s Bill Gat
アメリカの不動産業界がWeb APIの認証にOpenID Connectを採用
Peter Williams氏の報告[1]によると、アメリカの不動産業界がWeb APIの認証にOpenID Connectを採用することを決定したようです。知らなかったんですが、不動産業界って、GDPベースでは米国最大のセクターなんですね。米国商務省経済分析局の 2014年ベースの統計[2]でGDPの13%を占めています。２番めのセクターが政府セクターで、12.9%。 米国産業別GDP(2014) ー不動産業界は13%でGDP比率トップ （出所）米商務省米国商務省経済分析局の数字を元に筆者 Williams氏の上記報告によると「５年がかり」の検討の結果[3]、不動産標準グループはOAuthのカスタムプロファイルを廃止して、OpenID Connectに標準化することを決めたとのこと。MicrosoftやAmazonのサポートによって、導入が非常に容易になったのが決め手だったようです。 C
想像力の無い日本：『「全盲なら乗るなよ」「相当イラつくのは確か」川越線での全盲女子負傷 加害者への同調がツイッターで続出』
想像力の無い日本：『「全盲なら乗るなよ」「相当イラつくのは確か」川越線での全盲女子負傷 加害者への同調がツイッターで続出』 まったくひどい話だ。 JR川越線で全盲の生徒が乗客から暴力を受けてけがをした事件[1]はみなさんの記憶にあたらしいと思うが、このNaverまとめ[2]によると、なんとツイッター上ではにわかに加害者の肩をもつ発言が台頭してきているという。曰く、「自業自得」「被害者ヅラするな」など。せっかく日本も「障害者の権利に関する条約」を批准[3]したという年に、こういう光景を眼前にするのは信じがたい思いだ。 町村先生のブログ、Matimulog「美しくない日本、炸裂」[4]にもあるが、この傾向は障害者にだけではなく、例えばマタニティ・マークをつけている人とかにも現れているようだ[5]。「同調圧力」の裏返しとして、「違う存在」「マイノリティ」への攻撃性として顕在化しているようだ。 相
500万件にも及ぶGmailのユーザー名とパスワードが流出？！
怪しさ満点の記事が流れてきた。曰く 500万件にも及ぶGmailのユーザー名とパスワードが流出 TheDailyDotによると、ロシアのBitcoinフォーラムに、500万件にも及ぶGmailのユーザー名とパスワードがリークされたと伝えています。 流出経路は不明ですが、流出したのは、英語、ロシア語、スペイン語を話し、Gmail、Google+などGoogleサービスを利用するユーザーに関する情報のようです。 （出所）MACお宝鑑定団のBlog:『500万件にも及ぶGmailのユーザー名とパスワードが流出』[1] まぁ、ちょっと待て。もしGoogleからだとすると、500万件は少なすぎる。10億ユーザも居るのよ。もしデータベースにアクセスできたのだとしたら、0.5%しかとって行かないというのはあり得ない。さらに、言語特定があるのも怪しさ満点。おそらく、フィッシングによるものだろう。と、思って
OpenID Connect リリース～インターネットのアイデンティティ層
苦節４年半、ワーキンググループを作るところから始めたら、苦節６年、ようやくOpenID Connectをリリースしました。 OpenID Connect は、インターネット上の「アイデンティティ層」をなすものです。ちょっと説明しましょう。 レイヤーとか「層」とかというと、よく使われるものTCP/IPの参照モデルというものがあります[1]。これはIETFによって策定された、インターネット上のホストの持つべき通信機能を階層構造に分割したモデルで、TCP/IP参照モデル、インターネット・プロトコル・スイートなどとも呼ばれ、通信機能（通信プロトコル）を４つの階層に分けて定義しています(RFC1122)。この第４層はアプリケーション層と呼ばれますが、これは、あくまでHTTPやFTP等の通信サービスのことであり、いわゆる「業務アプリケーション」の意味ではありません。実際のユーザが使う「業務アプリケーシ
Id連携がなぜプライバシー向上に役立つか
某所より問い合わせを受けて回答したので、共有しておきます。 お題は、「Id連携がなぜプライバシー向上に役立つか」です。 「Id連携」は、英語では「Identity Federation」を指し、「複数のサービスの間で、主にある主体を識別するために、当該主体に関する（認証結果を含む）属性の集合（identity) を交換・管理する取り決め」のことを指します。一度の認証で複数のウェブサイトにログインできるシングルサインオン（ＳＳＯ）などが代表的な活用例です。 この技術はプライバシー保護に大きく寄与します。私達のような、ずっとId連携に関わってきている人間は当然のことと思っていますが、一般的にはそうではないとおもわれますので、ここにこうして書いておくことも一定の意義があるかと思います。 プライバシー原則 プライバシーの保護とは、原則的には、それぞれの人が個人として尊重され、個人の領域に属するもの
マイナンバーとプライバシー：識別子と超過リスク
前回、「マイナンバーとプライバシー：識別子に対する要件」で、以下のように書きました。 次に、仮想例として、税と社会保障（含む年金）の共通番号というものを考えてみましょう。これは、基礎年金番号と納税者番号双方の要件を満たす必要が出ます。つまり、年金管理が要求する「長い期間」と、税が要求する「広い範囲」の掛け算が必要になります。つまり「長い期間広い範囲で安定的」な識別子が必要になります。これは、要件３を満たしませんので、筋の悪い組み合わせだと言えます。 今回はこれを素材として、識別子のもたらすリスクの特性について考えたいと思います。 識別子の種類 さて、まず本題に入る前に識別子の定義を復習し、その種類をまず見てみましょう。 識別子：＝ある集団の中で、その個人（やモノ）を一意に他と区別（識別）うることができる属性の組み合わせ そうです。普通に考える「個人番号」のようなものだけでなく、「氏名・性別
IPA『アイデンティティ管理技術解説』のSAML/OpenID比較表について
さる８月９日に、独立行政法人 情報処理推進機構（IPA)から『アイデンティティ管理技術解説』[1]という教科書のドラフト版が公開された。８月版はまだドラフトで、各方面からの指摘を受けてどんどん直してゆくたたき台だそうだ。大変な力作であり、完成版が渇望される。 すでに色々なコメントをお返ししたが、SAMLとOpenIDを比較した表5.2-1が明らかに間違っているので、この表がひとり歩きする前に、ここに指摘しておくことにしたい。 問題の表は以下のとおりである。 （出所）IPA 『アイデンティティ管理技術解説』ドラフト版（８月版） より表 5.2-1： SAML と OpenID の特徴 この表のOpenID の欄をご覧頂きたい。以下、順に間違いを指摘してゆく。 間違い1. 「一つのデジタル・アイデンティティで」 デジタル・アイデンティティの定義は、属性の集合である。OpenID 2.0 では、
意味ある同意 Part 2 – 利用規約のクラウドソース評価：ToS-DRプロジェクト
以前の記事、「意味ある同意と情報共有標準ラベル」では、プライバシーポリシーやサービス利用規約を利用者が読んで理解して同意していると仮定するのは非現実的であり、それを改善するための方策として Kantara Initiative で標準化が行われている「情報共有標準ラベル」を紹介しました。 情報共有標準ラベルは、基本的に情報提供者が提供するべきもので、それ自体は、そのプライバシーポリシーや利用規約の良し悪しは評価していません。 今日は関連するプロジェクトとして、「利用規約なんて読まなかったよ (Terms Of Service; Didn’t Read. ToS-DR)」プロジェクトを紹介します。 ToS-DRプロジェクトは、クラウドソースによって各ベンダーの利用規約（ToS）を読み込んで、幾つかの評価項目について５段階評価し、それをグラフィカルに表そうというプロジェクトです。たとえば、みな
米Yahoo!からのパスワード流出を考える
(UPDATE1) Yahoo! Voice と Yahoo! Voices は別のサービスらしいので、そこをUPDATEしました。なお、結論は変わりません→ってことは、Yahoo! Voice も気をつけて対処したほうが良いってことですよ…。 米 Yahoo! からパスワードが流出したと大騒ぎである。 米Yahoo!は長らくビジネス的問題を抱えていて、多くの人材が流出していてシステムメンテに手が回らなくなっているので、「あー、ついにやってしまったか」と最初にニュースに接した時には思った。最近は、認証は専門部隊を持っているところに任せましょうという講演をあちこちでして回っているのだが、認証プロバイダ(Identity Provider, IdP) もやっている Yahoo! がこれをやってしまったというのは、個人的にも非常にインパクトが大きい[1]。 実際、この分野に造詣の深い Evolu
意味ある同意と情報共有標準ラベル
みなさん、フェースブックやらグーグルやらのサービスを使ったりするときに、サービスの利用規約やプライバシーポリシーをちゃんと読んでますか？ 私は読んでません。いや、フェースブックとグーグルは読みました。が、他の殆どは読んでいません。だいたい、そのサービスが使いたくてそこに行ったのに、何十ページもある規約なんか、読めるわけ無いですよね。 顧客がそれらを読まないことは、サービス提供者側も十分承知なはずで、この場合の同意に意味があるかどうかは大いに疑問なのであります。 こうした状況は、サービス提供者にとってもユーザにとっても不幸なことです。 この課題に対する一つの回答として Kantara Initiative の Information Sharing Work Group で検討されている仕様に、Standard Information Sharing Label （情報共有標準ラベル）という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
