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