メインコンテンツまでスキップ

Web + DB vol.136

パスキー

パスキーの登場

  • はじめに
    • FIDO / Fast IDentity Online
      • パスワードをなくすためのプロトコル群の総称
    • WebAuthn
      • FIDO に対応した FIDO 認証機を JavaScript API から呼べるようにしたもの
      • あまり普及していない
    • Passkey
      • FIDO や WebAuthn の UX 上の課題を解決したもの
  • パスワードの限界
    • 利用するサービスが増えるほど漏洩につながる
    • 使いまわし
  • 使いづらい 2 段階認証
    • 有効にしているのは全体の 1%未満
    • TOTP / 焦らされる、あるいは待たないといけない
    • セキュリティキー / 高い、コネクタの種類が多い
  • 強いシークレットの 3 条件
    • 記憶しないでいい
    • 毎回違う
    • 手入力しないでいい
  • パスワードレス認証
    • Magic Link
      • コスト安い
      • 信頼性低い
      • 3 条件のうち「手入力しないでいい」を満たさないのでフィッシングに無力
    • SMS 認証
      • コスト高い
      • 信頼性は Magic Link より高い
      • 3 条件のうち「手入力しないでいい」を満たさないのでフィッシングに無力
    • デバイス認証
      • WebAuthn による
      • 記憶しないでいい・毎回違う・手入力しないでいい
        • 3 条件を満たすのでフィッシングに耐性を持つ
      • ただし鍵を他のデバイスに移行できないので、端末移行時や紛失時が超面倒
        • 100 個のサービスで使っていれば 100 回再登録が必要 😰
    • パスキー
      • デバイス認証のダメな点を改善したもの
        • フィッシング攻撃への耐性は維持しつつ、デバイス紛失時のリカバリも容易にした
      • FIDO の用語でいう Discoverable Credential
        • デバイス認証の鍵を、他のデバイスに移行できるようにしたもの

パスキー時代の UX

  • 種類
    • 登録
    • 認証
    • 再認証
  • 注意
    • パスキーはそれ自体で 2 要素認証を満たしている
      • ローカル認証(顔、指紋、PIN) + 公開鍵によるリモート認証
    • よってパスキーをパスワード認証のあとの 2 段階目としても意味はないので注意
  • 登録の UX
    • 過渡期なのでパターンは確立していない
    • 既に登録済みのユーザーに、ログイン直後にお知らせする、とかが良さそう
  • 認証の UX
    • ワンボタンログイン
      • 究極にシンプルだが、普及するまではまだ使えないと思った方がいい
      • 実例は少ない
    • フォームオートフィルログイン
      • オートフィルの候補にパスキーが出てくるのでそれを使う方法
      • 最も現実的
    • ユーザー名指定ログイン
      • 最初の画面でユーザ名を入力させ、次の画面でパスキーを入力させる方法
      • 過渡期の妥協案。あまり推奨しない。
      • Google や Yahoo はこれ。
  • 再認証の UX
    • 特定のアカウントに紐づいたパスキーしか入力できない点が認証時と異なる
    • ゼロクリックログイン、とでも呼ぶべきか
  • (番外編)スマホでデスクトップにログイン
    • iOS と Windows など、異なるプラットフォームではパスキーが同期されないものの、それでもパスキーでログインしたい場合の方法
    • デスクトップで「近くのデバイスからのパスキー」などを選択すると QR が表示されるので、それをパスキーをもつスマホで読み込む
    • WebAuthn でいう Hybrid(旧 caBLE)という規格

(実装に関する記事は省略)

Go の強み

以下のおかげメンテナンス性が高いこと。 冗長な部分は Copilot などで補える。

  • エラー視認性が高い
    • 上から下に読めて見やすい
  • 動的コード生成がない
    • マクロ、Mixin などは便利な反面わかりにくい
  • 依存関係が堅牢
    • 同僚の PC では違うバージョンが使われてエラーが起きるみたいなことがない

複雑なクエリの読み方

  • 手順
    • クエリを分解する
    • 実行計画を見る
    • 対象のテーブルを見る
  • クエリの分解
    • SQL が実行される順で読んでいく
      • FROM
      • JOIN
      • WHERE
      • GROUP BY
      • HAVING
      • SELECT
      • ORDER BY
      • LIMIT
    • SELECT 句をいったん*にまとめるのもアリ
    • サブクエリがあるならサブクエリの単位で切りだして読む
    • FROM, WHERE をもとにベン図その他を書いてみる
  • 実行計画
    • EXPLAIN / EXPLAIN ANALYZE
  • 対象のテーブルを見る
    • DDL を見る / SHOW CREATE TABLE hogehoge_table
    • ER 図を見る
    • データの量を SELCT COUNT で見る
    • データの分布や傾向を SELECT DISTINCT や GROUP BY で確認する
  • 責務を分解する
    • よくある分け方
      • 前準備としてのデータの加工処理
      • データを絞り込む処理
      • データを集計する処理
      • データを並び替える処理
    • N+1 問題には注意
  • ビューを活用する / WITH 句
    • 以下に最適
      • CASE 式を使っているクエリ
      • 複数の結合を行っている複雑なクエリ
  • テーブル設計を見直す
    • ダメな設計を SQL でカバーするのは無理

Intl / 日時・数値のフォーマット、多言語化の最新手法

  • Intl / ECMA-402
  • フォーマッター初期化時に全てのオプションを指定しなければならないのが特徴
const jpYenFormatter = new Intl.NumberFormat('ja-JP', {
style: 'currency',
currency: 'JPY',
});

jpYenFormatter.format(1000); // => "¥1,000"
  • よく使いそうなもの
    • Intl.DateTimerFormat()
    • Intl.NumberFormat()