アカウント名:
パスワード:
確かにシステムはへぼい、へぼいが、その多くが* ID作ってSMSなりメールで認証してパスワード作ってログインして…とかできる人が対象なシステムではない* 接種番号のフォーマットもわからない、ってか決まっていないことからある意味「仕方ないへぼさ」だろう
個別の連絡も行くんだし、大規模接種会場は認証入りのまともなつくりでもよかった気もするけど、本気で実在の個人と紐づいたような個人認証しようと思うと証明書を撮影してアップロードしてくださいとか対象層を考えるとかなり無理あるつくりになっちゃうし
それならもういっそぶっ通し、ってのはありなんかなーと思い直した
同一の接種券番号で、異なる市町村番号が登録できません [twitter.com] という疑惑が出ている。これが本当だったらまずい。仕方ないへぼさと言い訳できないレベル。抗議どころか惨事を引き起こす前にチェックする機会を作ってくれてありがとうと礼を言わなきゃいけないんじゃないのか。
ホントかどうか知らないが、こういう疑惑が出るのもやむなしかね分かんないんだもんね作りが
もうなんか設計書とテスト用の番号等一式公開して叩いてもらうってのがええんかも?きっと死ぬほど叩いてくれるだろう
公開前にやって公開時にDBリセットすれば良いかDBの違うテストサイト公開してもいいね
クエリ書き換えとか本番環境では流石に躊躇われる検査までできそうだわざと穴残してますとか仕込むとやる気上がるかも?やりすぎ?
愉快犯だけが致命的な穴見つけたりすると問題だけど、ペネトレーションの会社とかが広告でやってくれるかもしれんし…
どうです今からでも防衛省さん
とりあえず以下のような話と理解した。本当にそうなっているかどうかは未確認（ヘタレ）。
疑惑があるのは、最初に表示されるページで市町村番号、接種券番号、生年月日を入力して認証ボタンを押すところ。市町村番号＋接種券番号がID、生年月日がパスワードになっていると考えればよい。認証ボタンを押すと、IDが初めて入力されたもののときは、対応するパスワード（生年月日）が登録され、登録済みのIDのときは対応するパスワードが一致しない場合ははじかれる（認証ボタンを押すと登録されてしまうという仕様もいかがなものかという気はするが）。
疑惑の内容は、IDが市
> 違う市町村番号＋同じ接種券番号＋同じ生年月日 → 入れる （結果は正しい）
接種券番号は市町村ごとに一意だから、異なる市町村で同じ接種券番号を持つ別人がいるかもしれず、入れちゃうとまずいんじゃないの（もっとも、生年月日まで一致するケースはまれだとは思うけど）。例のバーコード読み取り問題も、それがあるから接種券番号のバーコードは信用せず、市町村コードを含んだ別のIDを振ってOCRで読み取ろうって発想から来ているわけで。
「違う市町村番号＋同じ接種券番号＋同じ生年月日」のケースは、その市町村番号＋接種券番号のペアが未登録だということを前提としている。期待する動作は、新規の人が来たのだから入力された生年月日をパスワードとして登録して入れるというものになる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
そんなもんでしょ (スコア:5, すばらしい洞察)
確かにシステムはへぼい、へぼいが、その多くが
* ID作ってSMSなりメールで認証してパスワード作ってログインして…とかできる人が対象なシステムではない
* 接種番号のフォーマットもわからない、ってか決まっていない
ことからある意味「仕方ないへぼさ」だろう
個別の連絡も行くんだし、
大規模接種会場は認証入りのまともなつくりでもよかった気もするけど、
本気で実在の個人と紐づいたような個人認証しようと思うと
証明書を撮影してアップロードしてくださいとか対象層を考えるとかなり無理あるつくりになっちゃうし
それならもういっそぶっ通し、ってのはありなんかなーと思い直した
Re: (スコア:0)
同一の接種券番号で、異なる市町村番号が登録できません [twitter.com] という疑惑が出ている。これが本当だったらまずい。仕方ないへぼさと言い訳できないレベル。抗議どころか惨事を引き起こす前にチェックする機会を作ってくれてありがとうと礼を言わなきゃいけないんじゃないのか。
Re:そんなもんでしょ (スコア:2)
ホントかどうか知らないが、
こういう疑惑が出るのもやむなしかね
分かんないんだもんね作りが
もうなんか設計書とテスト用の番号等一式公開して叩いてもらうってのがええんかも?
きっと死ぬほど叩いてくれるだろう
公開前にやって公開時にDBリセットすれば良いか
DBの違うテストサイト公開してもいいね
クエリ書き換えとか本番環境では流石に躊躇われる検査までできそうだ
わざと穴残してますとか仕込むとやる気上がるかも?やりすぎ?
愉快犯だけが致命的な穴見つけたりすると問題だけど、
ペネトレーションの会社とかが広告でやってくれるかもしれんし…
どうです今からでも防衛省さん
Re: (スコア:0)
とりあえず以下のような話と理解した。本当にそうなっているかどうかは未確認（ヘタレ）。
疑惑があるのは、最初に表示されるページで市町村番号、接種券番号、生年月日を入力して認証ボタンを押すところ。市町村番号＋接種券番号がID、生年月日がパスワードになっていると考えればよい。認証ボタンを押すと、IDが初めて入力されたもののときは、対応するパスワード（生年月日）が登録され、登録済みのIDのときは対応するパスワードが一致しない場合ははじかれる（認証ボタンを押すと登録されてしまうという仕様もいかがなものかという気はするが）。
疑惑の内容は、IDが市
Re: (スコア:0)
> 違う市町村番号＋同じ接種券番号＋同じ生年月日 → 入れる （結果は正しい）
接種券番号は市町村ごとに一意だから、異なる市町村で同じ接種券番号を持つ別人がいるかもしれず、入れちゃうとまずいんじゃないの（もっとも、生年月日まで一致するケースはまれだとは思うけど）。
例のバーコード読み取り問題も、それがあるから接種券番号のバーコードは信用せず、市町村コードを含んだ別のIDを振ってOCRで読み取ろうって発想から来ているわけで。
Re: (スコア:0)
「違う市町村番号＋同じ接種券番号＋同じ生年月日」のケースは、その市町村番号＋接種券番号のペアが未登録だということを前提としている。期待する動作は、新規の人が来たのだから入力された生年月日をパスワードとして登録して入れるというものになる。