  |
はてなキーワード: ハッシュとは
「一日に煙草を一年間吸い続けると」君には躾が必要だ。そこにベンツに昇り降り－ボをしてい続けるといずれ、ところで僕あのーにんにく酸っぱいの好きなんですよ分かります？究極の至宝美体にバッア肘がグネクネし事件と民が迷宮入りと思わたっていたでしょとしていたら、無意杉にメリーゴ区ランドがそこには露わに引ん剝きなされていたのが、いつしか大体そこに止まない雨がないと言われがちですが、実際は何とも言えないなぁ…これ…何とも言れないなぁ…相容れなれないなぁ…そういうことしている間に試合は最初う局面を迎入れいようとしています。時々ロシア語でボソッと天照(アーティスト、作曲・編曲は、Ｋtsh a.k.a 世パ弥。「a.k.a」は「こと」という意味であり、世パ弥ことTashootMANIAという意味になる)をNNするいやロシアに太鼓の○人ねーよ！！(訂正調べたらありました)する、をする日記やVlogを始める方が急増中ですが、皆んな様んは天気が良いですか。！注意！これから先、日焼け止めを飲まなれれば、深淵が闇を覗くとき、深淵が世界に公開されるため、発言に気を付けマシおTVがスマホを激突盆栽を刈る、99歳は還暦を全年迎え、抵抗は空しいぞ。辞めてくれ。其んな顔で僕を見るな。僕は、ベンツに乗っているんだよ。ギャアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアア(ベンツが爆発する)すいませーんダイハツ売ってるって聞いたんですけど(2台目購入)お客さんこんにちはすいませーんこここんにちはーあのー店員さん今(76573台目購入)デビッドカードが売り着て！？駅のビビシビックビジョンの恥ずかしい所の部活動、略して恥部にがボリボ所属して5年目だが、全国大会行けないなぁ…全国大会行くないなぁ…行きたくない。貴方映画館に行きない？ブブーッ(正解の音を裏から表に掛けて)たまには電話ちょうだいよ？横花火に気を取られていた俺は、背後からの気配に笑いに来たバージンロードに耳を澄ませ…SEIKIN TV…た俺は、背後からの花火に五月かなかった！、2020束京オリンピックは、OSUSOWAKE右にもか左にもか、ｼｶﾉｺﾉｺﾉｺﾝﾀﾝﾀﾝ、カニカニフェス確証を得られぬまま、事件盲銘に尾の分け目という諺ップにもあるように、「メークイン装飾の弁当が」地味地味邪魔邪魔UMIGURIサバ女子サブリミナリズムうんぬんかんぬんックス(幻の四十九手目)りたまえ！ﾍﾞｰｽを横取りする境にハイドリデーショキニクス。僕には、呆れたよ(錯乱)。ク。サービスショットの裏には影むな棍あが人知れず…例えば、たまには正面から来たらどうだ？あれ！？上にも縦にも伏兵が溝んで…一体こどうすれな…「任せろ！あ、あなたは！SEIKINtTV！？」さ」て最近は花も一片舞い落ちる便利な世界、貴方と一緒に箱詰を望む女子がマッチングアプリですぐ待っています。今すぐ大好評アダウンロード！7800連ガチャ無料！(そんなに回すのだるいよ)あ、君さ、今、(そんなに回すのだるいよ)と思ったでしょ？心を読むんじゃないよ。セブンイ○ブンじゃないんだから。でも右目を開けたら次は左目を開けて。「はい…」そしたらいややい何んに何してんの！う？凄いでソイこれが世界の真実さ。こればいーっしんだけどね、共有ボタンんを押したね。聖闘士星矢の成人向け同人誌、聖闘士星矢ーンえっち「しょうもねーこと言ってんじゃなたは！SEIKINyTV！？ｽｭ」午前0時と8時と9時に僕は毎晩、あの日のことを思い出す。「そんな日もある」とは言うけど、「そんな日」を繰り返し、気づいたらドン底の人生の成人向け同人誌、気づい矢ーン35ビットのペクリこんにちは！僕は16才だから、もうベンツに乗れるんだ。今日は僕の自慢のベンツヲ紹介スルヨ…あ！注意！エラーが発生しました(メメカバレって興奮するね)。全く…名前を飲んではいけない人、出店で金魚すくいを頼みますよ、非公式でお願いします。「「「「「無修正差分が見たい！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！」」」」」僕の冒険は始まったばかりだ。でも僕がいないと危なかったよね？大きいデミグラスソースに縄張りを伏し付けて、その人には活躍するが、例えば神っぽいなの作曲者が稲葉曇(以下、稲葉)だったとして、実際に絵をWEB描いているのはいよわとは限らない。そういうこと僕は言いたいんです。リゼロ第4章読みましたか？僕はあの歌好きなんです。世界に不思議は事はたくさんありますが、化学の力であの日僕たちが出会ったので偶然ではありませんでした。いつも横に饂飩をよく噛んで食べ、電車の中には山が住んでいる。誰もが思っている事の一つとして、あべこべにでたらめをかける必要なないと言いますが、僕はやります。たまにトイレでは祖父がきゅうくらりんを歌いながら風と土の属性が咲煌きあう。身体を壊す前に無理をして、実際、参考にして下さい。自ずと道すがらくもありあます。道連れに吐露し、それでいて味わいは艶やか。家具を全て捨て、ガムテープで夜を共にする。(助けてくれこの文章にはヘルデルマが隠ている)朝になれば、ボク気づいたことあってヘッド閑散バリスフィント島が上の方にある。そんな時は立ち止まって、駅構内を走りまわさぬ様に下さい。家系図は5cmで轟き、背中合わせのうまい棒とテニスをする(ファミコンのね。)様起きて下さい！上からむ下から肉ドローン撮影に気を取られ、肉球の淵から煎餅を割ると2ポイント。ここでもある日突然だった、世界が0.4°捻じ曲がったあの日から僕の人生は変わった。重度の脹脛フェチの幼馴染が毎朝髪の毛を抜いてくるのでたまらないのだ。仕方ないけど、今は虫眼鏡の中にあるiPhone55VXXXXSRspecialを遍かねんばならないのだ。散漫を揺り戻す捏徐の如く、息も絶え絶えに戦国時代に広島のミニ四駆を衒った。うっせぇわを歌ったのは加藤浩志ですが、イガクを歌ったのは誰？横断歩道とラジオ体操には右左右に気を和け、悲しみに耳も憚らず、弛んで行くしかない。ウルトラマンが倒すのに29分掛かったカーテンレールを、今打ち砕かれようとしているが、なのは完売キャンディーではない。公職選挙法スレスレの合法紛いを突き進み、得てして獲得して勝利へ導かれたくはないか！？でも夜は危ないから気を付けるんだぞ。…僕はこれから何をされるんだろう？でも満たされているこの気持ち、よしBreakingDownに出場しようそう僕は決意したあの日の夜。でも翌朝になると覚悟は薄れるんですよ分かりますかこの気持ち？中と外で反面グリッパーしていて、ルトラマンが倒すのに29分掛かった。これに耐えられる奴は居ない。任○堂の倒し方知ってます？俺は知ってますよと言いながら、七夕に御節を作る。卵から産まれた人間は土に孵るから一緒に楽しもう。こんな事にもある、まあ楽しんだ者勝ちだから道を開け、生ごみを見るようなセンテンスが僕等を待って居る。けども金網をも凌駕する、100さ。海に誘われ、口からが本番だ。舌を鼻で笑い僕んっヤバイ衝撃がマラソン中。でも邪道さの中に正統派があるけど、いつになったら脱出できるんだろう？こっちは巨大娘で真剣に真剣しているのに進撃の巨人だDoDラスボスだ等と言われては腹が立つため真剣して来る。ありがとう！優勝者には意味が贈呈されます！あぁ良い気味ながら、世界一にお金持ちになって気分は如何かな？でも我慢できないから網羅しました(世の理を)。多いなるカには責任が多い僕でもコップを落としてしまうのだから、きっとティッシュを使い切った頃には5cm増えるし、株主を観衆の前に晒す慈しみは想像もでき無い。飽くまで正々堂々と白昼に広げようと言っているのだから、或いは間るも良し。どうしてもと言うのなら、肘と膝が一体型のセットは如何でしょうか？お役くしておきますよ。(こいつ偶に冴えた事を言うから侮ない…)それに貴方はお目が高いの、別室で尻がデカいと知ったら喜ぶでしょうね！セイクリッドルインが待ち受け画像に乱れ、ハッシュド洗米を独り出る血相を変えてまで、必要はあったのだろうか…
ロックに条件持たせる
やりたいことはできてるように見えるが、うーんしんどい
# Entity Relation Diagram
# ```mermaid
# ---
# title: Rental Office example
# ---
# erDiagram
# OFFICE ||--|{ ROOM : x
# OFFICE {
# number office_id
# }
# ROOM {
# number office_id
# number room_id
# }
# ROOM ||--|{ SCHEDULE : x
# SCHEDULE {
# number room_id
# datetime start_at
# datetime end_at
# }
# OFFICE ||--|{ BUSINESS_HOUR : x
# BUSINESS_HOUR {
# number office_id
# enum week_of_day
# datetime start_at
# datetime end_at
# }
# ```
# Directed Acyclic Graph
#
# ```mermaid
# graph LR
# A[OFFICE] --> B[ROOM]
# B --> C[SCHEDULE]
# A[OFFICE] --> D[BUSINESS_HOUR]
# D --> C
# A --> C
# ```
# 基底クラス: EntityLock
class EntityLock
attr_accessor :entity_name, :entity_locked, :attribute_locks
def initialize(entity_name)
@entity_name = entity_name
@entity_locked = false # エンティティ全体のロック状態を保持
@attribute_locks = {} # IDに対するロックを管理するハッシュ
end
def lock_entity
@entity_locked = true
puts "Entity '#{@entity_name}' is now locked."
end
def unlock_entity
@entity_locked = false
puts "Entity '#{@entity_name}' is now unlocked."
end
def lock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && !@attribute_locks[entity_id]
@attribute_locks[entity_id] = true
puts "#{@entity_name} with ID '#{entity_id}' is now locked."
end
end
def unlock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
@attribute_locks.delete(entity_id)
puts "#{@entity_name} with ID '#{entity_id}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定のIDがロックされているかチェック
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
return true
end
# ロックされていなければfalseを返す
false
end
end
# 子クラス: OfficeLock, RoomLock, ScheduleLock
class OfficeLock < EntityLock
def initialize
super("Office")
end
end
class RoomLock < EntityLock
def initialize
super("Room")
end
end
class ScheduleLock < EntityLock
def initialize
super("Schedule")
end
end
# 子クラス: BusinessHourLock
class BusinessHourLock < EntityLock
def initialize
super("BusinessHour")
@attribute_locks = [] # BusinessHour用のロックを配列で管理
end
def lock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks << [start_at, end_at]
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now locked."
end
end
def unlock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if @attribute_locks.include?([start_at, end_at])
@attribute_locks.delete([start_at, end_at])
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定の時間範囲がロックされているかチェック
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks.each do |(locked_start, locked_end)|
if locked_start <= start_at && end_at <= locked_end
return true
end
end
end
# ロックされていなければfalseを返す
false
end
end
# TreeNodeクラス
class TreeNode
attr_accessor :name, :children, :parents, :lock
def initialize(name, lock)
@name = name
@children = []
@parents = [] # 複数の親ノードを保持する配列
@lock = lock # TreeNodeにロックを持たせる
end
def add_child(child_node)
child_node.parents << self # 子ノードにこのノードを親として追加
@children << child_node
end
def display(level = 0)
indent = " " * (level * 4)
puts "#{indent}#{@name}"
@children.each { |child| child.display(level + 1) }
end
def has_dependency
return false if @parents.empty?
@parents.each do |parent|
puts "#{@name} is dependent on #{parent.name}"
return true
end
@parents.any?(&:has_dependency)
end
def locked?(attributes = {})
# 自身がロックされているか確認
return true if @lock.locked?(attributes)
# 親ノードがロックされているか再帰的に確認
@parents.any? { |parent| parent.locked?(attributes) }
end
end
# 木構造の組み立て
# ロックオブジェクトの作成
office_lock = OfficeLock.new
room_lock = RoomLock.new
schedule_lock = ScheduleLock.new
business_hour_lock = BusinessHourLock.new
# ノードの作成
office_node = TreeNode.new("Office", office_lock)
room_node = TreeNode.new("Room", room_lock)
schedule_node = TreeNode.new("Schedule", schedule_lock)
business_hour_node = TreeNode.new("BusinessHour", business_hour_lock)
# ノード間の依存関係の設定
office_node.add_child(room_node) # Office -> Room
room_node.add_child(schedule_node) # Room -> Schedule
office_node.add_child(business_hour_node) # Office -> BusinessHour
business_hour_node.add_child(schedule_node) # BusinessHour -> Schedule
# 木構造の表示
office_node.display
# ロックの確認
puts "Case 1. Office全体がロックされた場合"
puts "Is office_node locked? #{office_node.locked?({})}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # false
office_lock.lock_entity
puts "Is office_node locked? #{office_node.locked?({})}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # true
office_lock.unlock_entity
puts "Case 2. Room id:1 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.lock({ "room_id" => 1 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.unlock({ "room_id" => 1 })
puts "Case 3. BusinessHour start_at:0 end_at:5 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.lock({ "start_at" => 0, "end_at" => 5 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.unlock({ "start_at" => 0, "end_at" => 5 })
まぁ、パスキー(FIDO認証)でパスワードレスの流れじゃないですかね
ビックテックが下記みたいに言ってるので
MSはご希望の個人と企業にはパスワードレスを提供してるよね(大企業は本当に大丈夫か要件と運用確認した方がいい)
ショッピングサイトはAmazonくらいしかパッと思い浮かばないけど、それを追う形になるんじゃないですかね
https://forest.watch.impress.co.jp/docs/news/1540281.html
暗号化どうたらは複合ではなく出来るのは推測
システムのログファイルにパスワードが平文で記録されているとか愉快な作りではない限り、管理者もわかりません
あれだけのプレビュー捌けるエンジニアは基本的にジャガイモではないので、基本的なセキュリティ周りでどうこうは無いと思うんですけど、
えらい人がありがたい発言をたくさんしていることでも知られてますし、面接で面接者の評価に気さくな言葉を残したりしそうな、陽気なひとたちというイメージがあると思います
例えば、カスタマー対応してる時に、ユーザーからパスワードを直接聞き出し、それをメモに残しちゃったら、ハッシュ化ガーやソルト化ガーの意味ないですよね
ハッシュ化してるから～とか言ってるけどあれは理想であって現実じゃないんよ
その手の業界で働いたらわかる
そうなってないところなんて山ほどある
特に企業相手だと一般ユーザーとは違うレベルで丁寧なサポートが必要になる
本番でそんなのいらんだろって思うレベルで全部ログを全部出してたりする
通信ログでサーバーとクライアントのやりとりを全部保持してたりするし中にはパスワードとかが入ってることだってある
そもそもハッシュ化せず生で保存していて、画面で今のパスワードが確認できる必要があるシステムだってある
以前見たものではログインできないの調査依頼に「DBにはabcというパスワードが保存されてましたがユーザーはABCというパスワードで試行してました」とかもあった
世の中そんなもんよ
安心せずに変えておいたほうがいい
ニコニコ自体はウェブ系のところである程度しっかりしてるのかなって思うこともあるけど、カドカワ関係してるし
私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。
個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。
（関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨）
私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさせてください。
サーバーというのは、簡単に言うとシステムを提供しているコンピュータです。
貴方が触っているコンピュータシステムのネットワークの向こう側にいます。この増田も増田のサーバーというのがいて、私たちにサービスを提供してくれています。
しかし、このサーバ、どんなイメージを持っていますか？ でっかい黒い冷蔵庫？ちかちか光るロッカー？ それともバーチャルのネットワークで画面上に写されるものでしょうか。
サーバーといっても、実４形態ぐらいあるのです。私もチョットワカルぐらいなので間違っていると思いますが、まずは理解する為に簡単に説明させてください。
と言う段階があります。
ニコニコ動画のサービスはどうかというと、色々な情報を得ると、④を使いながら③にする途中で、まだ②が残っている、ということのようですね。
これらの使い分けについてですが、最近は自社でサーバを持っていると自分たちで管理しなければならなかったりして大変なので、できるだけ②から③、できたら④に持っていきたいと言うのが世の中の流れです。それでも②はのこりますが、最小限にしていく方向。
現在は、②のシステムがだけがやられたように、セキュリティ的にも預けた方が望ましいと言われています。
今回も、自社で管理している部分が攻撃されました。特にクレジットカード情報が漏れていないと何度も言われているのは、そこを自社で管理せずに専門業者に任せていたことが大きいわけです。
この流れをまずは頭に入れましょう。
さて、メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるこことはありません。これは何故かと言うと、それぞれを細かくたくさんのシステムや仮想サーバに別けた独立なシステムになっているからです。
さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの（バックオフィス）で必要な機能が異なるので、部署が異なるのと同じように違う仕組みになっているはずです。ただし、物理的にどこにサーバがあるかなどはあまり関係がありません。
しかし、こうなると小さなサーバがたくさんたくさんあると言う状態になって管理が大変です。
利用者の視点にしても、システムごとにログインするための情報が別々だと非常に使いづらいですよね。会社で部屋ごとに別々の鍵がついていて、じゃらじゃら鍵束を持って歩くような状態は面倒です。
すると、どうするかというと、これらをまとめて管理するシステムというものが作られます。
これを「システム管理ソフト」と「認証システム」といいます。これらが全体に対してユーザ認証や、サーバが正常に動いているかどうかの管理を提供する事で、たくさんのシステムの管理を効率化するのです。
企業の警備室に機能を集約するようなものです。ですが、ここが要になっていて、破られると全ての鍵が流出してしまうということになるわけです。
出てきた情報から見ると、この管理するシステムと認証するシステムがやられたと思われます。
また、その前の前段はVPNと言う仕組み（ネットワークを暗号化して安全に隔離するもの）が攻撃されて破られたのではないかと推測しています。
これは近頃猛威を振るっている攻撃で、業務用で多く使われているVPN装置の脆弱性（弱点）が狙われて、多数の問題が起きています。当然脆弱性を修正したプログラムは適用されていると思いますが、次から次へと新たなセキュリティホールが見つかる状況であり、匿名のアングラネットでは脆弱性情報が取引されているため、訂正版のプログラムが出る前の攻撃情報が用いられた可能性があります。（これをゼロデイ攻撃といいます） あくまでも推測ではありますが。
個々のシステムは独立しています。ですが、こうなってくると、今回はシステム全体が影響を受け、さらにどこまで影響が及んでいるかの分析が困難なレベルだと言われています。
ここまで広範囲に影響するとすると、管理と認証とVPNが攻撃を受けてやられたとみるべきでしょう。
また、ここが破られていると、クラウドシステムにも影響が及ぶケースがあります。
一時期「クラウド」というとストレージの事を言うぐらい、クラウドストレージが当たり前になって、自社運用ファイルサーバは減りました。これは今では危険と認識されているほかに、こちらの方が安く利便性も高いからです。
それ故に、クラウドストレージ、たとえばSharePoint OnlineやGoogleDrive、Boxなど外部のシステムに置くようになっています。
オンプレミスの認証サーバが破られているので、その認証情報を利用してクラウドにアクセスできてしまったものだと思われます。言わば、鍵を集めて保管してあった金庫がやぶられるようなもの。
通常、クラウドシステムはそんなに甘い認証にはなっていません。例えば多要素認証といってスマホなどから追加で認証すると言うような仕組みがあります。貸金庫に入るとき、自称するだけでは入れず、身分証明書とパスワードの両方が必要なうなものです。
また、日本企業なのに突然ロシアからアクセスされたりすると警報をだして遮断する仕組みがあります。
とはいえ、いちいちクラウドにアクセスする度に追加認証をしていると大変で、面倒クサいと言う声が上がりがちです。
そんなときに行われてしまうのは、自社のネットワークからアクセスするときは、認証を甘くすると言う仕組みです。
つまり、ネットワークは安全だという仮定の下においてしまうわけですね。自社の作業着を着ている人なら合い言葉だけで、本人確認なしで出入り自由としてしまうようなものです。
ところが今回は、ここが破られてしまって被害を受けている可能性があります。自社の作業着が盗まれているので、それを着られてしまったので簡単に入れてしまったようなもの。
また、社内システムからデータを窃盗するには、どのシステムが重要かを判断しなければなりませんが、クラウドサービスだと世界共通であるため、一度入られてしまうと慣れ親しんだ様子で好きなようにデータを窃盗されてしまうわけです。
上記のことを踏まえて、KADOKAWAの展開してるサービス自体や、そこに登録しているクレジットカードは「おそらく」大丈夫です。パスワードも「ハッシュ化」という処置を経て通常は記録されていません。
ただ、パスワードを使い回している方は、その事実とは別にそもそも危険です。パスワード変更をおすすめします。さらに、ハッシュ化をされていても、時間をかければ色々な方法でパスワードを抜き出す事も不可能では無いことも忘れずに覚えておきましょう。
しかし、単なるユーザー、お客さんではなく、KADOKAWAと会社として関わってる人や従業員、取引先で色々な書類等出した人は、既に情報が窃盗されていて、そこから今後も追加で情報が出回る可能性があります。
一方で、分かりやすい場所に保存されていたわけではない情報（システムのデータベース上にだけ入っていたものなど）は、センセーショナルな形で流出したりはしないのではないかと予想しています。
犯人が本当に金が理由だとするならば、データを分析するような無駄な事に労力を割かないためです。
腹いせで全てのデータを流して、暇人が解析する可能性はあります。
ありますが、犯人はコストを回収しようとするので、これらの情報を販売しようとします。売り物になる可能性のものをただ単に流したりもしづらいのではないかと思っています。
もちろん、油断はするべきではありませんし、購入者が現れるとすると購入者は具体的な利用目的で購入するため、より深刻な被害に繋がる可能性も残されています。
犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
また、周到にソーシャルハッキング（オレオレ詐欺のようになりすまして情報を搾取するなどの方法）や、このために温存したゼロデイ攻撃（まだ誰も報告していない不具合を利用した攻撃）を駆使され、標的型攻撃（不特定多数ではなく、名指して攻撃すること）をされると、全くの無傷でいられる企業や団体は、恐らく世界中どこにも存在しません。
それは大前提とした上で、敢えて言うならば、どちらかというと、経営判断が大きいと思われます。
ニコニコ系のサービスと、KADOKAWAの業務システムと2つに別けて話しをしましょう。
ニコニコ系のサービスは、現在、クラウドにシステムをリフトアップしている最中だったと思われます。先日のAWS（クラウドサービスの大手企業）の講演会で発表があったようにです。
ですが、この動きは、ニコニコのようにITサービスを専門にする企業としては少し遅めであると言わざるを得ません。
これは何故かと言うと、ニコニコ動画というサービスが、日本国内でも有数の巨大なサービスだったからだと思われます。特殊すぎてそれを受け入れられるクラウドサービスが育つまで待つ必要があったと思われます。
それが可能になったのはようやく最近で、動画配信系はクラウドに揚げて、残りを開発している最中だったわですが、そこを狙われたという状態ですね。
ただ、厳しい見方をするのであれば、その前に、クラウドに移行する前に自社オンプレのセキュリティ対策を行っておくべきだったと思います。結果論ですが。
それをせずに一足飛びでクラウドに移行しようとしたというのだとは思います。確かに一気に行けてしまえば、自社オンプレに施した対策は無駄になります。コストを考えると、私が経営者でもそう言う判断をしたかも知れません。
KADOKAWAの業務システムですが、これはITを専門としない企業であれば、オンプレミス運用（②番）が多く残るのは普通です。
何故かと言うとシステムとは投資と費用なので、一度購入したら4年間は使わないといけないからです。そして自社向けであればそれぐらいのサイクルで動かしても問題はありません。
しかし、それ故に内部的なセキュリテ対策の投資はしておくべきだったと思います。
以上の様にエンジニアのレベルととかは関係ありません。基本的には経営者の経営判断の問題です。エンジニアに責任があるとすれば、経営者に対して問題点を説明し、セキュリティを確保させる事ができなかったと言う所にあるでしょう。
ですが、パソコンのことﾁｮｯﾄﾜｶﾙ私として、想像するのです。彼らの立場だったら…自社グループに経験豊富なエンジニアがいて、一足飛びにクラウドへリフトアップができそうなら、既存の自社サービスのセキュリティ変更に投資はしないと思います。
逆に、パソコンに詳しくなく、自社部門だけでは対応が難しく、SIerの支援を受けつつやらなければならないと言うのならば、SIerは固いセキュリティの仕組みを付けるでしょうし、システムごとにSIerが異なることから自然とシステムは分離されていたでしょう。
そして減価償却が終わった者から徐々にになるので時間がかかることから、昨今の事情により、セキュリティ変更に投資をしてからスタートしたかも知れません。
ただし、繰り返しになりますが、犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
（おそらくは）社内のシステム管理を、自社でできるからと言って一本化して弱点を作ってしまったのは不味かったと思います。
先ほど述べたように、高度化していく手口でシステムへの侵入は防ぐことが出来ません。
なので、システムは必ず破られると考えて、それ以上被害を広げないこと、一つのシステムが破られたからと言って他のシステムに波及しないようにすることなどを意識する必要がありました。
これは物理的な話しではなくて、論理的な話です。例えば物理的に集約されていてもちゃんと別けていれば問題ないし、物理的に分散していても理論的に繋がっていたら同じです。
すごく簡単に言えば、管理するグループを何個かに分けておけば、どれか一つが破られても残りは無事だった可能性があります。
とりあえず今まで出てきた内容からするとニコニコとかその他のKADOKAWAの外部的なサービスは人員的にも予算的にも全然関係ない感じ
ただ、それより前は動画見るのにログイン必要だったこともあって一部のみたいものを見るために一時的にアカ作ったかもしれないレベル
ただニコニコ初期の頃の時代はほとんど全部同じパスワードだったからアカ作ってたら危ないかもなと思うが一時的な捨て垢みたいのだったらいつものパスワードを使わなかったかもしれない
それに仮にいつものだったとしても当時使ってた他のサービスとか覚えてないからパスワード変更して回るのも難しい
パスワード漏れてるんだとして、ニコニコ初期の時代じゃハッシュ化するもそこまで当たり前じゃなかったと思うし初期の頃から変更してないユーザーは生のままで保存されてたりするんだろうか
既知のCSAMについてはハッシュ化したうえでデータベース化し、疑いのある画像とマッチングするという手法が広くとられています。
perceptual hash‐based detection
LAIONによって確度0.995以上でunsafeと判定されているサンプルを全て抽出し、画像URLをPhotoDNAで検証
マッチしたサンプルをProject Arachnid Shield APIを通してC3P (Canadian Centre for Child Protection)に検証してもらう
CSAM判定されたCLIP特徴を記録
cryptographic hash‐based detection
NCMECの保有するMD5データベースを用いてLAION-5Bに含まれるCSAMを検出
この手法は既にリンク切れになってCSAMか判別できないサンプルに対しても一定の検出を行うことができます。LAIONは各画像のMD5をまとめたものをlaion2B‐multi‐md5, laion2B‐en‐md5, laion1B‐nolang‐md5といった形で公開しており、このMD5をNCMECの保有するデータベースと突き合わせることができます。このcryptographic hash-based手法はrecallが低くなるものの、MD5の一致を見るだけで良いので50億全てのサンプルを走査することができます。
記録したCLIP特徴でk近傍法を行い、データセット全体から類似画像を検索
PhotoDNAで検証
PhotoDNAでは分からなかった画像をダウンロードし、Thornの提供するCSAM分類器で判定
あらたに認定されたCSAM画像のCLIP特徴からk近傍法を行い、上のステップを繰り返す
この類似度検索によってunsafe値に依らない検出を行うことができ、さらにPhotoDNAでマッチしない未知のCSAMも検出することができます。しかしながらC3Pでの検証は人力であり、類似画像をすべて投げるわけにはいきません。そこでThornの分類器によるフィルタリングを挟んでいます。
みつかったCSAMの特徴
あまり詳しい統計は載っていないのですが、Reddit, Twitter, Blogspot, WordPressといったCDNや、XHamster, XVideosといったアダルトサイトのドメインが含まれているようです。またサイトの特徴として"teen models"やヌード、日本の"junior idol"コンテンツが多くヒットしているとしています。
https://qiita.com/__dAi00/items/90521cc333924196a7ba
原文読んでないからそのつもりで
ビットコインマイニングは、ビットコインネットワークのトランザクションを確認し、新たなビットコインを生成するプロセスである。
これは数学的な問題を解くことによって行われる。具体的には、以下のようなステップが含まれる：
1. 新しいブロックの作成： マイナーは未確認のトランザクションから新しいブロックを作成。
2. ハッシュの計算： マイナーは新しいブロックのハッシュを計算。ハッシュ関数は、任意の長さのデータを固定長のハッシュ値に変換。ビットコインでは、SHA-256というハッシュ関数が使用される。
3. 難易度ターゲットの比較： 計算されたハッシュが難易度ターゲット以下であるかどうかを確認。難易度ターゲットは、ネットワーク全体のマイニングパワーに基づいて調整される。
4. ブロックの追加： ハッシュが難易度ターゲット以下であれば、そのブロックは有効とされ、ブロックチェーンに追加される。そして、そのブロックを作成したマイナーは新たなビットコイン（ブロック報酬）とトランザクション手数料を受け取る。
これらのステップを繰り返すことで、ビットコインマイニングは行われる。
このプロセスは競争的であり、最初に問題を解いたマイナーだけが報酬を受け取ることができる。
現代のAIはモデルって呼ばれてる奴は重みが調整された巨大なデータ構造です。
データ構造は多分ニューラルネット的なやつが一般的なのでは。知らんけど。あ、私素人ですので、あまり真面目に聞かないでください。
そんでこのモデルは入力に応じて出力が変わります。LLMなら猫っていれたら、猫について語りだして猫この特徴や可愛らしさや、猫にまつわる人間の感情についての文章が出力されるだろうし、画像生成なら猫の画像が出てきます。
モデルは多くの場合関数として振る舞うので、出力方向からこの出力結果を入力すると(お尻にバイブを刺すのと一緒です。)元の入力データが復元できます。猫にまつわる説明文を後ろから入力したら「猫」って言葉が出るし、猫の画像を後ろから入力したら「猫」って言葉が取り出せます。
画像認識AIがやっていたことが全く同じことで、画像認識AIと画像生成AIは裏表の関係になっています。
ところで人間の場合は多くの人が、猫を識別できるにも関わらず、猫の絵を描くことが出来ません。
人間の脳は、これらAIが獲得している何かの機能を削ぎ落としているようです。
なんかそのへんが一方向性ハッシュっぽさあるよなーって思った。この辺のアイディアを組み合わせたらなにか、劇的にAIの計算コストを下げれそうよね。
あとは発話とかの人類共通の計算をハードウェアにしてしまうとか、世界モデルのベースをハードウェアに落とし込むとか色々計算効率化はありそうな気がしている。
人力イラストは、目から入ってハッシュ化され脳に記録されたデータ、もしくは頑張ってハッシュを行わずに保存されてるデータからの手を使った画像復元処理って感じだろうか。
アニメとか漫画のイラストとか絵を見るとき脳の効率を使わずに気分良く見れるのは、脳内の削ぎ落とされたデータに近い形での表現だからだろうなって思いました。
こうなってくるとハッシュはいいすぎててたんに情報量を落としたデータだな。
ぐぐったら、別人のXの投稿がでてきたんだが、どういうことだ
soraもすごいと思うけどズームもパースも狂った動画を大量の計算で15秒捻出するより
Gemini 1.5がアホみたいにデカいハッシュ長を振り返って参照し類推できる技術が将来的にプロンプトの精度を高めるのも確実なわけで
方向性が異なるものを同じハコに入れてどっちが上とかいう意味はないと思うんやが— 火鍋チャンネル（ヨッピー本人） (@hinabe_ch) February 19, 2024
山本一郎（Ichiro Yamamoto） @kirik.bsky.social · soraもすごいと思うけどズームもパースも狂った動画を大量の計算で15秒捻出するより Gemini 1.5がアホみたいにデカいハッシュ長を振り返って参照し類推できる技術が将来的にプロンプトの精度を高めるのも確実なわけで 方向性が異なるものを同じハコに入れてどっちが上とかいう意味はないと思うんやが
GPT-3.5のハルシネーションでももっと意味のわかる文章生成するのに、こいつやばすぎだろ……
でかいハッシュ長って何語？参照し類推って何？プロンプト精度を高めるって何？
むかぁしむかし、2ちゃんねるにはVIPというものがあって、これはVIP待遇とかそんなものではなくて単なる掲示板の分類のひとつなんじゃが、そこにはコテハンというものがおった。
（注・今もあると思うが自分が離れて現在の状況が分からんので過去形で書いています）
トリップという、ハッシュを付けたあとに特定文字を繋げることで生成される固有IDのようなものを名前欄に入れた「固定ハンドル」、通常「コテハン」がVIPでは闊歩しており、ここまで書けば理解ると思うがワシもそのコテハンの1人じゃった。
コテハンには様々な個性があり、今で言うぶいちゅうばあのはしりとも言えるんじゃあないかと思う。
コテハン同士で論破論破したり、名無しの人生相談に乗ったり、他の掲示板に「VIPからきますた」したりなど、暇で平和で自由な世界じゃった。年末年始は積雪した駅のライブカメラアドレスを載せたスレッドを保守したり、名前欄でomikuji!したり…
（書き続けるのがだるくなったので文章はここで終わっている）
