パスワードを忘れた? アカウント作成

こちらは、pochi-pさんのユーザページですよ。 アナウンス:スラドとOSDNは受け入れ先を募集中です。

11999489 comment

pochi-pのコメント: Re:IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア 1) 64

盗聴されうるだろうな、というのは想定しています。それでもあえてログインしている理由は
  • /.Jの初期スコアが違う
  • アカウント削除くらいならされてもそんなにダメージが無い(なりすましは嫌だが…)

…とかですかね。
気分的には「httpな掲示板で再編集用のパスワードを設定」しているような感じです。
全然セキュアでないけどまあ使うかみたいな。

どのみちSSL対応してもらった方が

  • アカウント乗っ取り&なりすまし投稿の心配が減る
  • 日記を書く気になるかもしれない
  • 出先の回線からでもログインする気になれるかもしれない

とかメリットのが確実に多いので気長にSSL対応を待っているのです。

11995958 comment

pochi-pのコメント: Re:IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア 1) 64

パスワードの最大文字数を増やそうって主張には同意なのですが、/.JにはまずSSL対応して欲しいです。 Let's Encrypt開始したら/.Jもさすがに対応してくれるのかな-?
353838 comment

pochi-pのコメント: Re:ホワイトリスト (スコア 2, 参考になる) 62

パナソニック製PHS(KX-HV200)には仰っているような機能が「だれかな応答」という名称で搭載されていました。
なのでパナソニック製の固定電話・携帯電話で同機能が搭載されている可能性はあるかと思われます。
321988 comment

pochi-pのコメント: Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア 1) 77

ストレッチングした意味があるようで無いような…w

ストレッチングの意味は、保存内容と適当なパスワードのハッシュ値の『比較に要する時間を延ばす』ことですね。
難読化の意味合いで使う物では無いと思います。

指摘されてる問題点については、原像計算困難性次第です。
保険的に単純結合以外を使っても良いですが、ソルトを含めて(ハッシュ前の値が)長い文字列になる事をまず優先してください。

321810 comment

pochi-pのコメント: Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア 1) 77

ちょっと誤解されすぎなので全部はレスしませんが、前述のハッシュ値はSHA256で求めたものですよ…。
ハッシュ関数自体を独自に作るのではなく、ハッシュ関数の利用方法の話です。>ソルト&ストレッチング

PHPだとこんなコードです。(わざとダサく書いてます)

$salt = $id . 'himitunomojiretsu'; //(ユーザー毎に違う)ソルト
$hash='';
for ($i = 0; $i<1090; $i++) { //ストレッチング
    $hash = hash('sha256', $hash . $pwd . $salt);
}

こう「するべき」である理由は、貴方も仰ってる↓の点などです。

ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。

実装コードが漏れた場合、同じコードで元パスワードを推測可能です。
ハッシュ値から元の値を直接求めるのが難しいのであり、適当なパスワードのハッシュ値を求めて保存内容と比較するだけなら難しくはありません。
あとは適当なパスワードを辞書攻撃や総当りで選ぶだけです。

解説は省きます。是非紹介した書籍を手にとってみてください。(^_^;)
衝突困難性に加えて、原像計算困難性とかも網羅した解説、綺麗なサンプルコードが載っています。

##他の方の言うHMACについては詳しく知りません。PHPのリファレンス見る限りはストレッチングとソルトを内包した考えなのかな…?

321692 comment

pochi-pのコメント: Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア 3, 参考になる) 77

ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。

それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。

完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。

ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。

例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも

abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'
def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874645a183565'

と別のハッシュ値になるよう実装すべきです。
##それでも実装コードが漏れると駄目です。

この考え方やサンプルコードは徳丸さんの書籍のp327-328に詳しく載ってますので是非読んでみてください。
##というかまんま受け売りです。(^_^;)

321651 comment

pochi-pのコメント: Re:パスワードは平文で保存してたのでしょうか (スコア 2, 参考になる) 77

今の所平文かどうかははっきりしませんね。ただ変更を勧める理由としては
  1. 平文で保存していた
  2. 単純なハッシュ化だけだった
  3. ハッシュ化されたパスワードに加え、ハッシュ方法(プログラムのソース)が漏洩した

の3通りが考えられそうです。
2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
平文でなくても変更を呼びかける可能性はあるでしょう。

297482 comment

pochi-pのコメント: 創作性はあるのだろうか? (スコア 1) 107

by pochi-p (#1901317) ネタ元: ポケモン、セーブデータへの著作権を主張
普通の文章とかでも、創作性が無いと著作権って主張出来ないですよね?
セーブデータに創作性認められるテキストデータを埋め込んであったら、この方式で配布禁止を主張できるかも?

「そのセーブデータには『ポケモン達のつぶやき』が保存されており、無断配布するのは許されない!」
「で、誰が読むの?」
「疲れてるデバッガーの癒しなんだよ! デバッグモードなら表示出来るんだよ!!」

みたいな。

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...