パスワードに『,』を含めておくと、流出時の被害確率が下がるかもしれない 60
ストーリー by nagazou
日本語パスワードって最近話題にならないな 部門より
日本語パスワードって最近話題にならないな 部門より
マルウェアの情報サイトvx-undergroundがTwitterで、パスワードにはコンマを入れておけば、漏洩した資格情報がCSVにダンプされたときにぶっ壊れるからいいよ、とするツイートをして話題となっている。日本語に訳してツイートした新山祐介さんのツイートのレスには「なるほど。「この行を削除したら動く!」みたいな感じで削除される確率も増えるといった納得できる意見も出ている。このほかにも、カンマだけ入れるより「 ,"'--\\\n 」くらい入れるともうちょい防御力上がるのではといったコメントもついている。もっともこの手の文字はパスワードには使えない事例も多いので実用性があるかは議論の余地がありそうだ(vx-underground、新山祐介さんのツイート、Togetter)。
感想 (スコア:2, おもしろおかしい)
「こんまかいな」
いやがらせキーワード (スコア:2)
過去には実名のVOIDさんやNULLさんが名前を受け付けられない件がありましたが、それもパスワードに応用出来るかな?
ネタをネタと見抜けない人たち (スコア:1)
この話をネタと見抜けない人は、プログラムが書けない人、いわゆるエスケープ処理を知らない人たちでしょうね。
パスワード盗むスキルがある人なら簡単に対処できます。CSVがぶっ壊れるとか、この行を削除したら動くってのは、単なる冗談。
Re: (スコア:0)
それは、例えばSQLインジェクションでパスワードを流出させちゃった連中はプログラムを書けない人と皮肉っている?
Re: (スコア:0)
世の中にはSQLエスケープ処理を自分で書くアホもいれば、CSVパーサーを自分で書くアホもいるので・・
なぜライブラリを使わないのだろうか。古代のperl CGIじゃあるまいし。
Re: (スコア:0)
つまりそのようなアホがいる以上元コメのように簡単にネタとも断定できないということですね。
Re: (スコア:0)
新元号追加→「自分で元号処理書くやつは馬鹿」
→Windowsの元号処理に不具合発覚→「他人の書いたコードを信用するやつは馬鹿」
の手のひらドリル事後諸葛亮には笑った
Re: (スコア:0)
これはおかしなこと言ってないと思うぞ。
出来の悪い自作も他作も使うべきではないで両立するからな。
特にMSなんか信用できないのは当然。
出来のいいライブラリを使う力が必要なんだよ。
Re: (スコア:0)
かきだしだけならたんじゅんなるーぷでいけるし…
Re: (スコア:0)
元ネタはダンプ云々いってるからただの冗談だと思うけど、
流出データ自体がCSVならありえないこともない気がするけどね。
いろいろ推察して読み方を変えてみても、100%成功するとは限らない。
Re: (スコア:0)
それはCSVじゃないだろう。
CSVならちゃんと
user,"pass,word"
となってるから、普通にパーズしてやればちゃんと読める。
Re: (スコア:0)
>それはCSVじゃないだろう。
ちなみに RFC-4180 はこう言ってますね。
>there is no formal specification in existence,
>which allows for a wide variety of interpretations of CSV files.
でもまあこれは20年ほど前の文書。
「それ(カンマを"で括らないの)はCSVじゃない」と言えるだけの根拠(たとえば公式仕様など)が
それ以降にできていたのであれば、教えていただければ大変ありがたいです。
Re: (スコア:0)
△ user,"pass,word"
○ "user","pass,word"
抜けの可能性があるよりは冗長な方が良い
Re: (スコア:0)
じゃあパスワードは「pass","word」と…
Re: (スコア:0)
たとえば、100万人のアカウントを盗んだハッカーが、1つのコンマ入りアカウントの対策にそこまでするだろうか?
もしコンマ入りアカウントが大統領とか要人とか、ターゲットのアカウントなら対処するだろうが、
特定ターゲットを狙わない攻撃なら、1つのアカウントに手間をかけるとはおもえない
Re:ネタをネタと見抜けない人たち (スコア:1)
そもそも「データに紛れたカンマでCSVが壊れる」というのは、CSVを書き出す処理をわざわざ手書きして、「CSVの仕様を満たしてないゴミデータを書き出してしまう可能性のあるダメなプログラム」を作った場合にしか起こらないんだ。
データに「,」とか「\n」とか「"」を含める場合にどうするかというのはCSVファイルの仕様で決まってる。だから正しいライブラリを使えば、それらを含んだデータでも壊れたCSVファイルにはならない。読み込みも同じく、正しいライブラリに任せれば良いだけ。
スクリプト言語だと標準ライブラリに含まれてたりする。それ以外の言語でも、だいたいまあ、誰かが作ったちゃんとしたやつはいくらでも公開されてる。まあ、実務だと、ライセンスがー、というのが問題で気楽に使えない可能性もあるけど、パスワード盗むようなハッカーの話だしなぁ(笑)。
綺麗なデータしか扱わないし、ライブラリを探したり使い方を調べる時間が無駄、というのはあり得るかもだけど、ちゃんと読み書きする処理を書くことまで考えると時間の節約になる。CSVの仕様から調べないとダメだしね。ちょっとした処理の見本として便利だからって、その辺を考慮しないCSV風のデータを読み書きするルーチンが、よく「CSVファイルを読み書きするコード例」として出されちゃってるけど、人にものを教えるつもりで情報発信するならもうちょっと気を使った方が良い。
Re: (スコア:0)
あんなに使われてるのに国際標準とかにはなってないの? それはビックリ。面白い情報をありがとう。
まあ、Python辺りのソースコードを参考にしたら実用十分で説明責任も果たせるんじゃないかなぁ。
Re: (スコア:0)
はい。
https://www.rfc-editor.org/rfc/rfc4180 [rfc-editor.org]
ていうか自分で見つけられなかったの? マジで?
まあこの仕様のCSVはExcelと互換性がないので実質使い物にならないんだけど
Re: (スコア:0)
そこに載ってるのはインターネット用の標準なのでちょっと… csvはむしろインターネット外で使われる規格であるからしてインターネット用の標準化団体の規格なんて結局外野が勝手に決めた企画で下手すりゃ混沌を悪化させただけ。
Re: (スコア:0)
それを指して仕様と言えるのって、中身を読んでない人くらいでは?
Re: (スコア:0)
そもそもハッカーが100万人単位の情報抜き取るときはSQLデータベースのダンプだからカンマが入ってようが壊れたりしない
SQLからCSVに変換して二次流通させるときは変換ツール側で自動的にダブルクオートされるから壊れない
Re: (スコア:0)
盗む奴と売り捌く奴が同一とは限らないんでは。
Re: (スコア:0)
おいやめろ最近寝ぼけてミスした俺の傷に塩を塗るな。
インジェクション攻撃系パスワード (スコア:1)
不用意に扱うとインジェクション攻撃になるような文字列をパスワードに使うとよさそう
ハッカーじゃなく、サイトのほうがダウンするかもしれないが
Re: インジェクション攻撃系パスワード (スコア:2)
EICARテスト文字列とかどうだろ
Re: (スコア:0)
パスワードをちゃんとハッシュ化しているかどうかがわかるな。平文で保存していると検知される
Re: (スコア:0)
不用意に扱うとインジェクション攻撃になるような文字列をパスワードに使うとよさそう
ハッカーじゃなく、サイトのほうがダウンするかもしれないが
日本なら普通に業務妨害で検挙されるだろうなぁ
# なんせ検索アクセスしただけでしょっぴかれるんだもの
Re: (スコア:0)
鎖自慢
Re: (スコア:0)
鎖ではありません。日本という素晴らしい国に生まれたことを自慢しているのです。
Re: (スコア:0)
攻撃者と勘違いされてBANくらいはありえるなあ。
「緊急性が高かったので回復不可な方法で(SQL直打ちとかで)アカウント情報削除しました」みたいな。お金絡んでるけど返金できませんとか、無用な民事トラブルが長引きそう。
#主にセミコロン多用してます
Re: (スコア:0)
昔会社の勤務管理システムのパスワードをスペース一文字にしたら、ログインできなくなったことがあるわ。
ダウンしなくとも内部での処理の仕方によっては、色々面倒なことになるかも知れない。
……まあ最近のシステムなら、ちゃんと登録前に弾くとは思うけど。
Re: Re:インジェクション攻撃系パスワード (スコア:3, すばらしい洞察)
弾けるかどうかは最近のシステムではなくちゃんとしたシステムかどうかで決まる。
むしろ目立っちゃって優先的に悪さされそうじゃない? (スコア:0)
ワシならそーする
Re:むしろ目立っちゃって優先的に悪さされそうじゃない? (スコア:3, すばらしい洞察)
Re: (スコア:0)
オレなら代わりに目立たないスペースを含めておく
確かにやるわ (スコア:0)
新人の頃、動かなかったからやったわ
今ならツールのオプションとか調べて削除しないでやれるかもしれない
逆のケース (スコア:0)
(大手じゃない)某通販サイトで「,」付パスワードを使っていたのですが、ログインができなくなりました。
パスワードリセットをし、今まで設定したはずのパスワードを入れたところ、現在使用中のものと同じパスワードですと表示。
ユーザー名もパスワードもあっているのにログインできないという、どういう処理をしていたのかわからないログイン画面でした。
国際標準化 (スコア:0)
こういうケースもアレだけどさ、そもそも「記号は使えません」とか「パスワードに指定可能な文字数は8桁までです」とかってサイトが多すぎて萎える。
もうパスワード処理とか検索条件の指定方法とか国際標準化してくんねーかなって思う。
Re:国際標準化 (スコア:1)
Re: (スコア:0)
標準化したって無視される、というか派遣プログラマはそんなものを知らない。
「なるほど。「この行を削除したら動く!」みたいな (スコア:0)
閉じカッコを削られることで私の解析器も軽くぶっ壊れました。
エスケープとかそういう概念は無い前提? (スコア:0)
そういうツールを作るようなやつはとっくに対策してるような気もするけど
ワンチャン、うっかり忘れてくれることを祈るばかり
Re: (スコア:0)
ハッカーのポカミスで逃げられる可能性はある。 コスパを考えればやる価値はある。
そのまえにですよ? (スコア:0)
漏洩したのって生パスワードなのですか?
Re: (スコア:0)
あんま真面目にツッコんでもしょうがない話のような気はしますが、まあ件のスーパーハッカーは何とかして
パスワードを復元したんじゃないかな。そこに行き着かないと意味がないから。
でもCSVの扱いはちょっと苦手。
Re: (スコア:0)
Cryptの仕様を変えて、必ずカンマが入るようにしたら流出しても嫌がらせ出来るかもね。
Re: (スコア:0)
この手のハッシュファイルの区切りはコロンが相場なのかと思っていましたが、カンマの文化のとこもあるんですかね…??
Re: (スコア:0)
まともなサイトならハッシュだよな。
だからこの件は最初から的外れ.
季節外れのエイプリルフールだったのだろうか。
なおパスワードやログインIDに記号は禁止しているサイトも
多いと思う。パスワード長が十分長ければ、記号の有無は
本質じゃないし、記号を入れても嬉しいことはない。
コンマが入ったらまずいサイトなら、コンマ入りパスワードは
バリデーションで弾くはず。
Re: (スコア:0)
hashをレインボウテーブルで復号したリストってのがあるんですが、ご存じありませんか。
Re: (スコア:0)
まともなサイトならそもそも流出しない
流出するようなところは生パスワードで保存してたりする
最近もそういう事件があったばかりだよね
・ディスクユニオンの利用者情報が流出か? [security.srad.jp]
そういう前提での話だからその指摘は的外れ