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

ログインするとコメント表示数や表示方法をカスタマイズできるのを知っていますか?

14035794 comment

dodaのコメント: sedもAaAbA (スコア 1) 2

by doda (#3709102) ネタ元: sedとjshellの置換(続々)

以下の結果から sed でも AaAbA になると思います。

% echo "ab" | sed 's/\(\)/A/g'
AaAbA

ruby も試してみたら Java や Perl と同じで a の後ろの隙間が置換されています。

irb(main):001:0> 'ab'.gsub(//, 'A')
=> "AaAbA"
irb(main):002:0> 'ab'.gsub(/a*/, 'A')
=> "AAbA"
irb(main):003:0> 'ab'.gsub(/a*/, '(\&)')
=> "(a)()b()"

awk は sed と同じっぽい。

% echo "ab" | awk '{gsub("", "A"); print}'
AaAbA
% echo "ab" | awk '{gsub("a*", "A"); print}'
AbA
% echo "ab" | awk '{gsub("a*", "(&)"); print}'
(a)b()

13918770 comment

dodaのコメント: Re:日本の運用だとかえって危険になる気がする (スコア 2) 48

sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。

中間経路でのなりすまし攻撃に対して公開鍵認証と比べたらパスワード認証の方が弱いというのは事実でしょう。

なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。

まともな運用が出来ていればいいのですが、『日本の運用』を考えた場合、「取り合えずyesと入力しろ」とか「訊かれたくなければStrictHostKeyChecking=noに設定しろ」等の情報が氾濫している現状から、あまり考えもせずにyesを入力するケースも有りそうです。
実際、Tera Termにも「警告を抑制できるようにして欲しい」という要望が多く来たのに負けて /nosecuritywarning を追加してしまいましたし。
# 実際には海外からも要望が来ていたので日本に限ったものではないかもしれませんが

そしてホスト鍵の確認が不十分な時はパスワード認証は脆弱で、中間者攻撃が行われている場合は接続先が本物のホストだった(ように見えた)時でも安全ではありません。
一方、公開鍵認証は(認証に関しては)安全ですし、本物のホストのホスト鍵が変わったのか、それとも中間者攻撃が行われているかの判別も可能です。(中間者攻撃の場合は認証が失敗する)

「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。

14文字ありますが

  • 使われている記号が : だけ
  • 大文字のFが3度使われている

など、かなり使われている文字に偏りが有りますね。
それらをおまけして"英大文字"/"小文字"/"数字"/"記号"の四種類、計95文字の中から14文字と考えると92bit程度の強度ですね。
これはRSA 1024bit鍵の80bit相当よりは安全ですが、現在主流のRSA 2048bit鍵の112bit相当やED25519鍵の128bit相当よりはかなり落ちます。
# 最新のOpenSSHではRSA鍵はデフォルトで3072bit(128bit相当)を生成するように変わりました

また、このパスワードは「英大文字/小文字/数字4桁を3つ作り、それを : で繋げる」というルールで作られているようにも見えます。
この場合は72bit程度の強度になるので、今はもう使うなと言われているRSA 1024bit鍵よりも弱い事になります。
# まあそれでもオンラインでのブルートフォース攻撃だけを想定するならば十分ではありますが

秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。

秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。

他のコメントでも指摘されていますが、OpenSSH標準で秘密鍵は暗号化されますし、パスフレーズを付けて保護されるのが一般的です。
一般的には行われていない運用を仮定してそれをもって公開鍵認証の方が脆弱だとするのは不公平な比較でしょう。前述したパスワード認証の問題も評価出来ていませんし。

13766519 comment

dodaのコメント: Re:「無課金勢」からの収益化 (スコア 1) 32

クロスオーバードに関しては課金自体を無くすという思い切った手段を取って来ましたね。
クロスオーバードのデベロッパーであるスマイルメーカーは今回のマイニングシステムのヘカトンケイブの開発もしています。
なので、これを売る為の実績作りとして自分の所のタイトルに組み込んだという感じでしょうか。

13620893 comment

dodaのコメント: sshへの影響 (スコア 1) 1

by doda (#3424377) ネタ元: OpenSSLに脆弱性

ちなみにsshでもDHは使われていて、実際にOpenSSHやTera Termでも該当の関数を使っているのですが、
RFC4419でgroupのサイズは1024~8192の間(*1)と決められているので、
これに従ってサイズをチェックしていれば影響を受けないという状況です。
OpenSSH, Tera Term共に該当の関数を使う前にgroupサイズのチェックを行っているので影響を受けません。
他の実装でも大体は大丈夫じゃないかなあと思っています。

まあ、サーバと違ってクライアントの場合は影響が出ても殺しちゃえばいいんですけれど。

*1: 昨年末に出たRFC8270で2048~8192に更新されました

13551451 comment

dodaのコメント: Re:蓋にキャベツが付いたとして... (スコア 1) 140

あとコーンポタージュは面白い解決法があったね。飲み口をちょっとヘコませるやつ。

最近は最初からへこませているのが出てたりしますね。
https://www.itoen.co.jp/products/detail.php?id=300

自分は飲み口が大きいやつが好きです。蓋が閉められるのが便利。
https://www.dydo.co.jp/products/detail/641

13483200 comment

dodaのコメント: Re:hmac (スコア 1) 2

by doda (#3331817) ネタ元: Tera Term 4.97

この辺りは全体としてどの程度の安全性を求めるかという話になります。

鍵長には等価安全性という考え方があって、例えばハッシュ関数のsha2-512は暗号化のaes256と同じくらいの強度と考えられています。
一つの要素だけ極端に強くしても全体の強度には繋がらないので、例えば256ビット安全性を目指すのならばsha2-512を優先し、
128ビット安全性でもいいとするのならばsha2-256を優先するのがいいと思います。

256ビット安全性の方が確かに安全ではありますが、その分負荷等がかかります。
例えばssh通信で1バイトを送る時(例えば何かキーを押したとか)にはsshパケット本体は32バイト(AES使用時)になりますが、
hmac-sha2-256では32バイト、hmac-sha2-512では64バイトのMACがさらに付加されます。

OpenSSH はこの辺り割り切っていて、現時点ならば128ビット安全性があれば十分としてデフォルト値が決められています。

typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...