タグ

認証に関するunfiniのブックマーク (45)

  • デジタル庁が発表した「デジタル認証アプリ」でできること ざっくり整理 - Qiita

    2024年6月21日にデジタル庁からデジタル認証アプリの発表がありました。 このデジタル認証アプリで何ができるのか、ざっくり整理してみました。 この記事で対象としている方 デジタル認証アプリの概要についてざっくり理解したい方 デジタル認証アプリについて今北産業してほしい方 この記事では技術的な話はなるべく避け、全体像を整理していきます。 技術的な話を理解したい方は、参考リンクより他の方が書かれた記事を参照してみてください。 「デジタル認証アプリ」はどんなものか? 「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 (デジタル認証アプリサービスサイトより引用) デジタル認証アプリは、デジタル庁が提供するデジタル認証アプリサービスAPIと組み合わせて1つのサービス(デジタル認証アプリサービス)を構成しています。デジタル認

    デジタル庁が発表した「デジタル認証アプリ」でできること ざっくり整理 - Qiita
  • 「パスキー」のユーザー体験を最適化させるデザインガイドライン、FIDOアライアンスが公開

    パスワードレスなユーザー認証を実現する業界標準である「パスキー」を策定するFIDOアライアンスは、パスキーのユーザー体験を最適化させるためのデザインガイドラインの公開を発表しました。 パスキーは、従来のパスワードによるユーザー認証よりも強力で安全な認証方式とされており、普及が期待されていますが、多くのユーザーが慣れ親しんできたパスワード方式と比べると、サインアップやサインインの方法が分かりにくいという課題が指摘されていました。 FIDOアライアンスによるデザインガイドラインの公開は、こうした状況を改善するものとして期待されます。 パスキーのデザインガイドラインの内容 デザインガイドラインは主に以下の要素から構成されています。 UXの原則(UX princeples) コンテンツの原則(Content principles) デザインパターン(スキーマ、サンプルビデオ、AndroidとiOS

    「パスキー」のユーザー体験を最適化させるデザインガイドライン、FIDOアライアンスが公開
  • 基本から理解するJWTとJWT認証の仕組み | 豆蔵デベロッパーサイト

    これは、豆蔵デベロッパーサイトアドベントカレンダー2022第8日目の記事です。 JSON Web Token(JWT)の単語を目にすることがよくあると思いますが、それと一緒に認証と認可や、RSAの署名や暗号化、そしてOpenIDConnectやOAuth2.0までと難しそうな用語とセットで説明されることも多いため、JWTって難しいなぁと思われがちです。しかし、JWT自体はシンプルで分かりやすいものです。そこで今回は素のJWTの説明からJWS、そしてJWT(JWS)を使った認証を段階的に説明していきます。 おな、この記事はJWT全体の仕組みや使い方の理解を目的としているため、以下の説明は行いません。 RSAやHMACなど暗号化やアルゴリズムの細かい説明 JWTを暗号化するJWEとJSONの暗号鍵表現のJWKについて OpenIDConnectとOAuth2.0について 記事は上記のような内容

    基本から理解するJWTとJWT認証の仕組み | 豆蔵デベロッパーサイト
  • Auth.js v5ではじめる本格認証入門

    Next.js 14 / Auth.js v5 / Prisma / Planet Scale / shadcn/ui / Tailwind CSS を用いた認証・認可をハンズオン形式で学びます。

    Auth.js v5ではじめる本格認証入門
  • パスキーに入門してみた話 - Qiita

    久しぶりの投稿です。 はじめに 昨今、様々なサイトがどんどんパスキーに対応しはじめてきました。 まだまだパスキーがデフォルトになっていくには時間が掛かりそうですが、どのような仕組みでパスキーを実装するのか、早めにキャッチアップしておくのも悪くないと思い、パスキーについて色々と調べてみました。 パスキーとは? パスワードの代わりに、自分の持つデバイスによる生体認証やパターンを用いて認証を行う方法のことです。 次世代認証技術であるFIDO(Fast IDentity Onlineの略で、「ファイド」と呼びます)を使った認証方式(詳細は後述)で、AppleGoogleMicrosoftがFIDOを普及させるために命名したブランド名になります。 FIDOとは? 脆弱なパスワードは安全ではありません。 2段階・2要素認証を採用してもそれを有効にするユーザーは少なく、昨今では2段階認証を突破する攻

    パスキーに入門してみた話 - Qiita
  • パスワードがハッシュ値で保存されているサイトのSQLインジェクションによる認証回避の練習問題解答 - Qiita

    この記事は、以下の問題の想定正解です。まだ問題を読んでいない方は、先に問題を読んでください。 まず、多くの方に記事を読んで頂きありがとうございます。解答もいくつかいただきましたが、その中で、以下のhm323232さんの解答は非常に優れたもので、これに付け加えることはほとんどありません。 しかし、気を取り直して、解答を書きたいと思います。 まず、ログイン処理の中核部分は以下に引用した箇所です。 $sql = "SELECT * FROM users WHERE userid = '$userid'"; $stmt = $pdo->query($sql); $user = $stmt->fetch(); if ($user && password_verify($password, $user['password'])) { echo "ログイン成功:" . htmlspecialchars(

    パスワードがハッシュ値で保存されているサイトのSQLインジェクションによる認証回避の練習問題解答 - Qiita
  • パスワードがハッシュ値で保存されているサイトのSQLインジェクションによる認証回避の練習問題 - Qiita

    SQLインジェクションによる認証回避 SQLインジェクションによる影響として、情報が漏洩するとか、データが勝手に更新されてしまうなどとともに、認証回避の例がよく紹介されます(私のでも取り上げています)。 典型的な例は下記のとおりです。 // $id と $password は外部からの入力 $sql = "SELECT * FROM users WHERE id='$id' AND password='$password'";

    パスワードがハッシュ値で保存されているサイトのSQLインジェクションによる認証回避の練習問題 - Qiita
  • APIトークン認証の論理設計

    SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう

    APIトークン認証の論理設計
  • Admin.jsを使って面倒な管理画面をサクッと作ろう | DevelopersIO

    こんにちは、CX事業部Delivery部サーバーサイドチームのmorimorkochanです。 突然ですが「あぁ〜管理画面作るのめんどくせ〜」って思うことはないですか? 例えばRDBと接続されたRESTfulなAPIサーバーを作っていて、一部の管理者向けに管理画面を作りたいが管理画面にこだわりがない場合などなど。 そんな時に便利なのが、Admin.jsです。Admin.jsは管理画面を簡単に作成できるフレームワークです。オープンソースとして公開されており、クラウドにデプロイされているサービスを利用する場合は月額料金がかかりますが手動でサーバーに組み込んでデプロイする場合は無料です。 Admin.jsを使うと、RDBで管理される各テーブルごとにCRUD画面を簡単に作成することができます。これによってRDBと同じプロパティを何度も定義したり同じようなCRUDコードを何度も記述する必要はありま

    Admin.jsを使って面倒な管理画面をサクッと作ろう | DevelopersIO
  • Windows XPの認証システムは完全に突破されていてオフラインでアクティベート可能

    2001年に発売されたWindows XPは動作が安定していることや低スペックのPCでも動作可能なことから2014年にサポートが終了した後も根強い人気を誇っており、発売開始から20年後の時点でも約0.6%のシェアを保っています。Windows XPは正規の需要に比例して海賊版の需要も高く、長年にわたって認証システムが攻略されてきました。2022年に完全オフラインで認証を突破できるようになるまでの流れをtinyappsがブログにまとめています。 Windows XP Activation: GAME OVER https://tinyapps.org/blog/202304230700_xp_wpa.html Windows XPのアクティベーションプロセスは、まずプロダクトキーを元にプロダクトIDを生成し、その後プロダクトIDとハードウェアハッシュを元にインストールIDを計算。そしてインス

    Windows XPの認証システムは完全に突破されていてオフラインでアクティベート可能
  • SSHブルートフォースログイン攻撃を防ぐ基本的な対策

    Sucuriはこのほど、「How to Prevent SSH Brute Force Login Attacks」において、SSHブルートフォースログイン攻撃を防ぐための基的なセキュリティ対策を紹介した。 How to Prevent SSH Brute Force Login Attacks SSHブルートフォース攻撃は、UNIXベースのサーバ上で安全なリモート接続のために使用されるSSHサービスを標的にするサイバー攻撃の一つ。攻撃者は自動化されたツールやボットを使用し、一般的なユーザー名とパスワードの組み合わせを継続的に試行してサーバへのアクセスを試みる。SSHログインの試行回数が多すぎる場合、SSHサーバがブルートフォース攻撃の標的になっている可能性は高い。 SSHブルートフォース攻撃を行う攻撃者の動機はさまざまとされ、貴重な財務情報やファイルへの不正アクセス、サービスの妨害、他

    SSHブルートフォースログイン攻撃を防ぐ基本的な対策
  • やはりお前らの「公開鍵暗号」はまちがっている。

    ※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証(人確認)をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に:暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して

    やはりお前らの「公開鍵暗号」はまちがっている。
  • 送信ドメイン認証の現状

    2019/09/07 DNS温泉6 in 下呂 で利用したスライドです。 内容的にマズい部分は改変してあります。 時間的に古いものですので、現在と相違がある部分もあります。

    送信ドメイン認証の現状
  • SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ

    SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの(再)取得 図解 ログイン アクセストークンの(再)取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか ReactVueで認証付きSPA(Single Pa

    SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
  • Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita

    元ネタ @localdisk さんの記事です。 こちらで概ね適切に説明されているものの,文章のみで図が無くて直感的に把握しづらいので,初心者にもすぐ飲み込ませられるように図に描き起こしてみました。 図 解説 illuminate/auth: 最小限の認証認可コアロジック コアコンポーネント群の laravel/framework に含まれているものです。 Socialite 以外のすべてのパッケージが,実質このコアに依存していることになります。 以下の記事でこのパッケージの詳細について説明しているので,ここでは端折って説明します。 伝統的 Cookie ベースのセッション認証 こちらでも解説している, 「Cookie に識別子を載せ,それに対応する情報はサーバ側のファイルに記録する」 という手法に近いものです。 実装は illuminate/session にあり, PHP ネイティブのセ

    Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita
  • 心臓の音で個人認証、精度95%以上 音のリズムやピッチを分析

    Innovative Tech: このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 スペインのUniversity Carlos III of Madrid、イランのShahid Rajaee Teacher Training University、イランのInstitute for Research in Fundamental Sciences (IPM)による研究チームが開発した「ECGsound for human identification」は、心電図から取得した心拍音を分析し、その人が誰かを特定するバイオメトリクス技術だ。心電図(ECG)信号をオーディオ波形ファイルに変換し、5つの音楽的特性を分析することで識別する。 今回はこれまでと違い、ノイズ(直流成分や

    心臓の音で個人認証、精度95%以上 音のリズムやピッチを分析
  • WebアプリケーションでJWTをセッションに使う際の保存先は(自分なりに説明できれば)どちらでもよいと思います - 日々量産

    以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き?— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門~PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ? - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -

    WebアプリケーションでJWTをセッションに使う際の保存先は(自分なりに説明できれば)どちらでもよいと思います - 日々量産
  • おーい磯野ー,Local StorageにJWT保存しようぜ!

    ある日,HTML5のLocal Storageを使ってはいけない がバズっていた. この記事でテーマになっていることの1つに「Local StorageにJWTを保存してはいけない」というものがある. しかし,いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく. 先の記事では,「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時,攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた. これに対し,クッキーを用いたセッションベースの認証では,セッションIDをクッキーに保存する.クッキーにHttpOnlyフラグをつけておけば,JavaScriptからはアクセスできず,XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない. 一見すると,これは

    おーい磯野ー,Local StorageにJWT保存しようぜ!
  • 不正なリクエストに一泡吹かせたい

    この記事は sadnessOjisan Advent Calendar 2021 25 日目の記事です。 ついに最終日ですね!今日は 02/04 なのですが・・・ 12/25 に Qiita のクソアプリカレンダーに マッチした人の年収を知れるマッチングアプリを作った と言うのを書いたのですが、あまりにも攻撃的なリクエストが飛んできたので閉じました。 で、閉じさせられることに腹が立ってきたので何か仕返しできないかなと思ってこの記事を書いています。 何を作っていたか 年収マッチ と言う、マッチングアプリ です。 マッチング(出会い)した相手とマッチ(対戦)できるというコンセプトです。 「年収を教えてくれる人には自分の年収を教えてもいいよね〜」と個人的に思っていて、それをしやすくするサービスとして作りました。 最終的には 50 人くらいの人が登録してくれていたのですが、一方でリクエストを見てい

    不正なリクエストに一泡吹かせたい
  • あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ

    初めに サイボウズ・ラボの光成です。 いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。 ビットコインでは相手の公開鍵を用いてハッシュ値を暗号化して相手に送る。 TLS1.3ではサーバ公開鍵を用いてAESの秘密鍵を暗号化する。 答えはどれも間違いです。 公開鍵認証は、(デジタル)署名を使って相手先の正しさを検証するものであり、暗号化は行われません。 同様にビットコインもデータや相手の正当性を確認するために署名が用いられ、暗号化は行われません。 TLS 1.3ではRSA暗号の公開鍵を用いて暗号化する方式(static RSA)は廃止され、ECDH鍵共有された値を元に秘密鍵を生成し、AES-GCMなどの認証つき暗号で暗号化します。 公開鍵暗号とは いわゆる公開鍵暗号には大きく2種類の意味があ

    あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ