落下箱
密林さんの片隅にて
（続き）
- www. の認証は touch, jar, lid のCookies 3個。他はゴミ
- touch: 32bit, 実質ただの User ID
- jar: 長い。が、再認証で不変。塩してないっぽい
- lid: 長い。再認証で変化はするが寿命設定等は不明
- 実質動作トリガの認証は touch とPOST中の t だけ。他には何もいらない
- t: 40bit, 再認証で不変, パスワード変更でも不変, IP紐付けなし, 推定寿命なし
・・・これは本当にこれでいいのかな・・・。ええと何が言いたいかというと、要するに dl-web. が touch と t だけで動作するので、例えば任意のファイルの上書きに必要な認証情報は計72bitのみであり、しかも状況からするとこのうちの何bitかは既知である公算が大きい。恐ろしいことに一切塩もされていなければ寿命すら設定されていないらしいので、www. の長大な認証は全部すっ飛ばすことが可能であってパスワード自体は不要である。むしろどちらかというとこれら計72bitの方が事実上のマスターキーであって、これを特定されたならばパスワードを変更しようが何をしようがrevokeできないので、有り体に言えば表向きのパスワードの方が立場は弱いといえる。
ちなみにファイル内容の取得、すなわち dl-web. からのGETに必要なのは touch と正確なパス名と32bitの w だけであり、鍵長だけで言えばこちらの方がさらに短い。とはいえ w の寿命はファイル自体の寿命で制限されるのでこの点ではまだマシ・・・かと思いきや、同じパス名でファイルを作り直すと同じ w になる罠。ちょ。正しくは w の寿命はファイル名の寿命に一致する、でした。
AES-256 とかのSSLで護送したマスターキーが、どう考えても72bit以下しかも寿命無制限ってのは、何かが途轍もなく間違っているような気がする、のだけど・・・。だってワンタイムのテンポラリキーの方がマスターキーより長いんだよ? 豚の貯金箱の鍵だけを耐火金庫にしまい込むのと同じだよ??
でまあ何の話だったかというとコレ。・・・今更とか言うな!
要するにザルっぽい認証のおかげで自動アップロード等のスクリプトを簡単に仕込むことができるので、謎クライアントは無視して単なるwebホストとして使うのが良いように思えました、という程度のネタ。なおPhotos領域は .png を透過させてくれないので今回の目的には使えない。
