「平文保存ではない可能性もある」って、一方通行のハッシュ値ではなく復号可能な形で保存してたら根本的なヤバさは変わらん……
“※平文保存ではない可能性もある”
20桁のパスワードを15桁に切り詰めればログインできるとか平文保存か可逆暗号確定だろ。金融機関のシステムとしてセキュリティのガバガバさ加減がホラーすぎる
iDecoのページにログイン…ってどこの証券会社？それがわからんと対策のしようがない。 / クレジットカードでいうところの「Visaで払った」くらい、責任の所在がよくわからないやつ。
問い合わせをして「パスワードは〇〇です」と返って来るまでは、15文字にカットして登録されているのか分からないやつ。後から仕様変更ならとても危ない
削るという発想が・・・
従来は先頭15文字でハッシュ値を計算していたのが、全文で計算するように変更された可能性が有り、その場合はセキュリティ的な問題は無い。AmazonかGoogleがこのパターンでやらかした記憶
15桁に制限、20桁では弾かれる、15桁に削ったらOK。15桁上限なのに一体何文字まで受け付けているのか。平文保存が疑われる開発チームなら無制限でもおかしくない。入力画面自体が脆弱性かも。
パスワードは記号とか数字を混ぜなくてもいいからとにかく長くすべしというのが今の考えじゃなかった？
残念ながら、パスワードが平文で保存されてるシステムなんてザラにあるのが現実。長さや文字に過剰な制限がある場合、恐らく平文保存されてる。自衛しましょう。
透過的暗号化で流出対策している可能性もあるが、まあ、SQL打てる立場の人には見えてしまう状態であった事はほぼ間違いないか。
元々15字より先は切り捨てて扱っていたのに、切り捨てなくなったとか？
某大手ファション通販みたいにフォームでトリミングしたりしなかったり挙動が一致しないから、ログインにつまずくサービスもあるから。挙動としては同じで、登録時のパスワードを削るとログインできる。
可能性として無理やり考えたところ、5文字ずつ4つのハッシュ（5x4=20）で突合してて、4つ目の検証をやめて、16文字以上の入力を一律エラーとしたんなら辻褄は合う。逆にいうとハッシュ化してた可能性はめちゃくちゃ低い
「パスワードの問い合わせにはパスワードを返答する」という要件があって、開発側はセキュリティ上問題があることを説明するんだけど理解してもらえなくて仕方なく平文保存になる、というのがかつてはありがちだった
20桁の文字列を暗号化しているものをVARCHAR(128)ぐらいで保存しているはずなのに、それを複合化したものから15字分入れろって意味なくない？
それで通るってどういう運用？
大丈夫、平文じゃなくて、シャーロックホームズに出てくる踊る人形だから、ダイジョブ
=平文保存かぁ～やってんなぁ
googleやappleだってパスワードマネージャーで復号可能な保存しているんだからうちだって平気やろーの精神。
途中のリプにもあるけど、元々先頭15字しか見てなかったんやろ。昔のハッシュ関数ライブラリは先頭n字しか使わなくて残りをサイレントに捨てる仕様のやつが良くあった／補足→https://anond.hatelabo.jp/20260703005911
システム改定まで平文で保存してて、システム改定時に15桁で削ってハッシュ化したとかはあり得る。改定までは平文保存でも今はどうなのかはわからんけどな。
15文字の入力制御がある時に、15文字以上「入力したつもり」で登録していて、なにかの改修で入力制御が効かなくなり、15文字以上「入力できるようになった」とか /ブラウザ変えるとログインできない時に似た経験した
平文で保存してない可能性を無理矢理考えると、以前は内部的に15文字にカットしてから照合していたが、それだと一致するパターンがいくつもあることになるので、15文字以上は無条件ではじくように変更した。とかか。
まず15桁のハッシュを追加して、1年後とかに長い方のハッシュを消すんだよ / https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#upgrading-legacy-hashes
うわぁ
内部で15文字でちょん切ってハッシュ化の可能性もゼロではないが…
三井住友カードもかつて16桁から8桁に変更されたことがあったな
わざわざ改修するからには今更15桁に制限する必要が出てきたわけだが何があったんだよ
先頭15文字でハッシュしてたなら20文字入力してもログインてきるのでは
ブコメで挙げられている5文字ずつ細切れにハッシュ化する手法だったとしても、それだけ短いと簡単にレインボーテーブルが作れてしまうからどちらにしてもヤバい
ユーザーログインで人力されるパスワード文字列を使って別DBにハッシュを再構築する移行プラクティスは存在する。"cognito lambda段階的移行"で検索。
そういや昔suicaのサイトでも同じことあったな。いや、あれは登録側が切ってただけか？
15桁までのパスワード設定なのに16文字以上入力出来て入力できるけど無視されていたのだろう。で、6月にMFA対応などと合わせてパスワードの要件を6桁～15桁から10桁～64桁に見直している証券会社があるのでそこかなー
「ハッシュ値で暗号化していれば、1文字でも削れば全く違うハッシュ値に...。」怖いな。コレ。個人年金なんだろ。今後も漏洩恐怖に晒されるのか。
だがちょっとまってほしい。本当にまって/「もともと15文字に切り捨ててハッシュ作ってたバグかなんかを引っ込みつかなくなって仕様にした」あたりが一番穏当か…？
投資なんか、破産者増やしただけっぽいからやらなきゃよかったね。
そもそもパスワードを15桁までに変える理由が分からなくて怖い。長くするなら分かるけど、短くするのは聞いたことない。
maxlength のせいです。しらんけど
そもそも新システム側でパスワードの桁数減らす理由がわからん
先月SBIのiDeCoでパスワードを変えていないのに、「パスワードが違います」でログインできずに変更したけど
ヤバすぎるだろ、2010年でさえ許されてなかったぞ…金融サイトで何やってんの公表しろよどこの業者だよ
昔のUNIXは8文字以上切り捨てだったっけ?
短いパスワード廃止された結果、パスワードリセットするまでログイン出来なくなってたアカウントが前にあったが、15文字までに短くするのは意味が分からない
id:cadadie のやり方は一瞬なるほどと思ったが、5文字のハッシュと分かっていれば一瞬で破れるので、それを何個か用意するのは平文保存と変わらないな。
私もJIS&Tで同じ話があった。初ログイン時に長いパスワードに変更して完了。次回、パスワード相違でログインできず。おそらく元のパスワードを勝手に短くして保存されたのだと思う。
いずれにしろ嫌すぎる。
id:cardmics ideccoのサイトって、JIS&Tがやってる本体のサイトでしょ。イデコの利回りとかは本体でないとわからない証券会社もあるはず、今は401kにしたから証券会社によるとは思うけど。
何のサービスだったか忘れたけど、パスワード変更で新旧のパスワード入れる画面で旧パスワードが合わず、パスワードを8桁で切り捨ててることに気づいた。ログイン時は切り捨てして、パスワード変更ではそれをやって
本当のところはどうなんだろう…？
一定期間で、パスワードマネージャーの前パスワードチェックし直すのだけど、いまだに「ここ大丈夫なの？」ってとこ多い。そらパスも独自のものにするし、メアドもエイリアスかけないとまずいと思うわ。
パスワード平文保存説あって草
ひどい
もともと15文字分しかハッシュ化していなかったとしたらパスワードの先頭15文字だけあってれば間違ったパスワードでもログインできる不具合が存在していたということで、それはそれで怖くない？
入札必須でシステム移行が発生しうる公共調達の場合、移行に備えパスワードを平文で持つことは有りうるんだけど、それを勝手に切り詰めるのが一番ダメ。そしてやっぱHashで持とうよ。どうせ1点モノだし。
まあもうちょっと説明した方がいいと思うよ。
JSで鯖に送る前に切ってた可能性が微レ存(震え声)
パスワードを可逆暗号で保持のblueboy先生を思い出しちゃった。でも、これは先頭15桁までしか使ってなかったんだろうな。
郵便貯金ホームサービス（ゆうちょダイレクトの前身）なんかパスワードが手書きで送られてきた
iDeCoのページにログインできず、コールセンターに連絡したら「システム改定でパスワードを15桁までにしたので、15桁まで削ってログインして」と言われた→「意味が分かるとめちゃ怖い話では？」のツッコミが相次ぐ
「平文保存ではない可能性もある」って、一方通行のハッシュ値ではなく復号可能な形で保存してたら根本的なヤバさは変わらん……
“※平文保存ではない可能性もある”
20桁のパスワードを15桁に切り詰めればログインできるとか平文保存か可逆暗号確定だろ。金融機関のシステムとしてセキュリティのガバガバさ加減がホラーすぎる
iDecoのページにログイン…ってどこの証券会社？それがわからんと対策のしようがない。 / クレジットカードでいうところの「Visaで払った」くらい、責任の所在がよくわからないやつ。
問い合わせをして「パスワードは〇〇です」と返って来るまでは、15文字にカットして登録されているのか分からないやつ。後から仕様変更ならとても危ない
削るという発想が・・・
従来は先頭15文字でハッシュ値を計算していたのが、全文で計算するように変更された可能性が有り、その場合はセキュリティ的な問題は無い。AmazonかGoogleがこのパターンでやらかした記憶
15桁に制限、20桁では弾かれる、15桁に削ったらOK。15桁上限なのに一体何文字まで受け付けているのか。平文保存が疑われる開発チームなら無制限でもおかしくない。入力画面自体が脆弱性かも。
パスワードは記号とか数字を混ぜなくてもいいからとにかく長くすべしというのが今の考えじゃなかった？
残念ながら、パスワードが平文で保存されてるシステムなんてザラにあるのが現実。長さや文字に過剰な制限がある場合、恐らく平文保存されてる。自衛しましょう。
透過的暗号化で流出対策している可能性もあるが、まあ、SQL打てる立場の人には見えてしまう状態であった事はほぼ間違いないか。
元々15字より先は切り捨てて扱っていたのに、切り捨てなくなったとか？
某大手ファション通販みたいにフォームでトリミングしたりしなかったり挙動が一致しないから、ログインにつまずくサービスもあるから。挙動としては同じで、登録時のパスワードを削るとログインできる。
可能性として無理やり考えたところ、5文字ずつ4つのハッシュ（5x4=20）で突合してて、4つ目の検証をやめて、16文字以上の入力を一律エラーとしたんなら辻褄は合う。逆にいうとハッシュ化してた可能性はめちゃくちゃ低い
「パスワードの問い合わせにはパスワードを返答する」という要件があって、開発側はセキュリティ上問題があることを説明するんだけど理解してもらえなくて仕方なく平文保存になる、というのがかつてはありがちだった
20桁の文字列を暗号化しているものをVARCHAR(128)ぐらいで保存しているはずなのに、それを複合化したものから15字分入れろって意味なくない？
それで通るってどういう運用？
大丈夫、平文じゃなくて、シャーロックホームズに出てくる踊る人形だから、ダイジョブ
=平文保存かぁ～やってんなぁ
googleやappleだってパスワードマネージャーで復号可能な保存しているんだからうちだって平気やろーの精神。
途中のリプにもあるけど、元々先頭15字しか見てなかったんやろ。昔のハッシュ関数ライブラリは先頭n字しか使わなくて残りをサイレントに捨てる仕様のやつが良くあった／補足→https://anond.hatelabo.jp/20260703005911
システム改定まで平文で保存してて、システム改定時に15桁で削ってハッシュ化したとかはあり得る。改定までは平文保存でも今はどうなのかはわからんけどな。
15文字の入力制御がある時に、15文字以上「入力したつもり」で登録していて、なにかの改修で入力制御が効かなくなり、15文字以上「入力できるようになった」とか /ブラウザ変えるとログインできない時に似た経験した
平文で保存してない可能性を無理矢理考えると、以前は内部的に15文字にカットしてから照合していたが、それだと一致するパターンがいくつもあることになるので、15文字以上は無条件ではじくように変更した。とかか。
まず15桁のハッシュを追加して、1年後とかに長い方のハッシュを消すんだよ / https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#upgrading-legacy-hashes
うわぁ
内部で15文字でちょん切ってハッシュ化の可能性もゼロではないが…
三井住友カードもかつて16桁から8桁に変更されたことがあったな
わざわざ改修するからには今更15桁に制限する必要が出てきたわけだが何があったんだよ
先頭15文字でハッシュしてたなら20文字入力してもログインてきるのでは
ブコメで挙げられている5文字ずつ細切れにハッシュ化する手法だったとしても、それだけ短いと簡単にレインボーテーブルが作れてしまうからどちらにしてもヤバい
ユーザーログインで人力されるパスワード文字列を使って別DBにハッシュを再構築する移行プラクティスは存在する。"cognito lambda段階的移行"で検索。
そういや昔suicaのサイトでも同じことあったな。いや、あれは登録側が切ってただけか？
15桁までのパスワード設定なのに16文字以上入力出来て入力できるけど無視されていたのだろう。で、6月にMFA対応などと合わせてパスワードの要件を6桁～15桁から10桁～64桁に見直している証券会社があるのでそこかなー
「ハッシュ値で暗号化していれば、1文字でも削れば全く違うハッシュ値に...。」怖いな。コレ。個人年金なんだろ。今後も漏洩恐怖に晒されるのか。
だがちょっとまってほしい。本当にまって/「もともと15文字に切り捨ててハッシュ作ってたバグかなんかを引っ込みつかなくなって仕様にした」あたりが一番穏当か…？
投資なんか、破産者増やしただけっぽいからやらなきゃよかったね。
そもそもパスワードを15桁までに変える理由が分からなくて怖い。長くするなら分かるけど、短くするのは聞いたことない。
maxlength のせいです。しらんけど
そもそも新システム側でパスワードの桁数減らす理由がわからん
先月SBIのiDeCoでパスワードを変えていないのに、「パスワードが違います」でログインできずに変更したけど
ヤバすぎるだろ、2010年でさえ許されてなかったぞ…金融サイトで何やってんの公表しろよどこの業者だよ
昔のUNIXは8文字以上切り捨てだったっけ?
短いパスワード廃止された結果、パスワードリセットするまでログイン出来なくなってたアカウントが前にあったが、15文字までに短くするのは意味が分からない
id:cadadie のやり方は一瞬なるほどと思ったが、5文字のハッシュと分かっていれば一瞬で破れるので、それを何個か用意するのは平文保存と変わらないな。
私もJIS&Tで同じ話があった。初ログイン時に長いパスワードに変更して完了。次回、パスワード相違でログインできず。おそらく元のパスワードを勝手に短くして保存されたのだと思う。
いずれにしろ嫌すぎる。
id:cardmics ideccoのサイトって、JIS&Tがやってる本体のサイトでしょ。イデコの利回りとかは本体でないとわからない証券会社もあるはず、今は401kにしたから証券会社によるとは思うけど。
何のサービスだったか忘れたけど、パスワード変更で新旧のパスワード入れる画面で旧パスワードが合わず、パスワードを8桁で切り捨ててることに気づいた。ログイン時は切り捨てして、パスワード変更ではそれをやって
本当のところはどうなんだろう…？
一定期間で、パスワードマネージャーの前パスワードチェックし直すのだけど、いまだに「ここ大丈夫なの？」ってとこ多い。そらパスも独自のものにするし、メアドもエイリアスかけないとまずいと思うわ。
パスワード平文保存説あって草
ひどい
もともと15文字分しかハッシュ化していなかったとしたらパスワードの先頭15文字だけあってれば間違ったパスワードでもログインできる不具合が存在していたということで、それはそれで怖くない？
入札必須でシステム移行が発生しうる公共調達の場合、移行に備えパスワードを平文で持つことは有りうるんだけど、それを勝手に切り詰めるのが一番ダメ。そしてやっぱHashで持とうよ。どうせ1点モノだし。
まあもうちょっと説明した方がいいと思うよ。
JSで鯖に送る前に切ってた可能性が微レ存(震え声)
パスワードを可逆暗号で保持のblueboy先生を思い出しちゃった。でも、これは先頭15桁までしか使ってなかったんだろうな。
郵便貯金ホームサービス（ゆうちょダイレクトの前身）なんかパスワードが手書きで送られてきた