コードサイニング証明書獲得に用いられる企業ID窃盗
すべてのCAが、どのような名称でも証明書を交付できるという現行モデルは、セキュアではあり得ない。有効なAuthenticodeコードサイニング証明書でサインされたファイルについて調査すると、このことを再認識させられる。 このようなものを、われわれは以前目にしたことがある。しかし今回のケースは、連絡先が非常に本物らしい点が奇妙だった。通常、有効だが悪意ある証明書では、詳細は明らかに虚偽であるか疑わしいものだ。 わたしは、この証明書にある名称とアドレスに該当する企業を探し、産業用プロセス制御とオプティマイゼーション関連のサービスを提供する小規模なコンサルティング会社を見つけた。 この会社に連絡をとり、彼らのコードサイニング証明書が盗まれたことに気づいているかどうかを尋ねた。そして彼らがコードサイニング証明書を有していないと回答したため、事態はわたしにとってより興味深いものとなった。実際、彼らは
キー入力「クセ」で本人確認…ＮＴＴコム、１００％識別 : ニュース : ネット＆デジタル : YOMIURI ONLINE（読売新聞）
ＮＴＴコミュニケーションズは、パソコンのキーボードで入力する際のクセや特徴を見抜いて個人を認証するソフトを開発した。 不正アクセスなどによる「なりすまし」を発見できる利点があり、パソコンを使った遠隔教育などでの活用が見込まれている。今年度中に国内初の商用化を目指している。 「キーストローク・ダイナミックス」と呼ばれる生体認証技術の一種で、キーを押してから離すまでの時間や、次のキーを押すまでのタイミングやリズムなどで個人差が大きいことを利用した。 事前に１０００文字程度のキー入力で様々なパターンのクセを登録し、その後入力される文章１５０文字程度ごとに、本人の打ち方との共通度を判定。打ち方のデータは、ネットワークにつながった利用者のパソコンから、同社の認証用サーバーに送られる仕組みだ。実証実験によると、本人か別人かをほぼ１００％見分けることが可能という。 パソコン利用中は継続して認証できるため
高木浩光＠自宅の日記 - EMOBILEのX-EM-UID、はじめから破綻, 追記
■ EMOBILEのX-EM-UID、はじめから破綻 昨日の「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」から導かれる当然の帰結であるが、EMOBILEの X-EM-UID: についても同様に、SSL接続で得たものを認証に使ってはいけない。 「IDがSSLで使えない」ではなく「SSLで得たIDを使ってはならない」である点に注意。つまり、http:// のページしか提供していないつもりでも、実はWebサーバが https:// でもアクセスできるようになっていて、同じWebアプリケーションプログラムにリクエストが渡るようになっていたりすると、https:// 経由でなりすましログインされてしまうということ。 EMOBILEの「EMnet」はProxyサーバ wm.internal.emnet.ne.jp:8080 によって提供されており、これをProxyとしてSSL接続
高木浩光＠自宅の日記 - まだまだ他でも破綻しているケータイID認証
■ まだまだ他でも破綻しているケータイID認証 前回の補足。以下は、私が気づいたことではなく、2009年夏に「かんたんログインが危うい」との話題で持ち切りだったときに、既に公に語られていたことである。 SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 特にUserAgentからIMEI番号を正規表現などで抜き取ってそれだけを利用している場合は、この方法を使えば偽装可能。uidの方を使うようにした方がいいかも。 モバイル用GWのIPアドレスを気にしてた時代もあったなぁ, コメント欄#1, 匿名の臆病者, 2009年8月6日 透過プロクシという仕組みはご存じない? あ、ということは少なくともhttpsにx-jphone-uidが乗っていたら擬装の虞か。(端末はuidを吐かないので) しかし、携帯電話会社がこの
認証基盤連携フォーラムの活動は終了しました。
認証基盤連携フォーラムの活動は終了しました。 5秒後に、Web Archive に飛びます。
ID連携で異なるサービスを利用する可能性と課題――推進団体が報告
認証基盤の連携によるサービスの可能性と課題について、認証基盤連携フォーラムが実証実験の結果を報告した。 認証基盤連携フォーラムの実証実験ワーキンググループ（WG）は3月26日、このほど実施した「認証基盤連携による認証基盤間の相互運用性確保の実証」の実証実験の結果について報告した。 この実験は、総務省のICT先進事業国際展開プロジェクトの1つとして実施されたもの。電気通信事業者の異なる認証基盤の相互運用性を確保することで、ユーザーが複数のコンテンツやサービスを1つのIDで利用できることを目指している。 実験では、1人のユーザーがPCと携帯電話で異なるIDを利用しても容易に本人確認ができる方式や、OpenIDを携帯電話で利用する上での課題検証、必要とする情報の重要度に応じて認証手段を使い分ける方法といった、さまざまなテーマで実施された。 NTTドコモが主体となった実験では、まずPCサイトにログ
[PHP] Amazon Product Advertising API で認証付きリクエストを送る方法まとめ - RinGoon POP!!
気になるニュースや時事の話題を毎朝配信！世界と日本の未来を分析します。デジモノや料理の情報、WQXGAサイズの壁紙も。 5月11日からスタートする Amazon Product Advertising API （旧称 Amazon Web Services ／ アマゾン アソシエイト Web サービス）は、移行期間3ヶ月の後、8月15日から認証のための電子署名付きリクエストが必須となる。アマゾンアフィリエイトWebサービスを使っている人は、認証付きリクエストを発行できるように、プログラムを改修する必要がある。ここでは、PHPを使って、電子署名付きリクエストを作成・送信する方法について解説する。 （5/11 13:00 完全版をアップしました） （5/11 22:30 ver 0.2 をアップしました。Timestampに関するバグを修正しました。必ずアップデートしてください。） （5/12
AmazonのAPI認証導入はOSSに対する挑戦だよなぁ - ただのにっき(2009-05-12)
■ AmazonのAPI認証導入はOSSに対する挑戦だよなぁ 「Amazon アソシエイト Web サービスの名称変更および署名認証についてのお知らせ」によって、たった3ヶ月であらゆるAPI呼び出しに認証をつけなくてはいけなくなったわけだが、ここまで広まったAPIにこんだけキツい縛りをかける、その裏の意図がさっぱりわからん。 この認証方式は、以前AlexaのWebサービスを使ってみたときとほぼ同じで、SHA1の代わりにSHA256を使う点と、ハッシュの元メッセージが複雑になった点が違う程度。コード上の対応は難しくない。tDiaryでもすでに、えろぺおさんによるモンキーパッチが出ている。 Alexaの場合は課金という目的があったけど、Amazonの場合は逆にユーザに金を払っているわけで*1、しかも実際に売り上げが上がったときにだけ支払ってるわけだから、あんまり認証かける意味はなさそうなんだよ
Amazon Web Services Developer Community : OSSからの認証利用について ...
You have been redirected here because the page you are trying to access has been archived. AWS re:Post is a cloud knowledge service launched at re:Invent 2021. We've migrated selected questions and answers from Forums to AWS re:Post. The thread you are trying to access has outdated guidance, hence we have archived it. If you would like up-to-date guidance, then share your question via AWS re:Post.
Twitter API Wiki / Sign in with Twitter
Sign in with Twitter is the pattern of authentication that allows users to connect their Twitter account with third-party services in as little is one click. It utilizes OAuth and although the flow is very similar, the authorization URL and workflow differs slightly as described below. The normal flow dictates that applications send request tokens to oauth/authorize in Twitter's implementation of
研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成
すでに破られているハッシュアルゴリズムであるMD5を、SSLの証明書の検証に用いることによる危険については最近かなり聞くようになっている。米国時間1月17日、ある研究者がAuthenticodeで署名されたバイナリファイルと署名が一致する、悪意のあるソフトウェアの作成に向けて、大きな一歩を踏み出したことがわかった。 研究者のDidier Stevens氏は、Peter Selinger氏が説明する、同じMD5のハッシュ値を持つ2つの実行ファイルを生成する技術を使って、MicrosoftのAuthenticodeプログラムで署名された実行ファイルのペアを生成することもできることを示した。この技術を使うと、悪意のある人物が、Microsoftによって署名されており、正しいものとして検証されるが、実際には悪意のあるドライバを作成することが可能になる。 SSL問題の場合と同様に、Authentic
Geneva Framework: クレームベースの WCF サービスを構築するためのより優れたアプローチ
Geneva Framework A Better Approach For Building Claims-Based WCF Services Michele Leroux Bustamante Code download available from the MSDN Code Gallery This article is based on a prerelease version of the "Geneva" Framework. All information is subject to change. Contents Why Claims-Based Security? Security Token Services Support for Claims-Based Security WCF Services, before the Geneva Framework Is
グーグル、「Friend Connect」の提供を開始
「Facebook Connect」の正式公開を受けてのもののようだが、Googleがユニバーサルログインシステム「Google Friend Connect」を開始した。米国時間12月4日、報道関係者のもとに急遽作成したらしい電子メールが送られてきた。そこには、「今日から、誰でも自由にFriend Connectを自分のウェブサイトに追加できる。審査の必要なし。その他の詳細はOfficial Google Blogにすぐに投稿します」と書かれていた。 Facebook Connectの場合と同様で、サイトにFriend Connectを採用した場合の利点は、ユーザーがたいていは毎日利用していて不安感のないログイン方法で登録できるということにある。Googleまたは「Gmail」のIDとパスワードが使えるのだ。 Friend Connectは、Facebook Connectよりもいくらか
Facebook、「Facebook Connect」の正式提供を開始
ソーシャルネットワーク大手のFacebookは米国時間12月4日、Facebookのプロフィールデータや認証情報を外部のウェブサイトでも利用できるようにするサービス「Facebook Connect」の正式提供を開始したと発表した。 同社はFacebook Connectの機能をセルフサービスで利用できるとしており、少しでもコミュニティー機能のあるサイトを開設しているユーザーなら誰でも、Facebookのソーシャルネットワークと関連づけることが可能になる。 以前の記事にも記したように、このサービスを否定するのは難しい。既存のFacebook認証情報でユーザーが「登録」できる機能をサイトに追加することで、コミュニティーの関わりが強化されるだけでなく、これらのサイトでユーザーが行うことがアクティビティ情報としてFacebookにも反映されるからだ。これは無料のマーケティングといえる。 Face
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブログ
ブログ
ご利用上の注意 | NTTドコモ
docomo IDについて サイト運営者様向け | NTTドコモ
docomo IDについて | NTTドコモ
さてどうしよう？Product Advertising APIへの対応 - あまなつblog