工場自動化シム『shapez 2』正式発表。“圧倒的に好評”の前作から3Dグラフィックへと進化、多層的な工場建設やパイプライン輸送など新要素導入 https://automaton-media.com/articles/newsjp/20230816-259943/
Spoonailと読みます
色々ゲームするひと
あとちょっとしたソフトウェア開発など
※多い・雑多にもほどがある・フォロー/フォロバ気まぐれ
■HOT: Vintage Story、ARK、他好きなゲーム→ https://whiteblackspace.hatenablog.com/prof
■何か作る メイン/最近は
・
もかなり/
ほどほど/C++ほんの少し/つくったものとかはここ
■で遊んだりほんの少しだけカスタム絵文字を作ったりごくまれにファンアートのような何か描きます
■20↑
工場自動化シム『shapez 2』正式発表。“圧倒的に好評”の前作から3Dグラフィックへと進化、多層的な工場建設やパイプライン輸送など新要素導入 https://automaton-media.com/articles/newsjp/20230816-259943/
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
正直自分で覚えるという選択をした時にさっきの以上に複雑にして覚えられるかという話が
自分で覚えないなら完全ランダムに生成しろ終了だし
大量のパスワード漏洩名簿を使って一括で大量乗っ取りしかけるときにはまず個別のパスワード文字列の構造まで解析する動機は薄いと考えられるので攻撃成功頻度は落とせる。これは思った
この方式について「ダメ」って言われることも良くあるけど、
同じのを使い回すのに比べれば「マシ」で、パスワードマネージャー使えない局面ではやっておいて損はない習慣よ。
あなた一人をピンポイントで狙う攻撃に対しては無力だけど、ほとんどの場合の、大量のパスワード漏洩名簿を使って一括で大量乗っ取りしかけるときにはまず個別のパスワード文字列の構造まで解析する動機は薄いと考えられるので攻撃成功頻度は落とせる。
RE: https://misskey.io/notes/9ign5l10er
このアカウントは、notestockで公開設定になっていません。
Misskey鯖缶勢へ
メモリめっちゃ食うの、メモリアロケーターをjemallocに差し替えると安定するねって話がでてます。確かにすごい安定してる。
https://github.com/misskey-dev/misskey/issues/10984#issuecomment-1672495555
導入手順はUbuntu 22.04でやってるならこう。
sudo apt install libjemalloc2
sudo systemctl edit misskey.service
[Service]
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2"
systemctl editはUnitを部分書き換えできるので、[Service]セクションの開始と環境変数の追加だけ書いてください。保存すると自動的にdaemon-reloadされます。あとは必要なときにsystemctl restartです。
試してみて結果が良好なら、みんなでGithubのissueにフィードバックしておくと標準手順になるんじゃないかな。
まあこういう悪さするの余裕なんであんまり使うなせめて実績あるところを(すでにあるんだから)使ってくれって論旨には変わりはないんですよ…
でももう少しなんか書くことあった気がする(
あんまり精度がよくない記事だけど
短縮リンクェ…という話を前にしたっけな
https://whiteblackspace.hatenablog.com/entry/2023/01/26/225032
実はonl.◯◯系については"確率で"本来のリンク先サイトじゃないところにリダイレクトされるって報告もあったから
そのへんもう少し詰めとけばよかったな
あと"中間ページ"が表示されて5秒ほどロード中表示がされるとかもあったのでそこもう少し詰めておけばよかったかな
(けどものがものなのであんまり実験したくなかった)
他にやりようはあるにしてもかなりさっくりとサイトへのアクセスコントロールをほとんど1主体に任せてしまう行為だから…
最悪フィッシングサイトに飛ばされるとかもありうるわけで
まーたキャッチーなデマを…と思ったらソースワシントンポストで草
https://www.washingtonpost.com/technology/2023/08/15/twitter-x-links-delayed/
昔自分用redmineをたてて勉強のためにもLet's Encryptでhttps対応しようとして挫折した身としては
fly.ioがはいこれドメインはいもうhttpsアクセスできますってやってくれるの衝撃だわね…(今回使わなかったけど)
頻出パスワードランキング的なのが公開された時「この中に僕の使ってるパスワードがあるので非公開にしてください」ってコメントが来た、って話思い出した
にするはブラウザコロコロ変えるから
ChromiumとFirefox両方にアドオンが用意されてるBitwardenが一番使いやすいとなっているの
(iOSとAndroidのアプリもあるのでかなりありがたい)
このアカウントは、notestockで公開設定になっていません。
モバイルSuicaのパスワード,数字〇桁みたいな感じなんだけど大丈夫かな(数字しか入力できない)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
まあ暗号化って言葉のほうがハッシュ化より馴染みがあるってことで
元の文字列を違うものに変換するんだよって意味合いというのは十分わかる(
(saltの効果の説明が主題ならそれで十分だし)
このアカウントは、notestockで公開設定になっていません。
さっきも書いたけど結局この辺のセキュリティの話は「やろうとするとめっちゃ大変(1000年単位とか)」で確保してるところあるからな
このアカウントは、notestockで公開設定になっていません。
一個だけ心配があるとすればハッシュと暗号化は違うもので
簡単に言えばハッシュはハッシュ化後の値から元の値を復元できないけど暗号化は複合できる概念のことを指すことが多いにゃあ
このアカウントは、notestockで公開設定になっていません。
これです(
「ソルト」をユーザーごとに違うものにすることで、みんなが「1234」というパスワードを使っていても、ユーザーごとに暗号文がバラバラになるんだ!ここも
このアカウントは、notestockで公開設定になっていません。
「現実的な時間で突破するのが難しい」セキュリティってちょっと直感に反するというか
絶対に破れません!じゃないからややこしいところあるよな
さっきのsaltありレインボーテーブルだって精神と時の部屋に入るか無限個のレインボーテーブル作れるくっそ強計算機があれば突破されちゃうわけだし(?)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
パスワードの平文保存に関しては大手もこんな感じだし(逆にこれ今までトラブル起きなかったのが奇跡では)
ドコモとソフトバンク、パスワードをハッシュ化せず保持 「パスワードを忘れた」からユーザーへ開示【追記あり】 - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2203/15/news172.html
とはいえ(?)さっき貼ったJPCERTのパスワード基準も前は文字種いっぱい使えって書いてあったとのことだし
研究が進んだ成果とか攻撃者とのバトルの成果とも言えるけど、今正しいと思われてるものが数年後やっぱダメだよって言われることもあるからね
難しいね~~~
え、今実際に起こってるって?
この想定はデータだけじゃなくてコードも全公開なのでsaltも当然漏れるしstretchの回数も漏れるもうお祭り状態だが(
RE: https://misskey.io/notes/9igor895un
このアカウントは、notestockで公開設定になっていません。
salt・stretchについては「もしシステム上の情報が全部漏れてもセキュリティを確保する」というな視点の話が面白かったんだけどどこいったかな…
まあ最近はこの辺一介のアプリケーション・サービス実装者が意識することってほぼないだろうしってか普通にオレオレ実装するなだよな(
saltありハッシュ+パスワードがqwerty……ばれにゃいもしsaltが漏れた場合に脆弱
これって意味なくね?とか隠したほうがセキュリティ的に安全!みたいな直感、それに反することを普通に研究者が理論化していたりするので軽くググる範囲でも読むと楽しいよ❤
ちょっとググってもらうと色々出てくると思うんだけど
saltはレインボーテーブル対策になってるのじゃ
まず理論的にはハッシュ化は一方後の操作で、ハッシュ化後の文字列からハッシュ化前の文字列を復元はできないと思ってほしい
例えばP@ssw0rd
という文字列がabcde123456
という文字列になるけどabcde123456
を(元の文字列を知らずに)P@ssw0rd
に戻すことはできない(値は仮)
ただこれ、事前に変換テーブルを作っておけば復元できてしまうよねという(これをレインボーテーブルという)
攻撃者はこんな感じで「よくあるパスワード」のハッシュ化後値一覧を作っておくだろうねP@ssw0rd
-[ハッシュ化]->abcde123456
123456789
-[ハッシュ化]->dbbaaxxyy00
abcde
-[ハッシュ化]->audhjeokk
このレインボーテーブルがあると、サーバーからハッシュ化後の値が漏れました、って時にこのテーブルを使って元のパスワードが復元できてしまう
そしてsaltがないパスワードのレインボーテーブルなんてこれまでに散々作られてるだろうから、相当長いパスワードでも逆引ける可能性が高いね!
ここでもしsaltを導入した場合、同じようにレインボーテーブルで突破するためには「salt入りのパスワードのレインボーテーブル」が必要になる
そしてこれはハッシュの性質によりsaltなしのテーブルから作成できず、新たにまた作成しないといけない
saltなしのテーブルよりはまだ"すでに作成された"大きさは小さいと考えられるので、十分長い安全なパスワードを使っていれば比較的安全…と言えるだろうという感じ
このsaltが確保する安全性は実はsaltが漏れても有効
saltおよびハッシュが漏れたとて、salt導入によりレインボーテーブルを作っておくコストがsaltなしより高くなるという効果は変わらないから
もちろんよくあるパスワードのレインボーテーブルなんてさっさと作れるから脆弱なパスワードを使うのはダメだぞ!!
というのがワイでもわかる基本的な考え方の部分で、世の中にはもっと奥深い解説があるはずなので丸投げするぞい
RE: https://misskey.io/notes/9ignl5dhsr
鯖側では必須ってかそれやってないってことは平文保存
あとsalt・stretchしてくれってTLの有識者が言ってました
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
まあそもそも自分で覚える前提じゃない方が安全という話はあるが
一人でも愚かな人間を減らすためには不要な制限はいらないよねっていう
https://www.jpcert.or.jp/pr/stop-password.html#tips1
、8文字で英大小文字+数字+記号(94種0.6京通り)をすべて使っても、解読コストの視点から考えると安価なため、容易に解読が可能となりますが、記号を使わない12文字以上であれば英小文字+数字だけ(36種473京通り)でも解読コストは高くなり[1]、一定の強度を保てると推測できます。asciiの中で入力できない文字種がある、も困るが大文字やら記号やら必須にするのも
このアカウントは、notestockで公開設定になっていません。
某新幹線の予約サイトのそれは正直ヤバヤバのヤバだと思っているのだが、「券売機で入力可能なものにする」という理由を聞いての顔になった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
そんな驚かんでもオンライン即売会といったらあそこやろ…
と思ったところでそういえばあれ以外のオンライン即売会プラフォってあるのかなと気になった
聞いたことないな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://misskey.io/notes/9gmcx2kn69
これとか20ネスト制限引っかかって表示変になった例
20個までしか効果ないよ〜
RE: https://misskey.io/notes/9ig89vbn50
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。