Ars Technicaは10月25日(米国時間)、「Passkeys—Microsoft, Apple, and Google’s password killer—are finally here｜Ars Technica」において、安全で使いやすいパスワードの代用品がついに登場したと伝えた。Microsoft、Apple、Googleの「パスキー(Passkeys)」の登場によって、パスワードの代替手段を手に入れることが可能になったという。 パスワードに変わる新たな選択肢として、パスキーが具現化した。もともと認証情報をハードウェアに保存するためのさまざまなスキームのことをパスキーと呼び、コンセプトは10年以上前から存在していた。パスキーは、パスワードよりも使いやすく、クレデンシャルフィッシングやクレデンシャルスタッフィング、アカウント乗っ取り攻撃にも完全な耐性があるといわれている。 F
認証プラットフォームを提供するAuth0（オースゼロ）社は、顧客ID＆アクセス管理（CIAM）に関する調査レポート「ログイン体験の期待と現実」を発表した。2021年2月から8月にかけてオンライン上で実施したもの。日本を含む世界の12カ国 、1万7000 人の消費者と オンラインサービスを提供する企業に勤務する2400人のIT・マーケティング分野の意思決定者から回答を得た。 調査結果によると、EC利用で83％は面倒なログイン・登録プロセスを理由に、購入やアカウント設定を放棄したと回答。日本市場に限ると76％で、そのうち5人に1人は「何度も（放棄した）経験がある」と回答した。 年代別では、35～49歳が他の年代よりも高い（28％）。世代別EC利用率も、仕事や子育てなど時間的制約のある30～40代が高いことから、ECの利便性が企業のビジネス機会に直結していることがうかがえる結果となった。 一方、
以前javascriptでMD5を計算するスクリプトを紹介しましたが、今回はそれを用いて、WEBアプリとjavascriptでダイジェスト認証を実装する方法をご紹介します。 「なぜそんなことをするのか？」という理由も記します。 はじめに 以前「javascriptでMD5」という記事を書きました。案外とアクセスしてくださる方がいらっしゃいます。 本稿ではそれを利用し、PHPで実装したWEBアプリでダイジェスト認証と同様の認証処理を実装する方法をご紹介いたします。 読者としてはHTML、PHP、javascriptとjQueryを知っている技術者を想定しています。掲載するコードは説明のためにシンプルにしてありますので、必要に応じて補完して下さい。 javascriptでダイジェスト認証を実装する意味 最初に、javascriptを使ってまでダイジェスト認証を実装する意味から記します。以下の4
Digest 認証 (ダイジェスト認証) 前ページでは Basic 認証を紹介し、セキュリティ面で問題があることを示しました。 その欠点を解消したのが Digest 認証です。 以下の URL では Digest 認証を行っています。 ブラウザから操作する分には Basic 認証と区別が付かないでしょうが、 認証の仕組みはちょっと複雑になっています。そのかわり、 ネットワーク上を流れるパケットを覗き見られても、パスワードがばれることはありません。 以下、仕組みを簡単に説明します。 「メッセージダイジェスト」の意味がよくわからなければ、暗号化のお話 (3) を参照してください (「ハッシュ」と「メッセージダイジェスト」は同じものと考えてください)。 まず、あらかじめサーバ側にパスワードの MD5 メッセージダイジェストを保存しておきます (ユーザ登録に相当)。 クライアントが Digest
2020年9月10日、株式会社Bot ExpressはLINEを用いた住民票申請の是非を問うため、総務省（国）を提訴しました。 争点争点は、当社が提供するLINEで住民票申請機能における本人確認実装が適法であるかどうかです。本サービスは簡単に言えば下記のとおりです。 ・住民はLINEで住民票を申請する。 ・本人確認書類および本人の複数の顔写真を照合して本人確認をおこなう。 ・LINE Payで手数料を決済する。 ・郵送で住民票が住民票記載の住所に届く。 本サービスは2020年4月1日から、渋谷区で導入されています。総務省は2020年4月3日に、高市総務大臣がこのサービスについて改善を求めると言及したほか、地方自治体宛てに「このサービスは適法でない」という旨の文書を交付しています。また、その後、複数の地方自治体から総務省にこのサービスの是非を確認する問い合わせがあり、総務省は一貫してNGだと
にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。本連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する（編集部） OpenIDってなんだろう？ 現在、国内外でにわかに注目されつつあるOpenIDという仕組みを聞いたことがあるでしょうか？ これはユーザー中心の分散ID認証システムですが、まだ日本での普及は進んでいない状況です。 これにはいくつか原因が挙げられるでしょうが、筆者はOpenIDが正しく理解されていないことが原因だと考えます。 本連載ではOpenIDの現行仕様、およびその拡張仕様とともに、実装を例に取りつつOpenIDとは何かということを明らかにしていきます。最終的にはOpenIDが切り開く未来を見るため、現在策定中の次期仕様についても触れていきたいと思います。 広がりつつあるブラウザベ
OAuth::Lite 1.25変更点 今までのget_access_token my $access_token = $consumer->get_access_token( url => $access_token_url, token => $request_token, verifier => $verification_code, ); tokenリクエストトークンを渡さなかったり verifierを渡さなかったりしたら、エラーとして扱っていました。 これはOAuth 1.0 Rev a で必ず必要なパラメータだったためです。 またメソッドの返り値として得られるのはOAuth::Lite::Tokenオブジェクトでした。 しかしSession Extensionや、先日のxAuthなどでは、token以外の情報も レスポンスに含まれるようになってきました。 また、xAuthでは、
2010年02月15日 [Ruby][Twitter] OAuthのアクセストークンを、ブラウザなしで、Twitterのユーザ名およびパスワードのみを用いて取得する(通称：xAuth)ためのRubyのコード タイトル長めですが、大事なことなので全部書きました。 コードはこちら： メインのライブラリ/タイムラインを取得するサンプル gist: 304123 - GitHub（最終更新：2010.02.15 11:26） 発言を投稿するサンプル（上記ライブラリと組み合わせてご利用下さい） gist: 306853 - GitHub（最終更新：2010.02.18 3:09） 概要 Twitterでは、OAuthという認証のシステムが利用できる。 従来は、（ユーザ認証を伴う）TwitterのAPIを利用する際、APIの呼び出しのたびにユーザ名・パスワードを送信する必要があった。一方OAuthでは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
