List of Password [text.Baldanders.info]

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

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); 評価

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

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)

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

Ubuntu 22.04 LTS へのアップグレード

2022-05-06T09:07:48+00:00

Ubuntu が「22.04 LTS にアップグレードせんのん？（← 超意訳）」と煩いので GW で余裕のある間にアップグレードすることにした。今回は特に（少なくとも最近の機械では）日本語周りで不具合の話も聞かなかったし。

Ubuntu 22.04 リリースノート

今回は特に大きな問題はなし。

日本語入力周りは問題なく動いている。 Ubuntu コミュニティのご尽力に感謝
21.10 から Firefox は Snap 版になっているのに何故か言語パッケージが APT で提供されているというチグハグな状態だったが，今回で統一された？
Thunderbird は相変わらず GnuPG の鍵束を認識してくれない。そろそろ捨てようか
LibreOffice は 7.3 系。 OpenPGP 鍵で暗号化したファイルもちゃんと開けるし，問題ないだろう。 Snap 版は相変わらず評判が悪いようだ（笑）
KeePassXC は既に jammy リポジトリがある。依存ライブラリのバージョンが違うらしい
pgAdmin4 は jammy リポジトリがまだ用意されてない模様。こちらはしばらく様子見か
Node.js は NodeSource で v18 系をインストールしてみた。今のところは問題なし。なにかあれば v16 (LTS) に戻すつもり

いつものように GnuPG が古い

$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/username/.gnupg
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,
      TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

まぁ v2.3 系でないのはしょうがないにしても，せめて今の LTS 最新版（v2.2.34）にしてくれよ orz

OpenSSH と OpenSSL

$ ssh -V
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022

OpenSSL は v3.0.3 のセキュリティ・アップデートに対応したバックポート・パッチが出ているようだ。相変わらず分かりにくい。普通にバージョンを上げてくれんもんかねぇ。

ちなみに GnuPG の gpg-agent との連携は問題なかった。

Docker と apt-key

これに関しては記事を分けた。後半へ続く（笑）

ブックマーク

Ubuntu 21.10 へのアップグレード（本番）

2021-11-06T11:49:34+00:00

前回の続き。

Ubuntu 21.10 日本語 Remix が登場したので，自宅のサブマシンに真っさらからインストールしてみたが，前回アレだった日本語周りも特に問題なく動いてる感じなので，いよいよメインマシンをアップグレードすることにした。

アップグレード作業自体は滞りなく完了。

日本語入力周りは問題なく動いている。 Ubuntu コミュニティのご尽力に感謝
前回書いたとおり Firefox は Snap 版になっていたが，こちらも問題なし。日本語フォント周りも壊れることなくちゃんと設定された
Thunderbird が 91 系にアップグレードされている。今のところは特に問題なし
LibreOffice が 7.2 系にアップグレードされている。 OpenPGP で暗号化したファイルもちゃんと開けるし，問題ないだろう
KeePassXC は 21.10 リリース以降アップデートされてないため APT リポジトリを impish に切り替えれない（apt update でワーニングが出る）しばらくは様子見か
同じく pgAdmin4 も 21.10 リリース以降アップデートされてないため APT リポジトリを impish に切り替えれない。こちらもしばらくは様子見

Japanese Team の APT パッケージ・リポジトリは以下のコマンドで追加できる。

$ sudo wget https://www.ubuntulinux.jp/ubuntu-jp-ppa-keyring.gpg -P /etc/apt/trusted.gpg.d/
$ sudo wget https://www.ubuntulinux.jp/ubuntu-ja-archive-keyring.gpg -P /etc/apt/trusted.gpg.d/
$ sudo wget https://www.ubuntulinux.jp/sources.list.d/impish.list -O /etc/apt/sources.list.d/ubuntu-ja.list
$ sudo apt update

mount.cifs で手こずる

アップグレードして再起動したら NAS に接続できなくなったのには焦った。

もしかしたら Ubuntu 21.04 以降で Active Directory に対応したことが影響してるのかも知れないが， SMB でマウントする際の認証情報で domain または workgroup オプションでドメイン名またはワークグループ名を明示しないとダメぽいみたい。でも，なんで前のバージョンで上手くいってたのか…

まぁ，でも，今は /etc/fstab ファイルで設定するのは時代遅れみたいなので，見直しが必要かなぁ。

[root tip] systemd mount unit samples - Tutorials - Manjaro Linux Forum

GnuPG が古すぎる

GnuPG は

$ gpg --version
gpg (GnuPG) 2.2.20
libgcrypt 1.8.8
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/username/.gnupg
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,
      TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

と，相変わらず古すぎる。 2.3 系にしないのは仕方ないとしても，せめて 2.2.32 相当には上げておかないと拙いと思うのだが，その気配はないよね。

OpenSSH と OpenSSL はこのままでいいか

OpenSSH と OpenSSL は

$ ssh -V
OpenSSH_8.4p1 Ubuntu-6ubuntu2, OpenSSL 1.1.1l  24 Aug 2021

となっている。バックポート・パッチが当たっているはずなので，あまり気にしてない。次の LTS バージョンである Ubuntu 22.04 では OpenSSL 3.0 に上げるらしいので，おとなしく待つことにしよう。

やっぱ問題は GnuPG だよな。まぁ，サブマシンを真っさらの Ubuntu 機にできたので，これを使って GnuPG 2.3 系の実験を始めるのもいいかも知れない。

ブックマーク

Ubuntu に KeePassXC を導入する

2019-08-25T03:05:20+00:00

以前に Mono 版の KeePass を導入する手順を紹介したが Linux 用であればサードパーティの KeePassXC がよさげである。

KeePassXC は KeePass のサードパーティ版である KeePassX の fork でマルチプラットフォームに対応している。 Windows や macOS の他，各種 Linux ディストリビューションにも対応しているようだ。

【2020-05-28 修正】 Ubuntu では APT または Snap から導入できるのだが， Snap 版は日本語入力ができない（日本語の文字列のコピペは可能）という致命的な欠点があるため PPA リポジトリを使って最新版をインストールする。

まずは PPA リポジトリの登録から。

$ sudo add-apt-repository ppa:phoerious/keepassxc
$ sudo apt update

これで KeePassXC がインストール可能になった。

$ apt show keepassxc
Package: keepassxc
Version: 2.5.4-1ppa1~focal1
Priority: optional
Section: utils
Maintainer: KeePassXC Team <team@keepassxc.org>
...

あとは普通に apt install すればよい。

$ sudo apt install keepassxc

これで Ubuntu のメニューから KeePassXC を起動できる。

おおっ，日本語だ（笑）

使い方は本家の KeePass とだいたい同じようだ。ブラウザ連携は今のところ怖くて使う気にならない。まぁ，そのうち気が向いたらね。

ブックマーク

パスワード・マネージャに関する走り書き

2019-06-20T12:34:14+00:00

（これは Facebook の TL に書いた記事です。今後の考察のためのメモとして残しておきます）

今週のおすすめ記事。

Before You Use a Password Manager – Stuart Schechter – Medium

パスワードおよびパスワード・マネージャによる管理についてよくまとめられている。パスワード・マネージャの比較表もあるので参考になるだろう。

セキュリティ専門家の Bruce Schneier 氏はこの記事に対して

My particular choices about security and risk is to only store passwords on my computer -- not on my phone -- and not to put anything in the cloud.

via Risks of Password Managers - Schneier on Security

と述べておられるが，そんな運用は私には無理。まぁ，どこまでを自分の制御下に置くかがセキュリティ・トレードオフの勘所なのかもねぇ。

セキュリティ管理の首根っこを掴まれるのは搾取される第一歩だ。 Android が登場した当初，あまりにダサい iTunes と比較して

「PCを母艦にするのは時代遅れ，これからはクラウドが母艦の時代」

と思ったものだが「監視資本主義」が台頭する今では認識を少し改めたほうがいいかもしれない。

超監視社会: ブルース・シュナイアー (著), 池村千秋 (翻訳); 草思社 2016-12-13 (Release 2017-02-03); Kindle版; B01MZGVHOA (ASIN)

実は積ん読のまま読んでない。そろそろちゃんと最後まで読まないと。

reviewed by Spiegel on 2019-03-23 (powered by PA-APIv5)

もうすぐ絶滅するという開かれたウェブについて続・情報共有の未来: yomoyomo (著); 達人出版会 2017-12-25 (Release 2019-03-02); デジタル書籍; infoshare2 (tatsu-zine.com); 評価

WirelessWire News 連載の書籍化。感想はこちら。祝 Kindle 化！

reviewed by Spiegel on 2018-12-31

Ubuntu に Mono を導入する

2019-04-14T10:36:23+00:00

今回は Mono および Mono で動くアプリケーションを導入する。

Mono の導入

Mono を導入するにはリポジトリの登録から始める必要がある。 gnupg と ca-certificates は既に入ってるみたいなので公開鍵のインポートとソースリストの追加から。

$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
$ echo "deb https://download.mono-project.com/repo/ubuntu stable-bionic main" | sudo tee /etc/apt/sources.list.d/mono-official-stable.list
$ sudo apt update

続いて mono-devel を導入する。

$ sudo apt install mono-devel

インストール処理が完了したら念のため動作確認をしておこう。

$ mono -V
Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	Interpreter:   yes
	LLVM:          yes(600)
	Suspend:       hybrid
	GC:            sgen (concurrent by default)

よーし，うむうむ，よーし。

KeePass の導入

KeePass は OSS のパスワード管理ツールで，基本的には Windows 用だが各種プラットフォーム用のバージョンが公開されている。 Ubuntu では APT で導入可能である。

$ sudo apt show keepass2
Package: keepass2
Version: 2.39.1+dfsg-1
Priority: optional
Section: universe/utils
Origin: Ubuntu
...

ちょっとバージョンが古いがプラットフォームが違うし，まぁいいだろう。インストールしてしまおう。

$ sudo apt install keepass2

インストールが完了するとドックのアプリボタンで表示されるアプリ一覧にアイコンが追加される。あとは Windows 版と同じように使える。

パスワードを覚えるなんて脳みその無駄遣い。適切な管理ツールでパスワード管理を行いましょう。

Keepass2のフォントを日本語化 | Pagent

Git Extensions の導入

Git Extensions は .NET Framework 上で動く git 用の GUI フロントエンドだが， Mono 版もあって他プラットフォームでも利用できる。ただし Mono 版はバージョン 2 系までしか対応していないので注意が必要である。

ダウンロードページから Mono 版の最新バージョンをダウンロードする。

適当なディレクトリにダウンロードした zip ファイルを unzip コマンドで展開する。 GitExtensions ディレクトリが作成されてファイルが展開されている筈である。

展開されたファイルの中に gitext.sh があるので，これに実行権限を付与して起動する。今後のためにパスを通しておいたほうがいいだろう。

最初に Git Extensions を起動すると言語の選択ウィンドウが表示される。

日本語があってよかったね。あとは Windows 版と同じ。

けど Windows 版と比べて操作感がイマイチなんだよなぁ。まぁ Git Extensions をメインに作業するわけではないので，これでもいいか。

【追記 2019-04-20】 Git Extensions が落ちる

Ubuntu を 19.04 にアップグレードしたら Git Extensions が落ちるようになってしまった。似た事例がないかと探してみたら GitExtensions/Plugins/Bitbucket.dll を削除したら行けるみたいな記述を見かけたので試してみたら上手く行ったっぽい？

How to install GitExtensions in Ubuntu

やれやれだぜ。

Git Extensions の代わりになるような GUI フロントエンドを探しているのだがいいのがない。コミットやタギングで電子署名を付与できて結果を検証できればいいのだが，特にタギングに署名できる製品がない。 GitKraken v5.0 ならいけると思ったのだが設定画面が分かりにくい上にフリー版だと署名の検証ができないっぽい？

.NET Framework と Mono と .NET Core

.NET Framework と Mono と .NET Core の関係がいまひとつ分からなかったのでちょろんと調べてみた。かなり大雑把な説明なのはご容赦。

.NET Framework

.NET Framework が最初に公開されたのは2001年。基盤となる CLI (Common Language Infrastructure) や CLR (Common Language Runtime) は標準化され Windows 以外のプラットフォームでも実装可能となるよう設計されたが，実際にはリファレンス実装である .NET Framework は Windows 以外には対応しなかった。まぁ，当時の Microsoft は FOSS に敵対的だったし，それもやむなしというところだろうか。

Mono と Xamarin

当然ながら，.NET Framework に対抗する OSS 製品を作ろうという動きがあり，そのうちのひとつが Mono Project であった。 Mono はマルチプラットフォームで動作するアプリケーション基盤として実装されているのが特徴である。

Mono を巡っては紆余曲折があったが（生臭い話は省略），最終的に Xamarin が開発母体となった。

Xamarin は Mono Project のオーナー企業であると同時に Mono を基盤とした製品群を指すようだ。なので今後は Mono/Xamarin と一括りにしてしまおう。

企業としての Xamarin は後に Microsoft に買収され Mono/Xamarin は Microsoft 傘下である .NET Foundation において今も開発が続けられている。

.NET Core

一方，実質 Windows でしか動作しない .NET Framework の派生として .NET Core が Microsoft からリリースされた。 .NET Core はマルチプラットフォームで動作する OSS 製品として，こちらも .NET Foundation で開発が行われている。

ここに於いて Microsoft は経営方針の大転換を果たしたわけだ。

.NET Core と Mono/Xamarin

現在 Microsoft は OSS の .NET シリーズとして .NET Core と Mono/Xamarin の2系統の製品を持っている。両者の棲み分けは以下のような感じらしい。

ASCII.jp：.NET Core / .NET Framework / Xamarin / Monoの関係を整理するより

つまり Linux や macOS，あるいは iOS や Android の GUI アプリケーションとしては Mono/Xamarin，サーバ・サイドあるいはクラウド向けには .NET Core ということのようだ。さらに将来的には Windows アプリケーション向けの .NET Framework，マルチプラットフォーム向けの .NET Core と Mono/Xamarin の基盤を共通化すると表明されている。

ASCII.jp：.NET Core / .NET Framework / Xamarin / Monoの関係を整理するより

そうなったら Mono も役目を終える感じになるのかねぇ。

ブックマーク

「避難訓練」の事前と事後

2019-02-11T02:10:15+00:00

最初に言い訳しておくと，私がセキュリティ管理者だったのはずいぶん昔の話だし今は職業エンジニアですらないので，セキュリティ関連の話題を深く追いかけることはしないようにしている。そのせいかどうかは分からないが，日本政府が一般家庭に「サイバー攻撃」を仕掛けるというニュースを最初に聞いたのは先月末，しかも皮肉なことに海外ブログ経由だったりする。

元ネタは NHK ニュースらしいので多分「知ってる人は（とっくに）知ってる」状態なのだろう。日本のいわゆる「セキュリティ・クラスタ」がどういう議論を行ってきたか（行わなかったか）は知らないし知る気もないが，海外からは

I am interested in the results of this survey. Japan isn't very different from other industrialized nations in this regard, so their findings will be general.

via Japanese Government Will Hack Citizens' IoT Devices

という感じで注目されているらしい。そして

I am less optimistic about the country's ability to secure all of this stuff -- especially before the 2020 Summer Olympics.

via Japanese Government Will Hack Citizens' IoT Devices

と続く。

今回の日本政府による「サイバー攻撃」がどのようなものであれ，その結果を犯罪者側は知ろうとするだろうし確実に利用されるだろう¹。私も “less optimistic” という印象だ。

たとえば大企業などでは従業員に対して偽の Phishing メールを送ったりネットワークに接続する機器に「不正アクセス」を仕掛けたり，といったことが行われる。これは一種の「避難訓練」で，接続機器の安全性を確かめたり従業員のセキュリティ意識を高めたりするのが目的である。

しかしこういった「避難訓練」は事前の教育と事後のフォローがあって初めて成り立つものである。事前の教育は今更なのでしょうがないとして（日本ってホントに教育費をケチるよねぇ），日本政府は「リスト攻撃」で危険な機器のリストを作り上げて（おそらく膨大な数になるだろう），それからどうするつもりなのだろう。

サービスプロバイダや企業に対するものとは違い一般家庭への「あくてぃぶさいばーでぃふぇんす（笑）」はあまり現実的ではない気がするが… そいういった「事後」についてどうするのか，といったことがメディアからは聞こえてこない。聞きそびれているのか（政府やメディアが）意図的に言わないのか，それとも何も考えてないのか（「何も考えてない」に100カノッサ）。

とりあえず，この機会にパスワード管理について改めて見直すのがいいだろう。ルータやネットワーク家電といった所謂 IoT 機器に関しては

購入時の初期パスワードから変更しましょう（頻繁に変える必要はない）
機器ごとに異なるパスワードを設定しましょう
パスワードの作成・管理で人間の脳みそはあてになりません。パスワード管理ツールを使いましょう。不安なら紙に書き出しておくのも可

といったところだろうか。昔はルータの WAN 側で防衛できていればよかったが（引き続きそれは重要だが），今はスマホなどの携帯端末も含めていくらでも侵入経路があるからね²。

ちなみに IPA ではパスワードに使う文字種と文字数ごとにパスワードの解読コストを調べていて³，ちょっとデータが古いが

利用する文字種類数と内訳				パスワード長
種類数	数字	文字	シンボル	4文字	8文字	12文字	16文字
10種	0-9	なし	なし	1円未満（$2^{13.3}$）	1円未満（$2^{26.6}$）	約35円（$2^{39.9}$）	約35万円（$2^{53.2}$）
36種	0-9	a-z	なし	1円未満（$2^{20.7}$）	約100円（$2^{41.4}$）	約1.65億円（$2^{62.0}$）	約276兆円（$2^{82.7}$）
62種	0-9	a-z A-Z	なし	1円未満（$2^{23.8}$）	約7,500円（$2^{47.6}$）	約1,120億円（$2^{71.5}$）	約165京円（$2^{95.3}$）
94種	0-9	a-z A-Z	! " # $ % & ' ( ) = ~ \| - ^ ` ¥ { @ [ + * ] ; : } < > ? _ , . /	1円未満（$2^{26.2}$）	約21万円（$2^{52.4}$）	約16.5兆円（$2^{78.7}$）	約129,000京円（$2^{104.9}$）

パスワード解読の想定コスト例（情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より）

という感じ。

文字種を増やしても8文字程度じゃ話にならないのがわかると思う。英数字を混ぜて12文字以上ならとりあえず安全かな。

ブックマーク

参考図書

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

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

なにせ犯罪者側が普段は他の通信トラフィックに紛れてチマチマやっていることを白昼堂々と大規模にやってくれるんだから，彼らは大歓迎だろう。「日本政府からのアクセス」という Phishing もできそうだ。防衛という点に関しては警察はあてにならないだろうし。 ↩︎
なので家庭内 LAN は用途ごとにセグメントを分けるのが吉。これからは家庭内にも検疫ネットワークが必要になるかも知れないねぇ。 ↩︎
資料によると「利用できる文字種類すべてを完全にランダムに選択して作ったパスワードを一つ一つ調べる全数探索により1日で解読しようとした際にかかるおおまかな想定攻撃コスト」とある。「全数探索(暗号鍵の総数256)でDES10を1日で解読するためのコストを約250万円と仮定します」とあるが2013年頃の資料なので，今はクラウドの利用コストも下がってるし，もっと安上がりにできるかも知れない。 ↩︎

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

2017-10-16T10:21:02+00:00

Bruce Schneier 氏の “Changes in Password Best Practices” の内容が簡潔だったので「そのうち紹介しなくちゃ」と思っていたが，先を越されたっぽい感じなので，便乗記事として上げておく（笑）

やばいパスワード - 複雑なパスワードを強制、でも破られやすいという現実：ITpro

まずは “Changes in Password Best Practices” で挙げられている3つの要件を以下に紹介する。

Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don’t help that much. It’s better to allow people to use pass phrases.
top it with password expiration. That was an old idea for an old way we used computers. Today, don’t make people change their passwords unless there’s indication of compromise.
Let people use password managers. This is how we deal with all the passwords we need.

強調部分は私によるものである。

生成規則が複雑なだけのパスワードではダメ

最初の要件は，いたずらに複雑なパスワード生成規則を強要するな，というものだ。ここで勘違いしてもらっては困るのだが，これは「複雑なパスワードはダメ」と言っているのではない。

パスワードの要件は

できるだけ文字数が多いこと
出来るだけ文字種が多いこと
出来るだけランダムに文字を選ぶこと

の3つである。これを人力で作って覚えるのは難しい。

パスワードの強度に関して IPA が2013年に発表した資料がある。

情報漏えいを防ぐためのモバイルデバイス等設定マニュアル：IPA 独立行政法人情報処理推進機構
- 情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編

このうちの「解説編」にパスワードの解読されやすさの一覧表がある。以下に引用しよう。

利用する文字種類数と内訳				パスワード長
種類数	数字	文字	シンボル	4文字	8文字	12文字	16文字
10種	0-9	なし	なし	1円未満（$2^{13.3}$）	1円未満（$2^{26.6}$）	約35円（$2^{39.9}$）	約35万円（$2^{53.2}$）
36種	0-9	a-z	なし	1円未満（$2^{20.7}$）	約100円（$2^{41.4}$）	約1.65億円（$2^{62.0}$）	約276兆円（$2^{82.7}$）
62種	0-9	a-z A-Z	なし	1円未満（$2^{23.8}$）	約7,500円（$2^{47.6}$）	約1,120億円（$2^{71.5}$）	約165京円（$2^{95.3}$）
94種	0-9	a-z A-Z	! " # $ % & ' ( ) = ~ \| - ^ ` ¥ { @ [ + * ] ; : } < > ? _ , . /	1円未満（$2^{26.2}$）	約21万円（$2^{52.4}$）	約16.5兆円（$2^{78.7}$）	約129,000京円（$2^{104.9}$）

パスワード解読の想定コスト例（情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より）

見たらわかると思うが，文字種の多さより文字数の多いほうがインパクトがあることが分かる。数英大小文字記号すべて使って8文字のパスワードを作っても1日で解読完了させるコストは21万円ほどだが，これは数字だけで16文字からなるパスワードよりもコストが低い。

ただしこれは最もコストの高い「総当たり攻撃」の場合である（しかも4年も前の話だ）。

利用できる文字種類すべてを完全にランダムに選択して作ったパスワードを一つ一つ調べる全数探索により1日で解読しようとした際にかかるおおまかな想定攻撃コストを示しています。ここでは、全数探索(暗号鍵の総数256)でDES10を1日で解読するためのコストを約250万円と仮定します。また、パスワードを1つ検査するのとDESの暗号鍵を1つ検査するコストは同じであるとし、パスワードを求めるのに必要な計算量(検査する個数)が半分になればコストも半分、2倍になればコストも2倍になるものとしています。

情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より

したがって辞書にあるような単語を組み合わせたパスフレーズの場合は，余程の単語数が必要になる。たとえば「やばいパスワード」で紹介されている方法では

テレビは1日1時間 → Terebi ha 1 niti 1 Jikan  → Terebiha1niti1Jikan

といった感じで19文字のパスワードを生成していて，先程の表で照らし合わせると，総当たり攻撃なら，ほとんど天文学的なコストになるが，実際にはそれぞれの単語が攻撃側の辞書にある場合は，たったの6単語しかないわけで，やり方によっては解読コストをかなり引き下げられる可能性もある（犯罪者側の最近の事情をよく知らないので杞憂かもしれないが）。

パスフレーズというのは，もともと「辞書攻撃」などない長閑な時代に PGP などのセキュリティ製品に採用されていたもので（今でも GnuPG ではパスフレーズが使用できる）

I could tell you my pass phrase, but then I would have to kill you.

みたいな比較的長い文（phrase）を使うことを想定している¹。したがってパスワード解読技術が向上している今の時代に単語を組み合わせただけのパスフレーズがどこまで効果的かは正直に言って分からない。しかし “Password!1” みたいな「法令遵守の観点から社内規則に則ってはいるけど機械で容易に推測可能なパスワード」よりは遥かにマシということなのである。

パスワードの有効期限など無意味

2番目の要件は既に散々言われていることなので今更であろう。

週末スペシャル：「パスワードの定期変更はすべきでない」，他

【追記】パスワード定期変更の起源？

「JNSAメールマガジン　臨時号　2015.4.3.」によると

パスワードの定期的な変更は、パスワード文字列が4文字だった時代にパスワードの総当たり攻撃(ブルートフォース攻撃)の対策として実施したことが起源と言われている。

JNSAメールマガジン　臨時号　2015.4.3.より

なんだそうだ。ホンマかいな（笑）

むしろ，ネットワーク管理者やセキュリティ管理者が自分たちの仕事（アカウント管理）を面倒臭がって「放っておいても期限切れになる」パスワード運用を強制した，のほうに1票いれるよ。

パスワード管理ツールを使え

3番目の要件もおなじみのやつである。

最近はウイルス対策ソフトを提供しているセキュリティ企業がパスワード管理ツールも提供していたりするので，そちらを使う手もある。私としては KeePass を是非オススメするが。

KeePass Password Safe

KeePass はオープンソースのパスワード管理ツールで Windows の .NET Framework 用だが Linux 用に Mono で動作するバージョンも存在する。また Android や iOS で動作する互換アプリも存在する。

Keepass2Android Password Safe - Google Play

パスワード管理ツールにはデータ暗号化にマスタパスワードを要求するものが多いが， KeePass では暗号鍵ファイルで暗号化できるのでマスタパスワードも不要だ（マスタパスワードと組み合わせることも可能）。暗号鍵ファイルさえ適切に管理すればパスワードを格納した DB ファイルをクラウドに置いて（他人に見えないところに置いてね）機器間で共有することもできる。

パスワードを覚えようとか考えないこと

いつも言っていることだが「パスワードを覚えるなんて脳みその無駄使い」である。最初に述べた3要件を満たすパスワードをツールで生成させてツールで管理すればよい。どうしても不安ならば紙に書いて誰にも知られないように管理する手もある。パスフレーズだって「覚えないといけない」という点では同じことなのだ。

「セキュリティと利便性のトレードオフ」なんてのは昔の話である。適切な運用をすればセキュリティも利便性も両方確保できる。それをしないのは単なる怠慢だ。

ブックマーク

参考図書

PGP―暗号メールと電子署名: シムソンガーフィンケル (著), Garfinkel,Simson (原著), ユニテック (翻訳); オライリー・ジャパン 1996-04-01; 単行本; 4900900028 (ASIN), 9784900900028 (EAN), 4900900028 (ISBN); 評価

良書なのだが，残念ながら内容が古すぎた。 PGP の歴史資料として読むならいいかもしれない。

reviewed by Spiegel on 2014-10-16 (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)

この物騒なパスフレーズは Simson Garfinkel 氏の『PGP』に載っていたものである。パスフレーズは文字数や文字種の制限がないのが特徴である。もし入力に日本語（UTF-8）が使えるのなら，海外の犯罪者に対しては，かなり強力なパスフレーズができると思うんだけどねぇ。 ↩︎

週末スペシャル：「パスワードの定期変更はすべきでない」，他

2016-07-02T13:37:46+00:00

最近「週末スペシャル」しか記事がないのはマジで忙しいからです。仕事は大事だけど，仕事しかできない状況というのは本当に辛い。こんなん長く続けてたら心がすり減っちゃうよ。

あー，はい。いつもの愚痴ですね。

「パスワードの定期変更はすべきでない」

「パスワードの定期変更はすべきでない」というのはセキュリティに敏い人たちの間ではほとんど常識のようになっているが，企業等ではあまり浸透してないようである。私自身も，ここのところ参加しているプロジェクトでは何故か定期的なパスワード変更を強要する職場ばかりあたっていてウンザリしている。そういうところに限ってパスワード変更の手続きが面倒だったり，パスワードジェネレータのひとつも提供されなかったりする。

わけがわからないよ。

「歩いて考える」

歩いて考える（文章を書く心がけ）｜結城浩｜note

「歩く」行為は脳に適度な刺激がいくようで，仕事で煮詰まってる時でも歩きまわってるうちにひょこっとアイデアが浮かぶことが多い。

たとえば休憩がてらトイレにでも行こうと席を立って10歩も歩かないうちに「あ，そうか！」と思いつくことがよくある（そしてトイレに行きそびれるw）。なんなんだろうね，これ。なので，考え事をする際はできれば歩き回っていたいのだが，職場でそれをやるとあからさまに嫌がれるのでしょうがなく自粛している。

これって，一種の機会損失だよね（笑）

今年のカープはなぜ強い？

相変わらず今年もカープの監督采配は下種である¹。

にも関わらず，なんやかんやで「打ち勝って」しまうのが今年のカープの強さだと思う。今年は監督采配が必要な局面が少ないということもある。ある意味すごいチームになってしまったものだ。

チームスポーツは，プレイヤー（とサポーター）がそのチームに対してどれだけ loyalty を持てるかだと思うが，チームは愛してても上司に恵まれない子たちが育つとああいう風になってしまうということだろうか。しかし，それをいかにも監督采配のおかげだなどと言ってしまう一部の人達（◯川くんとかw）が困りものである。あれって「来年は僕も混ぜてよ」アピールなのだろうか。

まぁともかく，このままどこまでいけるかが見ものである。まかり間違って優勝でもしようものなら… 宴会するしかあるまい！宴会費用を貯めておかなきゃ（笑）

ようやく『サイクス＝ピコ協定百年の呪縛』を読み終わった

いやぁ，たまには趣味や仕事以外の「もっと頭のよくなるような本²」も読まなくちゃね。

にしても世界史は難しい。世界史は学校でまともに習わなかったからなぁ。

私は歴史はみんな歴史「物語」だと思っている。「史実」は点で，点をつなぐ線は「物語」である。だから歴史物を読むときは何が点で何が線なのかを注意して読むようにしている³。その点，近代史や現代史は馴染みのある分だけ分かりやすいが，物語としては登場人物が多すぎてちょっとややこしい。

池内恵さんの文章（Facebook のタイムライン等も含む）は『イスラーム国の衝撃』を読んで以来，中東や欧州を理解するためのリファレンスのひとりとして注目している。まえがきにも書かれているが『サイクス＝ピコ協定百年の呪縛』は「中東ブックレット」の第1冊目という位置付けだそうで，これから続刊が出るようである。楽しみ。

その他の気になる記事

参考図書

【中東大混迷を解く】サイクス=ピコ協定百年の呪縛 (新潮選書): 恵, 池内 (著); 新潮社 2016-05-27; 単行本（ソフトカバー）; 4106037866 (ASIN), 9784106037863 (EAN), 4106037866 (ISBN); 評価

欧州および中東の近代および現代を「サイクス=ピコ協定」を特異点として網羅的に解説していいる。

reviewed by Spiegel on 2016-07-02 (powered by PA-APIv5)

イスラーム国の衝撃 (文春新書): 池内　恵 (著); 文藝春秋 2015-01-20 (Release 2015-01-28); Kindle版; B00SINS1HU (ASIN); 評価

「イスラーム国」だけでなく近代以後（特に 9.11 以後）の中東の歴史について理解を深められる良書

reviewed by Spiegel on 2015-01-31 (powered by PA-APIv5)

新聞なんかの監督コメントを読むと緒方監督って完全に「解説者目線」でチームを見てるよね。それならとっとと監督なんかやめて解説者になったほうがいいんじゃないだろうか。と Facebook のタイムラインでつぶやいたら「かな子のマネージャになればいい」とレスポンスがあった。確かに（笑） ↩︎
竹本泉「ブックスパラダイス」より（笑） ↩︎
たまに「見たんか！お前」と思わず本にツッコミを入れたくなるようなのがあるのよ。特に「ノンフィクション」ジャンルとか。 ↩︎

個人番号カードを発行してもらいました

2016-02-16T03:47:08+00:00

実は昨年末に申請したのにさっぱり音沙汰なしで私も忘れてたんだけど，先日交付の案内が来たので区役所に行ってきた。

申請は Web でできる。顔写真を提出しないといけないが，スマホの自撮りで大丈夫なようだ。

交付に際して準備するもの

個人番号通知カード（あの紙ペラのやつ）
交付案内のハガキ
身分を証明するもの（運転免許証等）
住基カード（既に持っている人のみ）

一応，印鑑も持って行ったのだが不要だった。

未成年の場合は法定代理人と同伴する必要があり，法定代理人の身分証明も必要。自分で受け取りに行けない場合¹ は代理人を立てることができる。この場合は委任状（交付案内のハガキに書く欄がある）が必要で，事前にパスワード等を決めておく必要がある。

既に住基カードを持っている人は個人番号カードと交換になるようだ。なお，この作業により場合によっては即日交付できないことがあるそうな。

暗証番号およびパスワードを決める

交付に際し，3つの暗証番号と1つのパスワードを決める必要がある。これは役所で説明してくれる。それぞれ

住基関連の事務に必要な暗証番号
電子申請等において個人番号や氏名等の情報をカード（の IC チップ）から読み出すための暗証番号
利用者証明用電子証明書を利用するための暗証番号
署名用電子証明書² を利用するためのパスワード

と役割が異なっているため，全て異なる値にしたほうがよい（役所では3つの暗証番号は同じでもよいと説明されたが，特に3番目は民間利用も想定しているようなので別にしておいたほうが安全）。当然ながらスマホやキャッシュカードの暗証番号を流用するのはダメ。自分や家族の誕生日もダメだよ！

パスワードは英数字で6～16文字で設定できる。ただし英小文字は使えないので文字が36種しか使えない。

IPA の「情報漏えいを防ぐためのモバイルデバイス等設定マニュアル」にパスワードの解読しやすさについて説明した表があるので以下に引用する

利用する文字種類数と内訳				パスワード長
種類数	数字	文字	シンボル	4文字	8文字	12文字	16文字
10種	0-9	なし	なし	1円未満（$2^{13.3}$）	1円未満（$2^{26.6}$）	約35円（$2^{39.9}$）	約35万円（$2^{53.2}$）
36種	0-9	a-z	なし	1円未満（$2^{20.7}$）	約100円（$2^{41.4}$）	約1.65億円（$2^{62.0}$）	約276兆円（$2^{82.7}$）
62種	0-9	a-z A-Z	なし	1円未満（$2^{23.8}$）	約7,500円（$2^{47.6}$）	約1,120億円（$2^{71.5}$）	約165京円（$2^{95.3}$）
94種	0-9	a-z A-Z	! " # $ % & ' ( ) = ~ \| - ^ ` ¥ { @ [ + * ] ; : } < > ? _ , . /	1円未満（$2^{26.2}$）	約21万円（$2^{52.4}$）	約16.5兆円（$2^{78.7}$）	約129,000京円（$2^{104.9}$）

パスワード解読の想定コスト例（情報漏えいを防ぐためのモバイルデバイス等設定マニュアル解説編 2.4.2.2項より）

これは完全にランダムな文字列のパスワードを brute-force 攻撃によって1日で解読する際にかかるコストである。 36種の文字列の場合，8文字のパスワードでもたかだか100円のコストで破れてしまう点に注意して欲しい³。

パスワードを覚えるなんて脳味噌の無駄遣い

これはいつも言っていることだが「パスワードを覚えるなんて脳味噌の無駄遣い」である。人間の頭で考えるパスワードなんてたかが知れている。 brute-force を使うまでもなくもっと簡単に解読できる。

個人番号カードの交付を受ける際は，パスワード管理ツール等を使って事前に3つの暗証番号と1つのパスワードを決めておくとよい。私は Keepass2Android を愛用しているので，交付までの待ち時間で暗証番号とパスワードを生成して登録しておいた。（言うまでもないことだが，パスワード管理ツールのデータベースは確実に暗号化しておくんだよ）

個人番号カードの有効期限

個人番号カード自体は身分証明としても使え，10年の有効期限がある⁴。厳密には交付から10回目の誕生日まで。たとえば誕生日が12月31日の人が今日2016年2月16日に交付を受けたとしたら，2025年12月31日が有効期限となる。そこからさらに延長するのであれば顔写真を撮り直して再交付してもらう必要がある。

ただし署名用電子証明書および利用者証明用電子証明書については有効期限が5年となっている。先程の例でいけば2020年12月31日が有効期限。

役所等から有効期限について事前にアナウンスされることはない（詐欺防止のため？）。したがってカードおよび証明書の管理は自分で行う必要がある。ちなみにカードの有効期限（10年）はカードに印刷されているが⁵，電子証明書の有効期限は空欄になっている。これって自分で書けってことなのかなぁ？

再交付

もちろん個人番号カードの紛失・盗難の際には再交付してもらえる⁶。ちなみに有料（800円＋200円）。その前に一時停止してもらわないといけないが。個人番号カードの裏にコールセンター（24時間受け付け）の番号が書いてあるので控えておくといいだろう。

暗証番号やパスワードの変更も受けつけているそうな。また暗証番号は3回，パスワードは5回間違うとロックアウトされるが，ロックアウトの解除は役所で申請書を書かせられるらしい。面倒だがしょうがないか。

また，氏名・生年月日・性別・住所が変更になった場合（記述間違いの更新を含む）は署名用電子証明書を更新する必要がある。これも有料かな。

個人番号カードにかぎらずカード状のものは紛失・盗難リスクが高いので，むやみに持ち歩かないほうがいいんだけどね。

「仕事が忙しい」は代理を立てる理由にならないらしい。役所によっては土日も受け付けてくれる場合がある。 ↩︎
署名用電子証明書は15歳未満には発行されない。なお，電子証明書を個人番号カードに格納しない選択もできる。これは申請時に選択する。 ↩︎
実際にはこんなに単純ではないのだが，8文字と12文字で解読しにくさが格段にアップするというのは覚えておいていいだろう。 ↩︎
未成年者は5年。 ↩︎
面白いことに有効期限は元号ではなく西暦で書かれている。これって10年後も「平成」とは限らないってことなのかねぇ。 ↩︎
本当は個人番号自体も変更すべきだろうけど。情報漏洩等の場合は変更可能らしいが，現場では抵抗されるだろうなぁ。 ↩︎

List of Password [text.Baldanders.info]

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

ブックマーク

参考図書

Ubuntu 22.04 LTS へのアップグレード

いつものように GnuPG が古い

OpenSSH と OpenSSL

Docker と apt-key

ブックマーク

Ubuntu 21.10 へのアップグレード（本番）

mount.cifs で手こずる

GnuPG が古すぎる

OpenSSH と OpenSSL はこのままでいいか

ブックマーク

Ubuntu に KeePassXC を導入する

ブックマーク

パスワード・マネージャに関する走り書き

Ubuntu に Mono を導入する

Mono の導入

KeePass の導入

Git Extensions の導入

【追記 2019-04-20】 Git Extensions が落ちる

.NET Framework と Mono と .NET Core

.NET Framework

Mono と Xamarin

.NET Core

.NET Core と Mono/Xamarin

ブックマーク

「避難訓練」の事前と事後

ブックマーク

参考図書

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

生成規則が複雑なだけのパスワードではダメ

パスワードの有効期限など無意味

【追記】 パスワード定期変更の起源？

パスワード管理ツールを使え

パスワードを覚えようとか考えないこと

ブックマーク

参考図書

週末スペシャル： 「パスワードの定期変更はすべきでない」，他

「パスワードの定期変更はすべきでない」

「歩いて考える」

今年のカープはなぜ強い？

ようやく『サイクス＝ピコ協定百年の呪縛』を読み終わった

その他の気になる記事

参考図書

個人番号カードを発行してもらいました

交付に際して準備するもの

暗証番号およびパスワードを決める

パスワードを覚えるなんて脳味噌の無駄遣い

個人番号カードの有効期限

再交付

【追記】パスワード定期変更の起源？

週末スペシャル：「パスワードの定期変更はすべきでない」，他