Googleがログイン認証を強化、OAuth 2.0の採用促す
米Googleは4月23日、2014年下半期以降にユーザーがWebブラウザやデバイス、アプリケーションからGoogleにログインする際のセキュリティチェックを段階的に強化すると発表した。 Googleではユーザーレベルで2段階認証などのセキュリティ強化策を提供するとともに、開発者向けには「Google Sign-In」などのツールを提供し、Google APIで認証プロトコルの「OAuth 2.0」をサポートしている。 今回のセキュリティチェックの強化は、本来のユーザーしかアカウントにログインできないことを確実にするのが目的。ユーザー名とパスワードをGoogleに送信しているアプリケーションでは、認証にOAuth 2.0を採用するよう開発者に促した。 Googleは、「OAuth 2.0を使わなければ、ユーザーがそのアプリケーションにアクセスするために、追加の手順を要求されるようになる」と
標的型サイバー攻撃を教訓にした認証機能の可能性
EMCジャパン RSA事業本部は、認証製品の最新版「RSA Authentication Manager 8」で、「リスクベース認証」機能の提供を発表した。モバイルデバイスやBYOD（私物端末の業務利用）といったユーザー環境の変化への対応、また、標的型サイバー攻撃への対策がその狙いだという。 リスクベース認証は、固定パスワードや別の認証手段を組み合わせる「多要素認証」の一つで、ログインを要求するユーザーの環境からその真正性を確認する。米EMC RSA事業部門でシニアプロダクトマーケティングマネジャーを務めるジェフ・カーペンター氏によると、同製品のリスクベース認証では主に（1）ユーザーのデバイス、（2）ユーザーの行動、（3）ネットワーク情報、（4）トークン情報――といった観点から「リスクスコア」を算出する。リスクスコアがしきい値を超えた場合に追加認証を行うことで、正規ユーザーであるかをチェッ
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
「パスワードでの保護は限界」と結論したGoogleが評価するセキュリティ技術
Googleは、2013年1月、セキュリティに関する研究結果を公表した。このレポートは「Authentication at Scale」というタイトルで、ユーザー認証技術についての評価報告である。Googleはこのレポートで、「パスワードとCookieで利用者を守ることはできない」と結論付け、新たな技術の導入を検討していることを明らかにした。 ユーザー認証にハードウエア・キーを利用 Googleが評価している技術の一つがYubiKey (ユビキー) という製品である。この製品は、Palo Alto (カリフォルニア州) に拠点を置く、Yubico (ユビカ) というベンチャー企業により開発されている。YubicoはRSA Conferenceに同社の最新技術を出展していた。 Yubicoのブースにおいて (上の写真、出展はすべてVentureClef)、John Salterから、製品デモ
スマホが開く“簡単認証”
業務システムを守るのに十分なセキュリティ強度を備えながら、消費者向けサービスにも採用できるほど使い方は簡単。そんな認証手法の活用事例が相次いでいる。 いずれも、複数の端末を使いこなす現在の社員や消費者のスタイルに沿ったものだ。これまで専用のハードウエアが必要だった生体認証、ICカード認証、ワンタイムパスワードを、それぞれスマートフォンやタブレット端末の機能を使って実現させた。いつも携帯している機器をカギに、PCのロック解除やシステムへのログインを行えるので、セキュリティ強度を維持したまま、使い勝手の良さも両立できる。 内蔵カメラだけで静脈認証 「2013年春には、社内の業務システムへのユーザー認証として採用したい」。ソフトバンクモバイル システムセキュリティ部の村上博文部長はこう語る。 同社が採用するのは、スマートフォンやタブレット端末を使い、追加の機器なしで利用できる生体認証だ（図1）。
遂にｷﾀ - .∵･(ﾟ∀ﾟ)･∵. - ｯ!!大事なGoogleアカウントを堅牢に守りきる2段階認証プロセス日本語版がとうとう有効になりました！ - 適宜覚書-Fragments
遂にｷﾀ - .∵･(ﾟ∀ﾟ)･∵. - ｯ!!大事なGoogleアカウントを堅牢に守りきる2段階認証プロセス日本語版がとうとう有効になりました！ Googleアカウントは、Googleのサービスを使う上でとても重要です。各種のサービスの利用設定はもとより、そこで蓄積したデータの管理はアカウントに紐づけられています。これは裏を返せば、アカウントの認証情報を取られてしまうと被害が甚大となります。Google側としてもこれを認識してユーザに認証情報を保護するよう啓蒙してきました。 でも、それには限界があって詐取に対する有効な手段として、今年2月に2段階認証プロセスが採用されました。日本語版も7月末に公開されたものの携帯電話でのコード受信が利用出来ず形だけのものとなっていました。恐らくは12月上旬ひっそりですが、とうとうこの機能が利用可能になりましたので導入プロセスを以下に紹介します。 【重要】
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
Google、アカウントのサインインに2ステップ認証を導入
米Googleは、オンラインサービス用Googleアカウントのサインイン手順に、同社が「2-step verification（2ステップ認証）」と呼ぶ新たなユーザー認証方式を現地時間2011年2月10日から導入した。同方式は、オンライン・アプリケーション・サービス「Google Apps」の無償エディションでも提供する。英語版のみ利用可能。 2ステップ認証を有効にすると、Googleアカウントにサインインする際、従来のユーザー名（「Gmail」のメールアドレス）とパスワードを入力後に、コードを入力するよう求められる。このコードはユーザーが所有する携帯電話に音声あるいはSMS（ショートメッセージサービス）テキストで送られてくる。 所有端末がGoogleの「Android」を搭載したデバイス、もしくはカナダResearch In Motion（RIM）の「BlackBerry」や米Apple
w3cもケータイ認証には困惑している件 | [ bROOM.LOG ! ]
ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 以前Twitterでもツイートしてたんだけど一部誤解があったのでこちらでまとめてみる。 Global Authoring Practices for the Mobile Web (Luca Passani) http://www.passani.it/gap/ 上記をもって「w3cが個体識別番号に駄目出し」としていたんだけど、多少事情が違った。 実は上記には元になる対象文書がある。それがw3cのベストプラクティスだ。 Mobile Web Best Practices 1.0 http://
Twitterによる簡易版OAuth: "xAuth"
最近にわかにTwitter APIのxAuth認証が話題になっています。これは主にデスクトップアプリケーション向けに用意される認証方式で、簡潔に言うと「Webブラウザで認証画面を開く必要のないOAuth」といったところです。 従来のOAuth認証ではまずアプリケーション（OAuthコンシューマ）がTwitterに接続してRequest Tokenを取得し、認証画面を開いてRequest Tokenを承認させ、承認されたRequest Tokenを使ってAccess TokenとToken Secretを取得することによって各APIにアクセスできるようになります。しかしこれはアプリケーション側の実装が複雑になる上、デスクトップアプリケーションの場合はわざわざWebブラウザへ切り替えなければならず（ブラウザを内包するものもありますが）、ユーザにとっても面倒なものです。 そこで提案されたのがxA
Devise: Rails向けの柔軟性のある認証ソリューション
英語力を鍛える為に海外からの興味ある主にRubyに関したブログ記事やマニュアルページなどを日本語に訳していこうと思っています。訳文に間違いや分かりにくい点があればコメントやメールで指摘して頂けるとうれしいです。 先日、2009年11月15日（日）にRails勉強会@東京第45回に参加させて頂きました。とてもいい雰囲気でとても楽しむことができました。本当にありがとうございました。 残念なことに、最近、新規の参加者が少ないとのことでした。もしこれを読んでいて、Rails勉強会@東京に参加したいけど、敷居が高いかなぁとかRailsに興味があるけど使ったことないからどうしようと思っていたら、一度、ぜひ、参加してみて下さい。初心者向けのセッションもあります。あと、もうRailsは大丈夫というかたでも、最新のRails事情などの情報を集めたりするいい機会だと思います。 自分は、普段、岐阜に住んでいるの
OAuthコンシューマの仕組みと実装 〜 Ruby編 - しばそんノート
前置き 前回の記事でOAuthを使ってTwitter APIにアクセスすることができるようになりましたが、ruby-oauthは内部でNet::HTTPを呼び出しているため、そのままではGoogle App Engine for Java上のJRuby(以下JRuby for GAE/J)で利用できません。 「JRuby for GAE/JでもNet::HTTPが使えるようになる」というrb-gae-supportと組み合わせればOKなのかもしれませんが*1、OAuthの仕様自体はシンプルなものですし、せっかくなので勉強がてら自分で実装してみることにします。 車輪の再発明おいしいです！*2 ちなみにタイトルにRuby編と付いていますが、他の言語編を作成する予定は特にありません。 OAuthの仕様 実装の前にOAuthの仕様や、そもそもの成り立ちについて調べました。既にわかりやすいまとめ記事
twitter,FriendFeedのOAuth実装について - r-weblife
■ 目的 twitterベースなマフィアゲームのおかげで一気に話題になったOAuth。 ここまできたら、みなさんにもっと詳しく知ってもらいたいということで、以下２つのサービスが実装したOAuthの仕様を見直してみます。 twitter : http://apiwiki.twitter.com/Twitter-API-Documentation FriendFeed : http://friendfeed.com/api/documentation 以下、OAuthをいくつかのステップに分けて仕様を見ていきます。 ■ Consumer登録 必要な情報 □ twitter Application Icon Application Name Description Application Website Organization Website Application Type Callback
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
#304 OmniAuth Identity - RailsCasts
Restful authentication => Rails Wiki
https://www.func09.com/wordpress/archives/280