パスワードはハッシュ化されていた、それでも変更が必要 — skyticket約1,464万件流出と3つの入口
この記事は時点のニュースです。現在の提供状況とは異なる場合があります。誤りの訂正は随時行います。
ペンギン先生、旅行予約の「skyticket」で1,464万件も個人情報が流出したって聞いたよ。そんなに大きな攻撃を一発で受けちゃったの?
件数がいちばん多い1件目では、何が出てしまったのかな?
あれ、でもクレジットカードの番号は出てないって聞いたよ。守りが強かったのかな?
理由はもっと単純で、「持っていなかった」からなんだ。お知らせには「クレジットカード番号とパスポートの画像を保存しておらず」と書かれていて、決済情報は決済代行会社が管理していると説明されている。パスポート番号についても「流出していないことを確認しております」と記載されているよ。ここは覚えておく価値があるところで、保存していない情報は、入られても持ち出されない。守りを厚くするのと同じくらい、そもそも手元に残さないという設計が効くんだ。ただし氏名は「パスポート表記を含む」とされているから、パスポート関連がまるごと無関係というわけではないよ。
そこは半分当たりだよ。OWASPのPassword Storage Cheat Sheetは「hashing is a one-way function (i.e., it is impossible to "decrypt" a hash and obtain the original plaintext value)」と書いていて、ハッシュから元のパスワードを復号して取り出すことはできない。でも攻撃側には別の手があって、同じ資料は「Lists of passwords obtained from other compromised sites」や「Brute force (trying every possible candidate)」で候補を大量に試す手法を挙げている。候補を自分の手元で片っぱしからハッシュ化して、流出した値と一致するものを探すんだ。復号ではなく、答え合わせを繰り返すイメージだね。
片っぱしから試されたら、どんなパスワードでも最後は当たっちゃわない?
だから「1回の計算をわざと重くする」仕組みが用意されているんだ。OWASPはwork factorを「the number of iterations of the hashing algorithm that are performed for each password」と説明して、これが「reduces the speed and/or increases the cost for which an attacker can attempt to crack the password hash」と書いている。さらにsaltは利用者ごとに違う文字列を混ぜるもので、「an attacker has to crack hashes one at a time using the respective salt rather than calculating a hash once」と説明されている。逆にSHA-256のような速いハッシュは、「not suitable for password storage because they allow attackers to perform large numbers of guesses quickly」とはっきり書かれているよ。
つまり、ちゃんとしたやり方なら安全ってこと? 今回はどうなんだろう。
OWASPの結論は条件つきなんだ。「Strong passwords stored with modern hashing algorithms and using hashing best practices should be effectively impossible for an attacker to crack.」――強いパスワードで、最新のアルゴリズムで、適切な設定なら、という3つの前提が付いている。そして今回のお知らせには「ハッシュ化した状態」とあるだけで、どのアルゴリズムをどんな設定で使ったかは書かれていない。利用者の側からは確かめようがないから、弱い前提で動くほうが安全だよ。NIST SP 800-63Bも「verifiers SHALL force a change if there is evidence that the authenticator has been compromised.」として、侵害の証拠がある場合は変更させることを求めている。お知らせでも「skyticketの会員様は、パスワードの変更をお願いいたします。」と依頼されているね。
skyticketのパスワードを変えれば、それで終わりかな?
いちばん忘れやすいのがその先なんだ。お知らせには「他のサービスで同じパスワードをお使いの場合は、そちらも変更してください。」とも書かれている。流出した組み合わせは、他のサイトのログインを試す材料として再利用されるからだよ。NIST SP 800-63Bが3.1.1.2で、パスワードの設定・変更時に照合すべきブロックリストの対象として「Passwords obtained from previous breach corpuses」――過去の流出データから得られたパスワード――を明記しているのは、まさにこの再利用を前提にしているからなんだ。だから「skyticketはもう使わないから大丈夫」ではなくて、同じパスワードを使い回していた他のサービス側が危ない、という順番で考えてね。
2件目に出てきた口座情報って、どのくらい心配したらいいのかな?
2件目で挙がっているのは「返金先の口座情報(金融機関名・支店名・口座種別・口座番号・口座名義)」で、対象は17,780件。パスワードと違って、口座番号は「変えて終わり」にしにくい情報だよね。お知らせでは「口座に身に覚えのない入出金があった場合は、お取引の金融機関にご相談ください。」と案内されていて、あわせて「当社や金融機関などを装った不審なメール・SMS・電話・郵便物にご注意ください。」とも書かれている。流出した情報を使って本物らしく装った連絡が来る可能性があるからだね。それと、全体としては「本件で流出した情報が悪用されたことによる二次被害は確認されておりません」としながら、2件目については9月9日に会員1名のアカウントへの不正ログインが確認されたとも書かれている。ゼロではないんだ。
3件目のバス予約は、ハッキングっていう感じがしないね。何が起きたの?
ところで、こういうとき会社からメールが来るのは義務なの? それとも親切でやってくれているのかな。
法律上の仕組みがあるよ。個人情報保護委員会の案内では、報告・通知の対象になるケースとして、要配慮個人情報、財産的被害のおそれがあるもの、不正の目的によるおそれがある行為によるもの、そして本人の数が1,000人を超えるもの、の4類型が挙げられている。今回は不正アクセスによるものだから、3つめの「不正の目的によるおそれがある行為による漏えい等」にまず当たるね。4つめの人数要件については、公表されているのが「約1,464万件」という件数で、人数そのものではないから、ここは件数と人数を分けて読んでおこう。期限も決まっていて、速報は発覚日から3〜5日以内、確報は30日以内、不正の目的によるおそれがある場合の確報は60日以内。実際にお知らせにも「個人情報保護委員会に報告しております。」と書かれているよ。だから「公表が早かったから軽い事案」ではないし、逆に説明が段階的になるのも制度上は想定されていること。そして大事なのは、通知を装った偽メールも来やすいということ。お知らせで注意が呼びかけられているとおり、メールのリンクから入らずに、ブックマークや検索で公式サイトを自分で開いてから確認するのが安全だよ。
出典・確認した情報
- 当社サーバへの不正アクセスによる個人情報流出に関するお知らせ(株式会社アドベンチャー/skyticket)
発表日: 2026-10-09 / 確認日: 2026-10-11
- 公表日は2026/10/09として掲載されている
- 1件目はサーバーへの不正アクセスで、発生は2026年10月2日〜10月4日、発覚は2026年10月5日、対象は約1,464万件
- 1件目の流出情報として「氏名(パスポート表記を含む)、生年月日、メールアドレス、電話番号、郵便番号・住所」「お振込み時のご依頼人名義、会員様のログインパスワード(ハッシュ化した状態のもの)」を列挙し、パスワードを含むのは約413万件
- 1件目の経緯として「skyticketの一部の管理機能を不正に操作され、そこから当社の他のサーバーおよびクラウド上に保管していたデータに不正にアクセスされたもの」と記載
- 「パスポート番号は流出していないことを確認しております」と記載
- 「クレジットカード番号とパスポートの画像を保存しておらず」、決済情報は決済代行会社が管理していると記載
- 2件目は業務管理システムへの不正アクセスで、発生は2026年9月20日、発覚は2026年9月28日、対象は17,780件
- 2件目の流出情報に「返金先の口座情報(金融機関名・支店名・口座種別・口座番号・口座名義)」が含まれる
- 「2026年9月9日に、会員様1名のアカウントへの不正ログインを確認」と記載
- 3件目はバス予約で、発生は2026年8月3日〜10月1日、発覚は2026年10月1日、対象は予約約12,000件
- 3件目の原因は「バスの予約完了ページがログインをしなくても表示できる状態」で、「第三者に機械的に閲覧されたもの」と記載
- 3件目の流出情報は「ご予約者様の氏名(カナ)、年齢、性別、生年月日(ご登録がある場合)、メールアドレス、電話番号、会員ID、ご予約に使われた端末の種類、お支払方法・金額、ご予約日時、ご乗車便の情報(日時・乗降地・運行会社・便名・運行会社の予約番号)、ご同行者様の氏名・年齢・性別」
- 「本件で流出した情報が悪用されたことによる二次被害は確認されておりません」と記載(上記の不正ログイン1件を除く)
- 「skyticketの会員様は、パスワードの変更をお願いいたします。」「他のサービスで同じパスワードをお使いの場合は、そちらも変更してください。」と依頼
- 「マイページの予約履歴と、クレジットカードのご利用明細をご確認ください。」「当社や金融機関などを装った不審なメール・SMS・電話・郵便物にご注意ください。」「口座に身に覚えのない入出金があった場合は、お取引の金融機関にご相談ください。」と案内
- 「2026年10月7日18時ごろをもって、保存済みクレジットカードによるお支払いと、カード情報の保存機能を停止いたしました。」と記載
- 「個人情報保護委員会に報告しております。」と記載
- ハッシュ化に使用したアルゴリズムの記載はなく、「ハッシュ化した状態」という表現のみ
- Password Storage Cheat Sheet(OWASP Cheat Sheet Series)
発表日: 2026-10-11 / 確認日: 2026-10-11
- 「Because hashing is a one-way function (i.e., it is impossible to "decrypt" a hash and obtain the original plaintext value), it is the most appropriate approach for password validation.」とあり、ハッシュは一方向関数で復号できないと説明
- 攻撃者は候補を大量に試す手法として「Lists of passwords obtained from other compromised sites」「Brute force (trying every possible candidate)」「Dictionaries or wordlists of common passwords」を挙げている
- 「Strong passwords stored with modern hashing algorithms and using hashing best practices should be effectively impossible for an attacker to crack.」とあり、強いパスワードと最新のアルゴリズム・適切な設定という条件つきの記述になっている
- work factorは「the number of iterations of the hashing algorithm that are performed for each password」で、「reduces the speed and/or increases the cost for which an attacker can attempt to crack the password hash」と説明
- saltは「a unique, randomly generated string that is added to each password as part of the hashing process」で、「an attacker has to crack hashes one at a time using the respective salt rather than calculating a hash once」と説明
- 推奨設定としてArgon2idは「a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism」、bcryptは「a work factor of 10 or more and with a password limit of 72 bytes」を挙げている
- 「Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly.」と記載
- NIST SP 800-63B Digital Identity Guidelines(Authentication and Authenticator Management)
発表日: 2026-10-11 / 確認日: 2026-10-11
- 3.1.1.2に「When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.」と記載
- ブロックリストの対象に「Passwords obtained from previous breach corpuses」「Dictionary words」「Context-specific words, such as the name of the service, the username, and derivatives thereof」が含まれる
- 「Passwords SHALL be salted and hashed using a suitable password hashing scheme.」「The salt SHALL be at least 32 bits in length」と記載
- 「The chosen cost factor SHOULD be as high as practical without negatively impacting verifier performance」と記載
- 「Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.」と記載
- 個人データの漏えい等が発生した場合の対応(個人情報保護委員会)
発表日: 2026-10-11 / 確認日: 2026-10-11
- 報告・通知の対象となるケースとして、要配慮個人情報の漏えい等、財産的被害のおそれがある個人データの漏えい等、不正の目的によるおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等の4類型を挙げている
- 財産的被害のおそれがある例として「ECサイトからクレジットカード番号を含む個人データが漏えいした場合」を挙げている
- 不正の目的による行為の例に不正アクセス、ランサムウェア、盗難、従業者による不正な持ち出しが含まれる
- 報告期限は速報が発覚日から3〜5日以内、確報が発覚日から30日以内で、不正の目的によるおそれがある場合の確報は60日以内と記載
- 行政機関等については本人の数が100人を超える場合が対象と記載