アカウント名:
パスワード:
この件と直接関係はないと思うけど、昔はパスワードハッシュへの理解って低かったよね。昔々の2chに「パワハラしたらエンジニアが辞めちゃって、顧客から顧客情報の問い合わせがあって、問い詰めたけど暗号化を解除する方法をどうしても吐かない、解読不可能だと嘘をついている。誰か手伝ってくれ」って大意の質問があったなあ。
スレ住民がエスパーしてその「顧客情報」はパスワードのことで、「解読不可能な暗号」はハッシュ化のことで、つまり解読は不可能だけどする必要もなく、単に古いパスワードを消して再登録させればいいんだ、新しいエンジニアを探してそう依頼しろとこんこんと説明して何とか納得させてた覚えがある。
それで納得しない人がいると、では平文保存、となっちゃうのかなあ。
昔はハッシュ関数でもなくDESや3DESだった。(未だにパスワード8文字制限の所があってげんなりする)今なら数秒で解読できるけど、まだそういう昔の方法や弱いハッシュ使っているところも多いのだろうな
実際、ADですら「復元可能な形でパスワードを保存」なんてオプションがあるくらいだから、ハッシュでは対応できない認証システムは山のようにある。
大企業のイントラで導入されてる「統合認証基盤」はだいたいそう。
適当こくな、あれはSAMLとかOAuthとか使ってるから復元可能なパスワードなんか持つ必要ないぞ。
まあPeingの事例でわかるようにバカは常に想定の斜め上を行くんだがな
古いところだと、SASLのDIGEST-MD5のような、復元可能でないといけない認証方式が生き残っているのではないでしょうか?
古いところにそういうのが残ってる可能性はあるが、どう考えても「だいたいそう」は言い過ぎ。
いや56bitフルに使ったパスワードなら大規模なクラスタでも組まなきゃさすがにまだ数秒では解読できんよ
以前にもスラドでどこかの時に書きましたが偉い人が「コールセンターがパスワードを回答出来ないとはサービスレベルが低い」とハッシュ保存を嫌がる場合が多々あるのですよDBでは暗号化までは許すがCRMのGUI側では簡単に復号され確認できるようにしろとか・・・後は顧客分析に必要だから手軽に個人情報付きで顧客情報ダウンロードさせろとか部下が進言したところで「お前の常識だろ」と聞きやしない、外部のコンサルから言われても「ビジネスにリスクは付き物だ」とか「何でお前たちは漏れる事前提で話すんだ、漏れるシステムが悪いんだろ」とか
そもそも暗号化自体が「のぞき見られた状況を想定している」って事を理解していない人が多い。暗号化しなければいけないとか言われているからしてる、ってレベルの人たち。
自組織がそんな感じだったら、さっさと言われたとおりに設計実装して、保守フェイズが始まる頃には退職できる段取りを整えておいた方がよさげ。
これについては、今回このように巨大な他山の石というか、聳え立つ糞の山が建立されたので、その手の輩に対して前より説得は楽そう。
被害に遭った人には悪いけど……
外部のコンサルから言われても「ビジネスにリスクは付き物だ」とか
結局これが発動するから科学的なビジネスをやってないうちは何があってもダメなんじゃないの
そういう強い動機があるのならパスワード復元できるシステムでも全然構わないと俺は思うんだけどね。むしろ
後は顧客分析に必要だから手軽に個人情報付きで顧客情報ダウンロードさせろとか
真剣な警戒が必要なのはこっちだと思う。
後者はおまけに、開発者の方も気軽にCSVエクスポート機能とか追加しちゃいそうやしなあ。
個人情報もログインパスワードで暗号化してログイン中のみ使えるようにする。くらいはやってほしいですね。権限のある者に悪意があると抜き取り放題になってしまう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
昔の2chを思い出す (スコア:1)
この件と直接関係はないと思うけど、昔はパスワードハッシュへの理解って低かったよね。昔々の2chに「パワハラしたらエンジニアが辞めちゃって、顧客から顧客情報の問い合わせがあって、問い詰めたけど暗号化を解除する方法をどうしても吐かない、解読不可能だと嘘をついている。誰か手伝ってくれ」って大意の質問があったなあ。
スレ住民がエスパーしてその「顧客情報」はパスワードのことで、「解読不可能な暗号」はハッシュ化のことで、つまり解読は不可能だけどする必要もなく、単に古いパスワードを消して再登録させればいいんだ、新しいエンジニアを探してそう依頼しろとこんこんと説明して何とか納得させてた覚えがある。
それで納得しない人がいると、では平文保存、となっちゃうのかなあ。
Re:昔の2chを思い出す (スコア:1)
昔はハッシュ関数でもなくDESや3DESだった。(未だにパスワード8文字制限の所があってげんなりする)
今なら数秒で解読できるけど、まだそういう昔の方法や弱いハッシュ使っているところも多いのだろうな
Re:昔の2chを思い出す (スコア:1)
実際、ADですら「復元可能な形でパスワードを保存」なんてオプションがあるくらいだから、
ハッシュでは対応できない認証システムは山のようにある。
大企業のイントラで導入されてる「統合認証基盤」はだいたいそう。
Re: (スコア:0)
大企業のイントラで導入されてる「統合認証基盤」はだいたいそう。
適当こくな、あれはSAMLとかOAuthとか使ってるから復元可能なパスワードなんか持つ必要ないぞ。
Re: (スコア:0)
まあPeingの事例でわかるようにバカは常に想定の斜め上を行くんだがな
Re: (スコア:0)
古いところだと、SASLのDIGEST-MD5のような、復元可能でないといけない認証方式が生き残っているのではないでしょうか?
Re: (スコア:0)
古いところにそういうのが残ってる可能性はあるが、どう考えても「だいたいそう」は言い過ぎ。
Re: (スコア:0)
いや56bitフルに使ったパスワードなら大規模なクラスタでも組まなきゃさすがにまだ数秒では解読できんよ
Re:昔の2chを思い出す (スコア:1)
以前にもスラドでどこかの時に書きましたが
偉い人が「コールセンターがパスワードを回答出来ないとはサービスレベルが低い」とハッシュ保存を嫌がる場合が多々あるのですよ
DBでは暗号化までは許すがCRMのGUI側では簡単に復号され確認できるようにしろとか・・・
後は顧客分析に必要だから手軽に個人情報付きで顧客情報ダウンロードさせろとか
部下が進言したところで「お前の常識だろ」と聞きやしない、外部のコンサルから言われても「ビジネスにリスクは付き物だ」とか
「何でお前たちは漏れる事前提で話すんだ、漏れるシステムが悪いんだろ」とか
Re:昔の2chを思い出す (スコア:1)
そもそも暗号化自体が「のぞき見られた状況を想定している」って事を理解していない人が多い。
暗号化しなければいけないとか言われているからしてる、ってレベルの人たち。
自組織がそんな感じだったら、さっさと言われたとおりに設計実装して、保守フェイズが始まる頃には
退職できる段取りを整えておいた方がよさげ。
Re: (スコア:0)
これについては、今回このように巨大な他山の石というか、聳え立つ糞の山が建立されたので、その手の輩に対して前より説得は楽そう。
被害に遭った人には悪いけど……
Re: (スコア:0)
外部のコンサルから言われても「ビジネスにリスクは付き物だ」とか
結局これが発動するから科学的なビジネスをやってないうちは何があってもダメなんじゃないの
Re: (スコア:0)
そういう強い動機があるのならパスワード復元できるシステムでも全然構わないと俺は思うんだけどね。むしろ
後は顧客分析に必要だから手軽に個人情報付きで顧客情報ダウンロードさせろとか
真剣な警戒が必要なのはこっちだと思う。
すば洞 (スコア:2)
後者はおまけに、開発者の方も気軽にCSVエクスポート機能とか追加しちゃいそうやしなあ。
Re: (スコア:0)
個人情報もログインパスワードで暗号化してログイン中のみ使えるようにする。
くらいはやってほしいですね。
権限のある者に悪意があると抜き取り放題になってしまう。