List of Authentication [text.Baldanders.info]

ぞーぺん（ZonePane）で bsky.social 以外の PDS にサインインする

2026-05-08T11:56:43+00:00

以前書いた「そろそろ PDS を個人で管理する時代か？」で「常用しているぞーぺん（ZonePane）も bsky.social 以外の PDS に対応してない」と愚痴ったのだが ZonePane for Desktop v2.9.18 で bsky.social 以外の PDS (Personal Data Server) にもサインインできるようになった¹。ありがたや。さっそく試してみよう。

bsky.social 以外の PDS でサインインを試す

アカウント追加画面に移動して

アカウント追加より

「Bluesky にサインイン」を選択する。

サインインより

折りたたまれた状態ではあるが「サーバー（PDS）」の項目が追加されている。 Bluesky の既定 PDS である bsky.social であればこの項目は空欄でもいいが，それ以外の PDS のアカウントの場合は PDS のドメインを入力する必要がある。

サインインより

これで「サインイン」ボタンを押せばブラウザの OAuth 認証・承認画面に飛ぶ。

Authorizeより

ここで承認すればサインイン完了である。

Bluesky じゃないほうの PDS を利用している方はプロバイダから PDS 名のアナウンスがあるはずなので必ずメモしておくこと。紛失しちゃった場合は PDSls で確認する手もある。

photos.baldanders.info - PDSlsより

デスクトップ版 ZonePane の Mastodon やら Bluesky やらをゴチャまぜにしてマルチカラムで表示するインタフェースはホンマに重宝していて，もう手放せなくなっている。これからもよろしくお願いします。

v2.9.18 は bsky.social 以外の PDS で OAuth 認証した場合に再認証で PDS ドメイン名を忘れてしまう不具合があったが 2026-05-08 にリリースされた v3.0.0 では修正されていた。

ありがたや 🙇

アプリケーションとデータストレージの抱き合わせはリスクか？

今までは，ユーザから見てアプリケーションとユーザデータ（のストレージ）が一体であることは当たり前だった。分散型と言われる Mastodon でさえストレージはアプリケーション・インスタンスの一部になっていて，別のインスタンスに移りたければインスタンス間でデータの「引っ越し」が必要である（引っ越しができるだけマシだが）。

ここで AT Protocol が登場し Eurosky や Periwinkle といったアカウントとデータを専ら扱う PDS サービスが出てきたことで（ユーザから見た）アプリケーションとユーザデータの関係が変わってきているんじゃないだろうか。たとえば Bluesky は利用したいが Bluesky が擁する PDS に自分のアカウントとデータは置きたくない，といったような。

（上の記事によると，コリイ・ドクトロウ氏は PDS を自前で用意したようだ）

私が pckt.blog サービスのアカウント（photos.baldanders.info）を取得するときには深く考えず「ひとつくらい別 PDS のアカウントがあってもいいだろう」くらいの軽い気持ちだったのだが，最近 atproto エコシステムにおいてアプリケーションとデータストレージの抱き合わせは（アプリケーションがなんであれ）リスクなんじゃないかと思い始めている。

というわけで PDS を引っ越そうか悩み中である。

【2026-05-10 追記】

Andorid 版および iOS 版の ZonePane も最新版で bsky.social 以外へのサインインに対応したようだ。

手元のスマホで試したが問題なくサインインできた。

デスクトップ版 ZonePane は現在「お試し版」の状態で Windows, macOS, Linux (Debian, Ubuntu) で利用可能。 ↩︎

Signal への攻撃手口（ソーシャルエンジニアリング）と防御策

2026-04-28T04:12:54+00:00

今朝，Bluesky と Mastodon の TL に Signal による長いスレッドが上がっていた。 Bluesky のポストは以下から始まるスレッドである（Mastodon のほうも内容は同じ，多分）。

A response to recent reporting in Germany, in service of clarity and accountability: First, it’s important to be precise when it comes to critical infrastructure like Signal. Signal was not “hacked” — in that our encryption, infrastructure, & the integrity of the app’s code was not compromised. 1/
— Signal (@signal.org) April 28, 2026 at 5:53 AM

ちょっと何言ってるか分からなかったので Kagi Assistant と GitHub Copilot に手伝ってもらいながら調べてみた。

もとになってる報道

Signal に対する攻撃，特に phishing を含むソーシャルエンジニアリングについては以前から言われていて，ドイツ BSI (Bundesamt für Sicherheit in der Informationstechnik) も Signal の利用ガイドラインを公開しているほどだ。

にもかかわらずってことなんだろうなぁ。

Signal による声明の直接のトリガーとなっているのは先週のドイツでの一連の報道のようだ。発端は DER SPIEGEL の報道：

Julia Klöckner ist Opfer des Signal-Hacks - DER SPIEGEL

これは有料記事だが，他メディアでもいくつかあった。

この中では Tagesschau の一連の記事が良さげなので Kagi Assistant に要約してもらった。

ドイツの政界や重要機関を標的としたSignalでの大規模なフィッシング攻撃は，国家が関与するスパイ工作の疑いへと発展しています。

被害の規模と対象:
- ドイツ連邦議会のほぼすべての会派の議員が標的となり，ユリア・クレックナー連邦議会議長や，フーベルツ建設相，プリーン家族相といった現職閣僚の被害も確認されています。
- 政治家だけでなく，ジャーナリスト，軍関係者，さらにはNATO関係者も攻撃対象に含まれています。
攻撃の手法:
- 攻撃者は「Signalサポート」を装い，偽のセキュリティ警告でユーザーに接触します。
- ユーザーを騙してPINコードを聞き出しアカウントを完全に奪取するか，あるいはQRコードをスキャンさせて攻撃者のデバイスを連携（同期）させることで，チャット内容や連絡先，過去45日分のファイルを盗み見ます。
当局の捜査と背後関係:
- ドイツ連邦検察庁は，本件を「諜報員活動（スパイ容疑）」として正式に捜査を開始しました。
- ドイツ治安当局（BfVおよびBSI）は，このキャンペーンが「国家主導のサイバー攻撃者」によるものであり，現在も勢いを増していると警告しています。
- オランダの諜報機関や米国のFBIは，この攻撃の背後にロシアの諜報機関が関与していると特定しています。
Signal側の見解:
- Signalは，アプリの暗号化やインフラ自体が突破されたわけではなく，あくまでユーザーを欺くソーシャルエンジニアリングによる攻撃であると強調しています。

大体合ってるかなぁ。ドイツ語はよく分からないので自信がない。

GitHub Copilot が各メディアの報道の違いを表にまとめてくれるというのでやってもらった。

媒体	位置づけ	主なポイント	閲覧性
DER SPIEGEL	初報の可能性が高い	政治家アカウント被害の最初期報道。見出しで「Signal-Hack」と表現	本文はSPIEGEL+（有料）
Tagesschau	検証・整理記事	「最初にSPIEGELが報じた」と明記。ハックではなくフィッシングという整理が明確	無料で読みやすい
taz	補強報道	被害対象，政府見解，手口（偽Signal Support）を具体化。SPIEGEL初報への言及あり	無料
ZEIT	続報	政府・当局側の見方（ロシア関与の可能性）を短く整理	一部制限あり（記事により差）

Signal による声明

というわけで Signal による SNS での声明に戻る。これについても Kagi Assistant に要約してもらった。

攻撃の性質: Signalの暗号化やインフラ自体が「ハッキング」されたわけではありません。実際には，攻撃者が「Signalサポート」を装い，ソーシャルエンジニアリングを用いてユーザーから認証情報を聞き出す巧妙なフィッシング詐欺が発生しています。
手口の詳細: 攻撃者は盗んだ情報でアカウントを乗っ取り，登録電話番号を変更します。被害者には「再登録が必要」と信じ込ませて新しいアカウントを作らせることで，乗っ取りに気づかせないようにします。その後，乗っ取ったアカウントを使って被害者の連絡先にさらなる攻撃を仕掛けます。
Signal側の対応: 今後数週間で，こうした攻撃を阻止するための新機能を導入予定です。
ユーザーへの推奨事項:
- Signalサポートがメッセージリクエストを送ったり，認証コードやPINを尋ねたりすることはないため，警戒を怠らないこと。
- 保護を強化するため，設定から「登録ロック」を有効にすること。

んー。これは大体合ってるはず。

「登録ロック」はアプリの設定の「アカウント」セクションにある項目で，電話番号を変更する際に PIN 入力を要求するらしい。

Signal アカウント設定より

PIN をばらしちゃったらダメだけどね。ちなみに Signal の PIN は英字も含めることができる。

Phishing はシステム侵入の手口としてはありふれていて，しかも人間の行動が関与するから完全には防ぎづらい。故に多層防衛をしていかないと「蟻の一穴」から簡単に class break してしまうことになる。

GitHub Copilot はこうまとめてくれた。

本件は，セキュアな暗号技術がそのまま利用者体験の安全を保証するわけではないことを示した事例である。攻撃者は最も弱い層，すなわち人間の心理と手続きを狙う。ゆえに防御も，暗号強度だけでなく，認証情報を渡さない運用，異常時の確認手順，設定レベルの予防策を組み合わせて成立するのである。

全く以ってそのとおり！

余談だが…

最初の SNS のポストの内容を元に Kagi Assistant と GitHub Copilot に元ネタとなるドイツ報道を調べてもらった。 Kagi Assistant のほうは自前の検索サービスがあり，一発で Tagesschau の記事を引き当てたので問題なかったが， GitHub Copilot はだいぶ難儀していた。

まず DuckDuckGo で調べようとして bot 判定され拒否られる。そこで Bing に切り替えたのだがノイズが多すぎて見つからなかったようだ（「検索エンジンが使いづらい」と愚痴ってた。 AI も愚痴るのかw）。まぁ， Google を使わなかっただけ偉いと言っておこう（笑）

そんで検索サービスを彷徨うのは一旦諦めて Bluesky の該当スレッドを API 経由で取得し，そこからようやく「Julia Klöckner（独連邦議会議長の人）」というキーワードを引き当てた。これを使って Bing で絞り込みをかけた結果，意味のある検索結果を得られたという流れだった。

この GitHub Copilot による一連の作業をチャット上で眺めながら，人間みたいなことをするんだなぁ，と妙なところで感心してしまった。そんでもって，ネット上の調べ物は Kagi Assistant のもんやねぇ，と思う。

そもそも調べ物をするのに検索窓を叩いて調べるとかせんやろ，いまどきは。ノイズに塗れた Web で，かつ主要検索サービスがメタクソ化する状況で「行きたい場所」に到達するには，結局 AI を使わなきゃ無理なのよ。特に今回みたいな漠然とした内容で知らない言語圏の情報を探す場合は。

つまり，もはや AI に認知してもらえないサイトやページは存在しないのと同じで，安易に拒否してるだけでは大海に取り残された某島の生物のようになってしまうだろう。

参考

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

MPA for Linux でログイン検証（Linux で個人番号カードを読む 2）

2026-04-01T06:25:15+00:00

前回の続き。

myna のリポジトリによると，サブプロジェクトの MPA for Linux を使って Linux の Web ブラウザでマイナポータルや e-Tax のサイトに個人番号カードを使ってログインできるらしい。素晴らしい！

Rust ツールチェーンのインストール

事前準備として Rust ツールチェーンのインストールを行う。

Rust の基礎勉強をしてたのはもう6年も前で，仕事に結びつくこともなかったので完全に放置していた。しかも，あれから自宅パソコンを買い替えたりして開発環境もなくなったので，インストールからやり直すことに。

インストールページに従って，以下のスクリプトをダウンロード&実行する。

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
info: downloading installer

Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

...

   default host triple: x86_64-unknown-linux-gnu
     default toolchain: stable (default)
               profile: default
  modify PATH variable: yes

1) Proceed with standard installation (default - just press enter)
2) Customize installation
3) Cancel installation
>

今回はこのまま Enter キーを押して続行。

info: profile set to default
info: default host triple is x86_64-unknown-linux-gnu
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-03-26 for version 1.94.1 (e408947bf 2026-03-25)

...

Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, you need to source
the corresponding env file under $HOME/.cargo.

This is usually done by running one of the following (note the leading DOT):
. "$HOME/.cargo/env"            # For sh/bash/zsh/ash/dash/pdksh
source "$HOME/.cargo/env.fish"  # For fish
source "~/.cargo/env.nu"  # For nushell
source "$HOME/.cargo/env.tcsh"  # For tcsh
. "$HOME/.cargo/env.ps1"        # For pwsh
source "$HOME/.cargo/env.xsh"   # For xonsh

これで ~/.rustup/ および ~/.cargo/ ディレクトリ以下にツールチェーンがインストールされた。 PATH 設定が ~/.cargo/env ファイルに記述されていて ~/.profile と ~/.bashrc が ~/.cargo/env を読み込むよう書き換えられている。必要に応じて内容を調整する。

とりあえず，今すぐ PATH を通したいなら

$ . ~/.cargo/env

とすればよい¹。

起動確認しておこう。

$ rustc --version
rustc 1.94.1 (e408947bf 2026-03-25)

うんうん。問題なさそうやね。 Rust の勉強もやり直すかなぁ。

MPA for Linux のインストール

いよいよ MPA for Linux をインストールする。

適当なディレクトリに github.com/jpki/myna リポジトリを clone する。

$ git clone https://github.com/jpki/myna.git

リポジトリ内の mpa ディレクトリに移動して cargo install を実行する。

$ cd myna/mpa
$ cargo install --path .
  Installing mpa v23.0.0 (/home/username/path/to/myna/mpa)
    Updating crates.io index
     Locking 107 packages to latest Rust 1.94.1 compatible versions
      Adding der v0.7.10 (available: v0.8.0)
      Adding generic-array v0.14.7 (available: v0.14.9)
      Adding sha1 v0.10.6 (available: v0.11.0)
      Adding sha2 v0.10.9 (available: v0.11.0)

         ...

   Compiling myna v0.6.4 (/home/username/path/to/myna)
   Compiling mpa v23.0.0 (/home/username/path/to/myna/mpa)
    Finished `release` profile [optimized] target(s) in 16.86s
  Installing /home/username/.cargo/bin/mpa
   Installed package `mpa v23.0.0 (/home/username/path/to/myna/mpa)` (executable `mpa`)

これで ~/.cargo/bin/ ディレクトリにホストアプリケーション mpa がインストールされた。

次に同ディレクトリにある install.sh を実行してホストアプリケーションをブラウザに登録する。ブラウザのプロファイルが既定の場所にあるのであれば，引数なしで起動すればよい。

$ ./install.sh
=== Installing Native Messaging Host manifests ===
Host path: /home/username/.cargo/bin/mpa

Installed: /home/username/.config/google-chrome/NativeMessagingHosts/com.github.jpki.mpa.json
Installed: /home/username/.config/chromium/NativeMessagingHosts/com.github.jpki.mpa.json
Installed: /home/username/.mozilla/native-messaging-hosts/com.github.jpki.mpa.json

ブラウザのプロファイルが既定のの場所にない場合は

./install.sh --user-data-dir /path/to/datadir

のように指定できるらしい。今回は既定のままでOK。

次にブラウザのほうほうにも拡張機能をインストールする必要があるのだが，正規ルートからはインストールできないようなので Developer mode で強制的に行う。手順は以下の通り。

Chrome

chrome://extensions/を開く

右上のディベロッパーモードをON

パッケージ化されていない拡張機能を読み込むで./mpa/extensionを読み込む

拡張機能のメニューからMPA for Linuxを開く

動作確認ボタンを押してエラーが出なければOK

Firefox(一時的)

about:debuggingのこのFirefoxを開く

一時的なアドオンを読み込むで./mpa/extension/manifest.jsonを読み込む

拡張機能のメニューからMPA for Linuxを開く

動作確認ボタンを押してエラーが出なければOK

ブラウザ拡張のインストールより

メインで使ってる Firefox に入れるのは怖いので，サブとして使ってる ungoogled-chromium で試した。やり方はたぶん Chrome と同じでいいよね。こんな感じ？

ちなみに Developer mode を OFF にするとこの拡張機能も無効になる。これがあるからオススメしにくいんだよなぁ。

これで MPA for Linux の導入は完了。上手くログインできるかなぁ。

マイナポータルサイトにログインする

マイナポータルより

左サイドにあるログインボタンを押してログイン画面に移動する。

ログイン | マイナポータルより

ここで暗証番号の入力を求められる。

暗証番号入力より

利用者証明用パスワード（4文字の数字）を入力して OK ボタンをクリックする。ボタンをクリックせず Enter キーを押すとなにも起こらず処理が止まってしまうので注意（困るなぁ）。

ホーム | マイナポータルより

よし。上手くいった！

e-Tax サイトにログインする

e-Tax サイトのログインは個人用と法人用がある。私は個人用からログインする。

個人ログイン | e-Taxより

下の方にスクロールすると

個人ログイン | e-Taxより

「ICカードリーダーで読み取り」ボタンがあるので，これをクリックする。あとは前節と同じように暗証番号の入力を求められるので，利用者証明用パスワード（4文字の数字）を入力して OK ボタンをクリックする。

TOP | e-Taxより

こちらも問題なく入れた！

これで Linux 機で確定申告できる！

マイナポータルおよび e-Tax の両サイトへのログインを確認できたので，ブラウザ拡張機能の Developer mode を OFF に戻しておく。

これで来年は自宅 Linux 機で確定申告できるな。もうスマホで確定申告するのは嫌なのよ。スマホは入力端末としては向かないっスよ。

ミニ PC の Windows 機はますますゲーム専用機になっていくな（笑）まぁ，それはそれで重宝しているからいいか。

参考

スーパーユーザーなら知っておくべきLinuxシステムの仕組み: Brian Ward (著), 柴田芳樹 (翻訳); インプレス 2022-03-08 (Release 2022-03-08); 単行本（ソフトカバー）; 4295013498 (ASIN), 9784295013495 (EAN), 4295013498 (ISBN); 評価

版元で PDF 版が買える。セキュリティ・エリアにも持ち込めるよう紙の本を買ったのだが，オンライン読書会が始まったので PDF 版も購入。Linux システムの扱い方に関するリファレンス本として優れている。最初に軽く流し読みして，必要に応じて該当項目を拾い読みしていけばいいだろう。

reviewed by Spiegel on 2023-02-11 (powered by PA-APIv5)

コマンドの . は source と同じ意味で，指定したファイルを現在の shell で実行する。 ↩︎

NIST SP 800-63-4 最終版がリリース

2025-08-28T08:34:43+00:00

以前「誰が「パスワードは複雑なものにしろ」と言ったのか」でちょろんと紹介した NIST SP 800-63-4 の最終版が2025年7月に公開されたようだ。見落としてたよ。

これは以前の NIST SP 800-63-3 を置き換える内容となっている。 NIST のブログ記事によると，主な変更点は以下の通りらしい。

Updates to context setting for risk management, reframed risk management processes, and new expectations for greater cross-functional engagement.

New recommended continuous evaluation metrics.

Expanded fraud requirements and recommendations for identity proofing processes.

Restructured identity proofing controls to better define roles and types of identity proofing.

Added controls for addressing injection attacks and forged media (e.g., “deep fakes”).

Integration of syncable authenticators (e.g., synced passkeys).

Representation of subscriber-controlled wallets in the federation model.

via Let’s get Digital! Updated Digital Identity Guidelines are Here!

とりあえずこの記事ではリンクのみ指示しておく。そのうち詳しく話す機会があるかもしれない。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

誰が「パスワードは複雑なものにしろ」と言ったのか

2024-12-02T14:06:54+00:00

いつものように yomoyomo さんの記事を起点に小咄を。

長年の誤ったパスワードポリシーが推奨された原因はあの偉人の論文だった？ - YAMDAS現更新履歴

この記事の元ネタが更にあって，ボクらの Bruce Schneier 先生の記事で紹介されている以下の記事。

How some of the world’s most brilliant computer scientists got password policies so wrong | Mildly-Aggrieved (not mad!) Scientist

これは古のパスワード生成ルール「パスワード文字列は英数字と記号の三種盛りにしろ」とか「パスワードは定期的に変更しませう」とかの元ネタが何かって話らしい。記事によると Robert Morris さんと Ken Thompson さんが1979年11月に公開した “Password Security: A Case History ” という論文が大元なんだとか。 Ken Thompson さんは Go 言語開発者のひとりなんだね。

First, was Morris and Thompson’s confidence that their solution, a password policy, would fix the underlying problem of weak passwords. They incorrectly assumed that if they prevented the specific categories of weakness that they had noted, that the result would be something strong.

via How some of the world's most brilliant computer scientists got password policies so wrong

この記事では言及されてないが，更に悪いことに，この考え方で NIST SP 800-63 のほうも実装されてしまったらしい。このせいで悪名高きパスワード生成ルールが世に蔓延ることになったわけだ。

以下は改訂された NIST SP 800-63-3 が正式リリースされた2017年の ZDNET Japan の記事。

　大文字、小文字、数字、記号を使った覚えにくいパスワードを作らされ（しかもそれを定期的に変更することを義務づけられ）て、どうしてこんなルールがあるのかと憤ったことがある人は多いだろう。それはおそらく、どこかの開発者が、米国立標準技術研究所（NIST）が2003年に作成した文書に従ったためだ。

　この8ページの「NIST Special Publication 800-63別表A」は、NISTの元管理職であるBill Burr氏によって作成された。同氏はすでに引退しており、今では72歳になっている。

　Burr氏は、The Wall Street Journalの取材に対して、「今では、わたしが決めたことの大部分について後悔している」と語った。

あの「面倒なパスワード作成ルール」、作った人も後悔していた - ZDNET Japanより

“How some of the world’s most brilliant computer scientists got password policies so wrong” では更に

That mistake was their recommendations on how passwords should be stored. They recommended that systems should not store passwords, but instead assign each user a random “hash” function used to compute a number (the hash) from that users’ password.

[…]

Storing numeric hashes instead of the passwords can protect users whose passwords are hard to guess, but it also prevents scientists from examining those passwords to determine if there might be categories of common (weak) passwords that users should be discouraged, or prevented, from choosing. While Morris and Thompson did not invent password hashing 3, they implemented it into Unix, strongly recommended it, and their paper would be the one most cited to support the necessity of password hashing.

via How some of the world's most brilliant computer scientists got password policies so wrong

などと書いている。ユーザによるパスワード生成の実態をサービスプロバイダ側が把握できなかったせいで「間違い」が放置されたままだったというのだ。少なくとも論文が登場した1979年には公開鍵暗号は発明されてたんだからハッシュ関数を使うのではなく公開鍵暗号を使えばよかったとか言ってるようだ。

まぁ「研究者」としてならこれはこれで正しいのかも知れないが，エンジニアとしてはパスワード情報の秘匿に公開鍵暗号を使うのが「善」なのか首をひねるところがある。そもそも記事で挙げている RSA は20世紀当時は特許でガチガチに固められていて，しかも米国外では（軍事的な理由で）使用不可なアルゴリズムだったので，実質的には無理な話だったと思う。

いや，パスワードを（ハッシュ化ではなく）暗号化するのはいいけど，その鍵をどうやって管理するのかって話ですよ。厳格な管理が要求される Bitcoin 交換所でもたまに漏洩事件が起きたりするんだよ。

もしもの話として，パスワードを公開鍵暗号の公開鍵で暗号化するとして，ひとつの鍵ペアで全部のパスワードを暗号化するわけないし（そんなことして万が一秘密鍵が解読されたり漏れりしたら全ユーザのパスワードが晒されてしまう），そうなるとユーザごとに鍵ペアが必要ってことになるだろう（無数の鍵ペアを使うにしても秘密鍵をひとつところに置いていれば同じことだがw）¹。つか，そんなことするくらいならパスワード認証なんかやめて公開鍵暗号を使って認証すればいいぢゃん。 ssh みたいに。

パスワード生成のルール化はどちらかというとユーザ体験（UX; User eXperience）の問題と言える。パスワードの複雑化や定期更新を強制するのは，そのほうがシステム管理側が楽だからだ。そして面倒な部分をユーザ側に「転嫁」しているのだ。セキュリティ・マネジメントの観点で「転嫁」戦略は悪いことではないが，不特定のユーザにそれを強いてもユーザはただ迂回するだけである。これは「悪い UX」の典型と言える。

そういえば『はじめて学ぶビデオゲームの心理学』に UX の起源みたいな話があって

ドナルド・ノーマン（大きな影響力をもつ『誰のためのデザイン？ —— 認知科学者のデザイン原論』（Norman, 1990）の著者）は「ユーザー体験（UX：user experience）」という単語を提唱し、製品やそのエコシステム（マーケティング、ウェブサイト、顧客サービスなど）にユーザーが関与するときの体験全般を考えるという方針を示しました。そのため、企業やグローバル戦略も UX に含まれます。

『はじめて学ぶビデオゲームの心理学』 p.34より

という感じに UX 自体が1990年代以降の考え方らしい。ルールによってユーザの行動がどう変わるかみたいな話を1979年の論文で考慮しろってのが無理筋である。

まぁ，歴史に「たられば」はないっちうことやね。

ところで，最初に挙げた yomoyomo さんの記事を読んで気がついたのだが NIST SP 800-63-4 のドラフト版って2022年に公開されてるんだね。しかもパブコメの募集は先々月の10月で締め切られているらしい。

NIST SP 800-63 Digital Identity Guidelines

まぁでもここから正式版が出るまでが長いならなぁ NIST は。気長に待ちましょうか。

ブックマーク

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

はじめて学ぶビデオゲームの心理学脳のはたらきとユーザー体験（UX）: セリアホデント (著), 山根信二（監修） (著), 山根信二 (翻訳), 成田啓行 (翻訳); 福村出版 2022-12-15 (Release 2023-07-03); Kindle版; B0C9Z7KGRN (ASIN); 評価

Kindle 版が出ている。ゲームデザイナやゲームエンジニアだけでなく，ソフトウェア・エンジニアは全員読むべき。あと，ゲーマーな人も読むといいよ。感想はこちら。

reviewed by Spiegel on 2023-11-21 (powered by PA-APIv5)

さらに別のもしもの話として，生のパスワード情報を暗号化してどっかに保持って（実際の認証ではなく）統計情報にのみ使うとして，その結果をユーザの行動にどう反映させるのか，という問題もある。メディアで定期的にヤバいパスワードランキングが公表されるが，あれはそういったパスワード情報が既に攻撃手段として用いられている（だろう）と分かってるからできることだ。一方，私たちユーザ側の考え方としては，拙文「「パスワードのベストプラクティス」が変わる」でも書いてるが「パスワードを覚えるなんて脳みその無駄使い」である。人間は複雑というか機械が予測不能な文字列をいくつも思いつけるようにはできていない。パスワード認証を使うならパスワード管理ツールで生成も管理も任せてしまったほうが安全ってことだと思う。 ↩︎

KeePassXC に TOTP を設定する

2023-08-17T12:48:05+00:00

私が愛用しているパスワードマネージャ KeePassXC の 2.7.6 がリリースされていた。

Release Release 2.7.6 · keepassxreboot/keepassxc · GitHub

これで思い出したのだが Google Authenticator を捨てて TOTP 管理を KeePassXC に一元化しようとしてたのだった。すっかり忘れてたよ。

KeePassXC は KeePass 2.x 互換のアプリケーションで Windows, Linux, macOS で動作するマルチプラットフォームのアプリケーションである。特に KeePassXC は標準機能で TOTP のシークレットを登録してワンタイムパスワードを振りだすことができる¹。

（以下は Ubuntu 環境でのセットアップ）

TOTP の設定はコンテキストメニューから可能。

KeePassXC コンテキストメニュー

「TOTP の設定」を選択すると以下のウィンドウがポップアップする。

KeePassXC TOTP の設定

ここの「秘密鍵」の項目に各サービスで振り出されるシークレット（あるいは秘密鍵）を入力する。他は「既定の設定 (RFC 6238)」のままで大抵は問題ない。

たとえば 𝕏 (旧 Twitter) の場合なら，設定でセキュリティとアカウントアクセス → セキュリティ → 2要素認証と進み

Twitter 2要素認証

QRコード（上の図は塗り潰してる）の下の “Can’t scan the QR code?” のリンクをクリックすると

Can't scan the QR code?

という感じにシークレットが表示されるので（上の図の塗り潰してる部分），そのままコピペすればよい。これでコンテキストメニューから TOTP のワンタイムパスワードが取得可能になる。

KeePassXC コンテキストメニュー

たとえば「TOTP を表示」を選択すると，こんなウィンドウが表示される。

KeePassXC TOTP を表示

TOTP の設定を紛失すると，最悪の場合，そのサービスに二度と入れくなくなる。サービスで2要素認証を設定したなら，必ずリカバリーコード（あるいはバックアップコード）をダウンロードし保存しておくこと。紙に出力しておくのもいいだろう。ただしリカバリーコードの管理は慎重に。

…よしよし。これでまたひとつ Google 依存が減ったな。

ブックマーク

Google Online Security Blog: Google Authenticator now supports Google Account synchronization : この記事を見て Google Authenticator を捨てようと思ったのだった
Ubuntu に KeePassXC を導入する
Authenticator と AAL

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

KeePassXC の機能についてはリポジトリページを参照のこと。他に KeePass 2.x 互換のアプリケーションとして Android 用の Keepass2Android というのもあって，こちらも TOTP に対応している。 iPhone 版は知らん。 ↩︎

それはワンタイム・パスワードの問題ではない

2021-11-07T09:28:00+00:00

いやさ

狙われるワンタイムパスワード、多要素認証を破る闇サービスが浮上：この頃、セキュリティ界隈で（1/2 ページ） - ITmedia NEWS

て酷い釣りタイトルだよな，と思いつつモニタにツッコんでしまったよ（笑）

ハッキリ言おう。それはワンタイム・パスワードの問題ではない。

ワンタイム・パスワードに問題がないわけではない。 NIST SP 800-63B によればスマホの TOTP アプリや専用のワンタイム・パスワード機器は「単要素 OTP デバイス（Single-Factor One-Time Password (OTP) Device）」と呼ばれる。これはタイプとしては「知識」ではなく「所有」に分類される。所有型の Authenticator には紛失・盗難のリスクが伴う。また，基本的に OTP は認証する側とされる側との間で最初にシークレットを共有する必要があり（特にアプリでは）シークレットの受け渡しと管理の問題が発生するが，認証の段階でこのシークレットをやり取りすることはない。

しかし，上の記事の「ワンタイムパスワード」はこれとは異なる。 SMS やチャット・アプリ等を通してサービスプロバイダから使い捨てシークレットを通知し，シークレットをもらったユーザは通知を受けたチャネルとは別のチャネル（大抵はスマホ・アプリかブラウザで表示される Web ページ）でシークレットを返す。送ったシークレットと返ってきたシークレットを比較して認証を行うわけだ。こうした仕組みは NIST SP 800-63B の分類では「経路外デバイス（Out-of-Band Devices）」と呼ばれている。

経路外デバイスが筋が悪いのは攻撃者から見て攻撃ポイントが多いことだ。上の記事で示される事例はまさにそこを突かれて認証を突破されている。

以前に拙文「Authenticator と AAL」で紹介したが，元々 NIST は SMS を使った認証を非推奨（または禁止）にするつもりだった。

SMSを使った二要素認証を非推奨〜禁止へ、米国立技術規格研究所NISTの新ガイダンス案 | TechCrunch Japan

しかしその後，色々あったようで，最終的には “RESTRICTED Authenticator” という位置づけまで緩和されてしまった。

The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used.

via NIST Special Publication 800-63B

でも，結局その「温情措置」が重大なセキュリティ・インシデントを招いているのだから「なんだかなぁ」という感じである。電子メールや VoIP が経路外デバイスとして NG なら SMS だって NG だろう。

Authenticator による認証には3つのレベル（Authenticator Assurance Level; AAL）があるが，最初の記事の事例にあるような「暗号資産」を扱う重要な決済システムなら AAL3 は必須だろうし，そうであるなら認証手段として経路外デバイスを選択するのはあり得ない。これは「闇」でも何でもなく，単にサービス・プロバイダが間抜けで迂闊だったというだけの話である。

道具は適切に組み合わせないと所定の性能を発揮できない。私達エンジニアはこのことを肝に銘じておくべきだし，利用者としても「利便性はセキュリティとトレードオフできない」ことは知っておくべきだろう。

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

Authenticator と AAL

2020-09-27T10:45:38+00:00

どうも日本の金融界は「リスク感度が鈍い」そうなので，自衛のためにも2017年にリリースされた NIST SP 800-63-3 をベースに少しお勉強しておく。

SP 800-63-3 といえばパスワード運用で当時は話題になった。

「パスワードのベストプラクティス」が変わる

このパスワード話が出てくるのが SP 800-63B だが，このドキュメントでは Authenticator 全体について色々と書かれている。

Authenticator

Authenticator について適切な日本語が見当たらないが，強いて言うなら「認証機能」あるいは「認証器」といったところだろうか。たとえばパスワードも Authenticator だし，スマホにインストールした TOTP アプリも Authenticator だ。 Yubikey なんかの暗号デバイスも Authenticator に含まれる。

SP 800-63B では Authenticator を以下の9つに分類している。

種別名	認証要素
Memorized Secrets 記憶シークレット	知識
Look-Up Secrets ルックアップ・シークレット	所有
Out-of-Band Devices 経路外デバイス	所有
Single-Factor OTP Device 単要素 OTP デバイス	所有
Multi-Factor OTP Devices 多要素 OTP デバイス	所有＋知識／生体
Single-Factor Cryptographic Software 単要素暗号ソフトウェア	所有
Single-Factor Cryptographic Devices 単要素暗号デバイス	所有
Multi-Factor Cryptographic Software 多要素暗号ソフトウェア	所有＋知識／生体
Multi-Factor Cryptographic Devices 多要素暗号デバイス	所有＋知識／生体

また，各 Authenticator の例としては以下のものが挙げられる。

Authenticator	具体例
記憶シークレット	パスワード，PINコード
ルックアップ・シークレット	乱数表，認証失敗時のリカバリコード
経路外デバイス	SMS によるコード送信， QR コード（電子メールや VoIP は認められない）
単要素 OTP デバイス	アクティベーションを必要としない OTP デバイスまたはソフトウェア
多要素 OTP デバイス	アクティベーションを行った上で利用可能な OTP デバイスまたはソフトウェア
単要素暗号ソフトウェア	セキュアなストレージ上で保護されている暗号鍵
単要素暗号デバイス	FIDO U2F の USB ドングル
多要素暗号ソフトウェア	単要素暗号ソフトウェアに対して追加のアクティベーションを必要とするもの
多要素暗号デバイス	単要素暗号デバイスに対して追加のアクティベーションを必要とするもの

Authenticator Assurance Level

さらに SP 800-63B では AAL (Authenticator Assurance Level) を定義している。 AAL は 1 〜 3 の3段階あり，それぞれ以下に示す Authenticator の組み合わせを許容している。

AAL 1 では9種の Authenticator 全て許容され，単要素の認証で OK
AAL 2 では以下に示す通り複数の認証要素による多要素認証が必要：
- 多要素 OTP デバイス
- 多要素暗号ソフトウェア
- 多要素暗号デバイス
- 記憶シークレット＋以下
  - ルックアップ・シークレット
  - 経路外デバイス
  - 単要素 OTP デバイス
  - 単要素暗号ソフトウェア
  - 単要素暗号デバイス
AAL 3 では以下に示す通り，暗号鍵の所持証明要素とハードウェア関与を含む複数の認証要素による多要素認証が必要：
- 多要素暗号デバイス
- 単要素暗号デバイス＋記憶シークレット
- 多要素OTPデバイス(SW/HW)＋単要素暗号デバイス
- 多要素OTPデバイス(HW)＋単要素暗号ソフトウェア
- 単要素OTPデバイス(HW)＋多要素暗号ソフトウェア
- 単要素OTPデバイス(HW)＋単暗号ソフトウェア＋記憶シークレット

AAL の各レベルごとに要求されるセキュリティ事項（一部）は以下の通り。

要求事項	AAL 1	AAL 2	AAL 3
中間者攻撃耐性	必須	必須	必須
Verifier なりすまし耐性	不要	不要	必須
Verifier 改ざん耐性	不要	不要	必須
リプレイ耐性	不要	必須	必須
認証意図（AuthN Inbtent）	不要	推奨	必須
レコード保持ポリシー	必須	必須	必須
プライバシー統制	必須	必須	必須

金融系サービスの subscriber 確認で乗っ取りやなりすましを防ぎたいなら AAL 3 で何らかの物理暗号デバイスが必要だと思うけどねー。

格子型の乱数表は NG

現在は使ってるところはないだろうが，かつてネットバンキングでよく見られた格子型の乱数表はルックアップ・シークレットとしても NG だそうだ。まぁ，当然だよな。

SMS 認証は非推奨？

NIST は SMS によるコード送信について， SP 800-63-3 のドラフト段階では非推奨にするつもりだったらしい。

SMSを使った二要素認証を非推奨〜禁止へ、米国立技術規格研究所NISTの新ガイダンス案 | TechCrunch Japan

しかしその後，激しい議論があったようで，最終的には “RESTRICTED Authenticator” という位置づけまで緩和されたようだ。

Currently, authenticators leveraging the public switched telephone network, including phone- and Short Message Service (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator types may be added as additional threats emerge. Note that, among other requirements, even when using phone- and SMS-based OTPs, the agency also has to verify that the OTP is being directed to a phone and not an IP address, such as with VoIP, as these accounts are not typically protected with multi-factor authentication.

via NIST SP 800-63 Digital Identity Guidelines-FAQ

（スマホを含む）電話機に依存した認証は，プライバシーも絡めて考えると筋が悪い。ぶっちゃけ SMS 認証を含む経路外デバイスを使った認証は排除するか（ルックアップ・シークレットのように）優先順位を下げて非常時のみ使えるようにするのがいいと思う。もちろん電話番号を広告に流用するなど以っての外である。

生体情報は Authenticator として使えるか

Authenticator の分類を見れば分かるように，生体情報は単独では認証手段としては使えないという認識のようだ。そもそも生体情報は秘密情報ではないのだから当たり前といえば当たり前かな。

ブックマーク

参考図書

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

ついカッとなって機種変した，反省はしない

2020-05-14T15:02:50+00:00

5年前に買ったスマートフォンなのだが，相変わらずバッテリ周りが酷くて今のが3台目だったのですよ。その3台目も2年と経たずにイカれてしまい（勝手に強制リブートを繰り返すようになった）ついカッとなって機種変更した。失業して銭のないときになんちう迷惑な。

近所（田舎の近所なので察してください）の au ショップに駆け込んで「テザリングが使えるいっちゃん安い機種を」と言ったら Galaxy A20 を勧められた。端末代が税込で 33,000JPY とのことで即金で買いましたよ。もはやスマホにこれ以上パラダイム・シフトの夢を見ることはないし，スマホでゲームはしないからスペックも最小限で無問題だよね。

2要素認証するならリカバリ・コードは控えておくこと

今までの反省から，旧端末から認証情報やデータを移行できない可能性を考慮して準備しておいたのは助かった。

特に2要素認証¹ の2要素目で TOTP を使っている場合は認証不能になる場合があるので，サービス側が発行するリカバリ・コードを必ずダウンロードして控えておくこと。なんなら紙に印刷して厳重にしまっておけば確実だろう。

言い換えると2要素認証を推奨しているのにリカバリ・コードの提供すらしないサービスはダメなサービスだと断言していいだろう。まぁ SMS に一時パスワードを垂れ流して「2段階 認証だから安全」とか言ってくさるサービスとかあるけどな（笑）

最近流行りの認証デバイスを使えばそんな面倒もないんだろうけど，個人的には紛失・盗難リスクが怖くてノートパソコンや携帯端末に認証デバイスを使う気にならないんだよねぇ。

最初にすること

まずは OS のアップデートを行うこと。最近の端末は最初からストレージの暗号化がされてるんだね。よーし，うむうむ，よーし。

で，アプリのアップデートを行う前に既定で入ってるアプリで使わないものは削除する。中には削除できないものもあるが，そういうのは，アップデート前であれば，見分けがつくので最初にやってしまおうってわけ。

なんで LINE や Facebook や Twitter のアプリが最初から意味もなく入ってるんだろうねぇ。ぜんぶ削除ですよ。あと端末メーカー製やキャリア製のアプリで明らかに使わないものは可能な限り削除する。ついでに Google 製の不要アプリもザクザク削除。

これで，すっきり！

雑多な作業

「最初にすること」が終わったらパスワード管理アプリを入れる。

Keepass2Android

私の場合，データベースファイルをクラウド・ストレージに置いているので，クラウド・ストレージにアクセスするアプリも併せて導入する。暗号鍵は USB で PC に直結して端末にコピってしまう。暗号鍵とパスワードでデータベースファイルを二重にロックしておけば大丈夫だろう。

その後

File Explorer Pro

を導入して LAN 上の NAS に入れるよう設定すれば一段落。

他にセキュリティ関連アプリとして

を導入してセットアップする。 Signal は既定の SMS アプリとしても設定できるので置き換える。

ブラウザは

を導入し Firefox Focus の方を既定のブラウザにする。 Firefox は予備系とし Chrome や他のブラウザは使わないようにする。もちろん検索サービスにはどちらも DuckDuckGo を指定する。

Input method は

Gboard

で無問題。ていうか，これ以外使いたくない。

あとは好みで

あたりを順次入れていく。 5年前に比べればだいぶ顔ぶれが変わったなぁ。

Microsoft Launcher を導入してみた

各端末メーカーが既定で入れてるランチャってなんであんなにダサいのかね。いや，デザイン・センス皆無の私に言われたくないだろうけど。

今までは「どうせすぐ壊れるから」と手を付けなかったんだけど，今回は試しに Microsoft Launcher を導入してみた。セットアップ時に Microsoft account を要求するのだが，大昔に登録したのがまだ有効だったようで，問題なく行けた。位置情報も要求されるが，許可しなくても無問題（もしくは後から許可を取り消せる）。

ちなみに検索バーと連携する検索サービスに DuckDuckGo を指定できる。使わんけどね。

「デバイスを探す」で避難訓練

ひととおり設定が終わったら「デバイスを探す」で一度は避難訓練をしておくとよいだろう。携帯端末の捜索についてはキャリアも端末メーカーもサービスを提供しているが，キャリアはともかく，端末メーカーのサービスは無用である。

「デバイスを探す」では検索対象の携帯端末に対して「音を鳴らす」「デバイスのロック」「データの消去」といった操作ができる。「音を鳴らす」と「デバイスのロック」については一度は試してみることをお勧めする。

端末を探す

今だに「2段階認証」とかぬかす馬鹿メディアがあるみたいだが「2段階」では不十分だから「2要素」が要求されるのだ，ということを分かっているのだろうか。 ↩︎

7iD リスク

2019-07-07T07:26:46+00:00

7pay の件は Twitter の TL に流れてくる情報を中心に眺めていたが，2010年代も終わろうかという頃に「サイバーノーガード戦法」とかあまりに馬鹿すぎて他山の石にもならないようだ。リンクは以下の2つだけ張っておけば十分だろう。

被害にあった方々にはお見舞い申し上げるとともに（被害額の返金だけではなく）賠償請求を行ってきちんとペナルティを支払わせることを強くお勧めする。向こうは「謝罪して返金すりゃいいんだろ」って感じだし。バブル崩壊以降，ホンマに「謝罪」が安くなったよなぁ。まぁお金が絡む話に謝罪とか，それこそ一銭の価値もない。

今回の件は脆弱性（vulnerability）というより設計上の欠陥（defect）と位置づけるのが適切だろう。そうなると，その認証基盤である 7iD（旧 omni7）ってどうなん？という話になる。

で，サイトを覗いてみたら提携企業の多さに「これヤバくね？」って感じなのだが，それらの企業は今回の件をどう思っているのかね。現金決済であれキャッシュレス決済であれ，基盤となるシステムを信用するからこそ成り立つものであり，信用がなくなれば「そこで試合終了」なんだけど。

今後も情報を集めるとしたら，その辺を重点的に見る必要があるかもなぁ。

そもそも「QR決済」以前に「QRコード」そのものを信用していないので¹，「QRコード」が絡むサービスは極力使わないようにしているのだが，今後もしばらくその状態は続きそうである。

あと Twitter 眺めてて気になったのだが「2段階認証（2-step authentication）」と「2要素認証（2-factor authentication）」は意味が違うし，昔は「2段階認証」と称してパスワードを2つ登録させる馬鹿なサービスもあって安全性に対する印象が悪いのだけど，みんながみんな「2段階認証」を連呼するのはその辺も踏まえての話なのかね。

ブックマーク

7payの「二段階認証導入」は正解か？　セキュリティ専門家、徳丸氏の視点 (1/2) - ITmedia NEWS
セブン、「7iD」全ユーザーのパスワードをリセット　セキュリティ強化の一環で - ねとらぼ
- 「よーやくか」と思ったが，よく考えたら 7iD はパスワード変更機能が腐っていて，そこからパスワードが漏洩したんじゃないかって当初言われてたっけ。やっぱ設計がクソだと何もかもが裏目に出るな
ひさしぶり「サイバーノーガード戦法」 | Baldanders.info

参考図書

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

社会における「信頼」とは。

reviewed by Spiegel on 2015-11-28 (powered by PA-APIv5)

だってQRコードのあの図形を見ても何についての情報かすら分からないし（human-readable でない），汎用のスキャナを使って復号した情報を確認してから使うのならまだしも，最近のQRコードを使ったサービスはそれすら省いてる感じだし，使いたくない。 ↩︎