タグ

authに関するkappaseijinのブックマーク (9)

  • トルコの認証局、中間CA証明書を誤発行--グーグルやMS、対応を明らかに

    GoogleMicrosoftが米国時間1月3日にそれぞれ明らかにしたところによると、トルコに拠点を置くある認証局(CA)が2012年12月にセキュリティ証明書を「誤って」発行したことで、その電子証明書の交付を受けたある組織によって、さまざまなGoogleサイトへのなりすましが可能な偽の証明書が作成されてしまったという。 GoogleエンジニアであるAdam Langley氏のブログ投稿によると、「Google Chrome」は12月24日、「*.google.com」ドメイン向けの無認可セキュリティ証明書を検出し、ブロックしたという。同氏によると、この証明書のブロック後、Googleによる調査が行われ、問題の証明書がトルコの認証局であるTURKTRUST傘下の中間認証局により発行されたものであると特定できたという。 ウェブサイトの正当性を証明する電子ドキュメントである証明書が不正に作

    トルコの認証局、中間CA証明書を誤発行--グーグルやMS、対応を明らかに
    kappaseijin
    kappaseijin 2013/01/04
    酷い、というか滅茶苦茶。そのうち組織丸ごと乗っ取られそう。
  • 就活生のみなさんへ ~文系?理系?~ « サーバーワークス社長ブログ

    サーバークスCEOブログ 大石蔵人之助の「雲をつかむような話」は、 「はてなブログ」へ移行致しました。 旧ブログ記事のURLからお越しの皆様は自動で新ブログへ転送されます。 転送されない場合、恐れ入りますが下記URLから移動をお願い致します。 新URL:https://ceo.serverworks.co.jp/ 引き続き、大石蔵人之助の「雲をつかむような話」を宜しくお願いいたします。

    就活生のみなさんへ ~文系?理系?~ « サーバーワークス社長ブログ
    kappaseijin
    kappaseijin 2012/12/29
    OneLoginをぐぐってみたらブラウザーのプラグインやiPhoneのアプリでデバイス単位の認証を実現してるのね。よさげ。
  • Yahoo! JapanがOAuth 2.0 & OpenID Connectに対応 - OAuth.jp

    2011年12月のOpenID Summit Tokyoで、2012年中のOpenID Connect対応を宣言したYahoo! Japanが、日ついに宣言通りOpenID Connectをサポート開始しました。 もともとOAuth 2.0も対応していなかった(よね?)ので、OAuth 2.0対応も同時リリースです。 まだバグとかあるっぽいけど、何はともあれ世界の大手IdPの中で一番最初にproduction環境でOpenID Connect対応できたのはすばらしい! OpenID Summit Tokyo 2011 from Taizo Matsuoka まだOpenID ConnectのDiscoveryとDynamic Registrationには対応していないので、Nov RPに "yahoo.co.jp" とか入力しても使えない状態ですが、それは今後に期待です。 YConnec

    kappaseijin
    kappaseijin 2012/11/08
    「世界の大手IdPの中で一番最初にproduction環境でOpenID Connect対応」まだ夜明け前だったのね。
  • 非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】

    昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」(ユーザ認証)という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊

    非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
    kappaseijin
    kappaseijin 2012/10/29
    認証、許可、OAuth 1.x/2.0、OpenID/OpenID Connectの関係がわかりやすい。
  • 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる

    In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット&ペーストアタックが可能だからです。 OAuth 認証?は、図1のような流れになります。 図1 OAuth 認証?の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A

    単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
    kappaseijin
    kappaseijin 2012/10/29
    死んだと思っていたOpenIDが盛り返しているのはこれが理由なのね。OAuthは認証ではなく許可のプロトコル。覚えた。
  • bit.ly の OAuth 2.0 とか色々試してみたら色々アレだった : にぽたん研究所

    ある日、うちのサービスで bit.ly 使って URL を短縮したいねーなんて話があがって、まぁ、単純に短縮化するなら、@shiba_yu36 さん作の WebService::Bitly なんか使えば簡単に色々出来て便利だなーって思いました。 で、きっと、このモジュールを使っているであろうはてなダイアリーとか見てみたら、bit.ly の設定画面があるんですね。 自分自身の bit.ly アカウントを使えば bit.ly でトラッキングとか出来るし便利だなーと思いました。 …でもね、うちのサービスの利用者の方々は、はてな民のようなリテラシーの高いユーザばかりではないのですよ。 「bit.ly の API キー」とか言っても「は?????」って感じの方が大多数。 意味わからないものを設定画面につけるとなっちゃん宛にクレームがいっぱい来てしまいます。 とりあえず、bitly API Docum

    bit.ly の OAuth 2.0 とか色々試してみたら色々アレだった : にぽたん研究所
    kappaseijin
    kappaseijin 2012/10/29
    今でもこうなのかなあ。短縮したいだけならここまで苦労しなくても良いっぽいけど。
  • OAuth 2.0 Implicit Flow で認証の問題点、再び。 - OAuth.jp

    おひさしぶりです、@novです。 最近は、新しいFacebook iOS SDK使ってるアプリを見つけるとまずToken置換攻撃を試みていますが、結構高い確率でこの攻撃に対して脆弱なアプリがみつかります。困ったものです。。 そんななか、2週間ほど前に、Micosoft Researchの人がIETF OAuth WGのメーリングリストに同じ問題を提起していました。該当Threadでは少し話題が脱線している部分もありますが、もともと最初にこの問題を提起したJohn BradleyがOAuth 2.0 CoreにSecurity Considerationsを追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに

    kappaseijin
    kappaseijin 2012/10/29
    「Web API側では毎回token発行先が自分のアプリかどうか確認していますか?」ありがちで怖ぇぇぇ。
  • OAuth.jp

    いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。 細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。 Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。 User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を

    kappaseijin
    kappaseijin 2012/10/29
  • [Rails3] ログイン認証の要・不要をコントローラーによって使い分ける

    実行環境: ruby 1.9.3 Rails 3.1.3 ログイン認証を実現する際、認証が必要なコントローラー内に before_filter を書いてコントローラーを実行する前にログイン状態をチェックします。 たいてい、認証が必要なコントローラーが複数あります。それぞれに before_filter とそのメソッドを書くのはダサいので、before_filter を書いたコントローラークラスを作って継承させるのですが、認証させるコントローラーの数が多いと面倒になってきます。 すると「ええぃ、全てのコントローラーの親である ApplicationController に書いてしまえ!」と思うわけですが、逆に認証させたくないコントローラーが1つ2つあると、どうしてやろうか?と悩むことになります。 実現方法は色々あると思いますが、例としていくつかパターンを上げてみたいと思います。 ここでは例と

    kappaseijin
    kappaseijin 2012/10/29
    1-1だろJK、と思ってたけどnamespaceで判断って良さげ。でもやっぱりマーカーとして継承がいいなあ。
  • 1