この動画のパスワード解析時間を疑い、
パスワードの総当たりを実際にして、
解かれる時間について考えてみました。
環境
WSL version: 2.4.13.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.19045.5737
Bun 1.2.9
攻撃するサーバー
Bun+Hono+TSで自作します。
攻撃者の環境
localhost:3000で攻撃者はアクセスできます。つまりローカルから攻撃ということです。
攻撃方法
数字のみのパスワード長は固定で、Bun+TypeScript+fetchで
- パスワードに使う文字数分の通信を同時にし、それぞれの通信では最後の文字を変えたパスワードでトライする
- それらの通信全ての返答を待つ
- 返答を確認し、パスワードが全部違うならパスワードを変えて1からトライ
という感じです。
では結果の表がこちら。
| アルゴリズム | パスワード | 結果 |
|---|---|---|
Bun.password(argon2id) |
45 | 3.0秒 |
Bun.password(bcrypt) |
45 | 1.2秒 |
== |
4545 | 2.4秒 |
| SHA256 | 4545 | 2.1秒 |
| SHA512 | 4545 | 1.9秒 |
Bun.hash |
4545 | 2.0秒 |
結果、パスワードのハッシュアルゴリズムによっては短くても時間がかかるということが分かりました。
最後にパスワードG@m5で実験
英数字・記号4文字で実験します。
アルゴリズムは==です。
～～～～～
数十分とかそんぐらい動かしましたが終わりませんでした。TNTSuperManはせっかちなのでここで終わりました。これをやった感想は、全く4秒じゃない！です。
なぜ結果が乖離したのかの考察
BunなどのJavaScriptランタイムはシングルスレッド
BunなどのjsランタイムはPromiseなどはあれどシングルスレッドです。
なので通信のオーバーヘッドがある総当たり処理を単一CPUで計算ってなると遅くなるのかなと。
このパソコンが弱い
WSLのオーバーヘッドに加えCPUもそんなに良くないので普通にそれが直撃したのかなと。
パスワードハッシュ(argon等)が遅すぎた
bcryptやargonのようなパスワードハッシュは
意図的に速度が遅くなるよう設計されているので、
このような総当たりの速度が非常に落ち、攻撃が困難になるのかなと感じました。
感想
パスワードハッシュはいかに総当たり攻撃に最適か・Honoの速さを体感できました。
今回作ったプログラム