Scribble at 2023-02-23 20:16:45 Last modified: unmodified

まぁ、こんなもん20年前の俺らでも考えてた理屈なんだけどさ。その当時は、特定の会員だけアクセスできるページとか提供してる会社で１日に100万 PV のサイトをサーバからアプリケーションまで構築・開発して運用してたし、サイトのデザインとかコンテンツの更新すらやってたわけで、やはり認証の仕組みを会員さんに通過してもらうだけで酷く重い（そして攻撃対象になりやすい）サーバとなっていたからだ。

上記のサイトを見る人は多くないと思うので、簡単にアイデアだけ説明すると、静的な HTML ファイルの内容（たとえばブログなら記事として提供するブロック要素）だけ AES-256 (CBC) で暗号化する。そして、それを復号化するための認証情報をハッシュ値としてソース・コードへ直に追加しておく。当たり前だが、正しい認証情報を入力しないと復号化されないため、コンテンツは表示できないのだ。

考え方としてはシンプルだし、サーバ上で隠すべきものがないという利点もある。暗号化のアルゴリズムはもちろんだが、暗号化されたコンテンツやハッシュ値ですら攻撃者に開示してしまっているからだ。これが危険だというなら、タクシーや路上や居酒屋で盗まれた情報セキュリティ技術者のノート・パソコンも、たとえ HDD が暗号化してあり、更に VeraCrypt で暗号化した仮想ドライブにデータが入れてあってパス・フレーズは自分の記憶だけという条件ですら危険だという話になる。

ただ、Hacker News のコメントにあるように、JavaScript の値として扱えるデータの量には限度がある。それから、いちいちテキストを修正するたびに暗号化をやりなおしてアップロードすることになるので、これはまさにコンパイル方式のプログラムをメンテナンスするような作業だ。