マンガ作成アシストツールを作ろう①ログイン仕様

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

最近typescriptをやろうとしたが、あまりのライブラリ層の薄さに辛さが募ったのでバベルES2017で頑張ることにする。IE以外は対応しているようなので

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

とりあえず、今はYAMLでやってみましょうかね。aceでも使って。 yaml？なにそれ美味しいの？って人は無視します。あとねブラウザというプラットフォームが古い人も。夢のES2017準拠でガンガン行きましょう。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ダメだった・・・・まだBabelがまともに対応してなかった・・・

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ツイートでデータを集めて自力れデュースしてその際にYAMLバリデーションかけて それが漫画のページになる感じか。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

タグクラウドには自身の能力が試されているな。名前空間を適切に付けるという能力が。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

まずはサーバレスでというか素のhtmlとjsだけでやるかのう。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

やはりマップレデュースなんだと思う。 まず有象無象のアイデアをイメージを含め一旦ツイートとして書き出す。 それを時系列に繋げる。 そして横に時系列のツリーを置いてYAMLで清書する。 YAMLにする時にページ割が可能になるので、その状態でネームを作成する。 多段階だがこれが多分楽

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

このメディアコンバージョンで一番の苦痛は結局のところ変換元と変換先を同時に見れない、これに尽きる。別マシンだったり、別アプリだったり。そして何より変換作業開始時に変換元情報が散逸している、収集作業から開始な～というジャッジメント浪費作業が待っているのが辛い。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

メディアコンバージョン対象のデータが散逸しない、一箇所にアクセスしたら手に入る。その上で、ネームまでたどり着ける。で、マルチデバイスに対応していて、データの所在がユーザのデバイス上、ネットワークにストレージを用意しなくて良いまでを目指したい。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

とりあえず、クライアントサイドでの暗号化を考えたのでﾂｲｰﾖしておくか。 今回のプロダクトの要件として、完全にオフラインで作動する。 ユーザは開発者ツールでブラウザ内に蓄えられた情報を見ることが出来る。 しかし、ログインしたユーザ以外にデータを見せてはならない。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ログインとは何か ここでは、ログイン画面でユーザIDとパスワードを入れ画面遷移することを指す。 次にアクティベーションチェックを行う。単純に利用規約に同意のチェックボックスをつけて次の画面に遷移するだけである。この作業が終わらない限り、利用規約が表示され続ける。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

アクティベートが終わった次点で、次の情報が手に入る。 ユーザID、パスワード、初回登録時間、アクティベート時間、UA、ドメイン。 ブラウザ側で使用可能な永続的ストレージは、LocalStrage、IndexedDBである。サーバーがない場合にキャッシュは使用可能なのだろうか？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

まあいい。問題はブラウザには開発者ツールというものがあるし、ブックマークレットなりで頑張ればそこに存在するとわかっているLocalStrorageやIndexedDBの中身を見るのは容易いということである。格納場所がわかっている状況でどうやれば第三者に解読されないようにできるのか

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

メモリの中を開発者ツールのデバッグで見てしまったよ系の頑張ったね君は今回のところ対象外とする。ログイン状態であればお金を100万円も使えばすぐにメモリの中身は取り出せてしまうのが現実である。今回は流出状態がログイン状態ではないという状況で考えてみたい。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ログイン状態が正しいか、というのはシステム側が把握しているユーザIDとパスワードを入力値と一致させれば良い。ストレージの中身がわかっている時は平文で保存すると当然ユーザIDとパスワードは漏洩する。入手した情報でなり変わってログインが出来る。したがって平文はありえない。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

じゃあ暗号化しました。暗号化されたトークンがあるとします。 暗号化は復号化が可能なため、破られる可能性が高い。というのも所詮人間が入力するユーザIDとパスワードである。１個が対象ならこれも１００万円ぐらいクラウドに使えばブルートフォースアタックで突破されるだろう。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

じゃあどうするんだよで、こう１０００万円払えます？ニッコリぐらいの障壁があればいい。 ハッシュもよほどシードがわかりやすくなければ衝突条件を引き出すのはなかなか難しいだろう。 ID+パスワード+UA+ドメイン+塩(初回ログイン時間)の1000x回ストレッチ→ハッシュ①を生成する。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ハッシュ①をそのまま保存して暗号化キーに使用するとキーが漏れていることになるので、これを別の手順で作成した固定塩のハッシュ②でAES暗号化処置をして保存する。 またアクティベートキーを発行する。アクティベートを行った時間を元にハッシュ③を生成する。ハッシュ②で暗号化し保存する

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

ハッシュ生成ソースが公開状態にあるのでハッシュの推測は厄介だが暗号化のキーが人間の入力値であるという解読のやる気が上がる状況は回避できる。 十分鍵が長くなったところでストレッチの途中に途中経過のハッシュ同士で暗号化を行えば良いのだろうか。ストレッチ→暗号化→再ストレッチのように。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

初回ログイン時間考慮のハッシュ① 固定塩のハッシュ② アクティベート時間考慮のハッシュ③ 実際は①と③を足したハッシュをオンメモリでキーとして持って暗号化、復号化に使用する。前回保存したユーザ名を解読できたらおめでと！、君は正式なユーザだ歓迎する！となるはずであると。