「トークン」を含む日記 RSS

はてなキーワード: トークンとは

2017-06-09

[]6月8日

○朝食:ヨーグルト

○昼食:助六寿司

○夕食:ご飯、納豆(二つ)、減塩野菜たっぷり味噌汁フリーズドライ)、ツナ缶エビシュウマイ(冷凍

調子

はややー。

うーむ、なんか今週は仕事のノリが悪いのか、今日仕事ミスをしてしまい、注意された。

しゃらくさいこと言うな! って怒られるかもだけど、体使う仕事苦手なんですよ。

普段プログラム実装とか設計とかテストとか要件定義とかをしてるんだけど、水木金と環境リプレイスとか負荷試験とかで何もできないから、

使わなくなったノーパソ倉庫に運ぶ仕事を今週してて。

この手の作業自分かなりポンコツだ。

体を動かすのと、頭を使うのが同時にできないのか、倉庫しまノーパソ管理番号メモるとか、外付けキーボードマウスを落とさずに運ぶとか、その程度の作業ミスってしまう。

で、それにミスる自分に苛立ってさらミスが増えるという悪循環で、気分も最悪だ。

うう、明日もこの作業があるけど、行きたくないな。

そうえば、昔いた会社を辞めた理由の一つに、展示会の準備で物を運んだりものしまったりする作業があることだったことを思い出した。

●XboxOne

○グヴェント ウィッチャーカードゲーム

チャレンジモンスター最後以外は終わらせた。

モンスター最後難易度高すぎる。

「なんかもうフォーマット違うんじゃね?」ぐらいのカードパワー差を感じる。

MTGでいうと、自分が動員令でトークン出すデッキだったら、敵が苦花でトークン出すデッキ使って来る、ぐらいの違いを感じる。

(いやなんでオンスロートのそんな地味レア禁止経験もあるカード比較するんだよ、的なツッコミをされても、MTGあんまり詳しくないからごめんね)

3DS

ポケとる

ログボのみ。

iPhone

○はねろコイキング

トレーナーランク25。

コイキングは、29代目。

コマスター

ログボのみ。

サザンドラデッキ組みたいな。

ただ、今手持ちに、モノズジヘッドが一体ずつしかいから、先が長い。

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2017-04-16

クソじゃない一人用ゲーム運ゲーについて考える

運ゲー定義について人によって別れそうなのでここでは「目的を果たすのに意志決定よりも運が強く求められるゲーム」と仮定する。

「運要素が問題なんじゃない、その要素が強すぎるのが問題なんだ!」っていうのは自明だろうし。


過程や結果の種類が豊富

どうなっていようが楽しいので、意思決定ができなくてもあまり気にならない。

すごろく人生ゲームみたいなパーティゲームが当てはまるが、一人用だと……なんだ?


◆得られるトークンが大きい

強力な武器を手に入れるまでは苦行だったけど偶然手に入れてから一気に先に進むのが楽になりました!きもちいい!!


◆もう思い付かない

運ゲーは)だめだやっぱ

だいたい一人用ゲーム運ゲーとか面白い筈ないだろ!いい加減にしろ!!

2017-04-07

月がようやく復旧、爆発・崩壊事故から3日

人類の大半がデータとして<太陽系>の中で走るようになってから大分経ったけど

解消されると思われた格差問題は新たなステージ突入してしまった。

いわゆる「時間格差」だ。

太陽系>の処理能力無限じゃないかトークンを支払って処理時間を買わないといけない。

俺みたいに貧乏で大規模な研究や探査が出来ない奴は処理時間が買えず、またその間に差を空けられてしまう。

最近はもうインフレ状態で俺が1日過ごす間に上級市民様は1年は活動してる感じらしい。

太陽系>も拡張はしてるけどそれに貢献している市民に優先的に処理時間が割り当てられるしな。

これだけ速度に違いがあるともう追いつくのは不可能だろう。

ところで忘れてたくらい大昔にりゅうこつ座に探査プローブを飛ばした時のトークンがさっき入ったんだけど

何日か前に播種?された自律探査原子?のエサになって助かったってさ。

1日で何年経ってるんだ...ヤバすぎるだろ。

2017-03-22

JINSマジでやばい

https://twitter.com/piyokango/status/844361226767380481

という話があり、その現物なのだが、

http://www.freezepage.com/1490165400GAZZVSXBDT

であるキャッシュの freezepage ですまんが、まあいいだろ。

これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題JINS対応だ。

t_jins_gmo_brandtoken_cancel_if_rireki

t_jins_gmo_brandtoken_change_if_rireki

t_jins_gmo_brandtoken_entry_if_rireki

t_jins_gmo_brandtoken_exec_if_rireki

などといったテーブルから、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報流出した可能性は、恐らくない。

しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカード入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。

この為、こうしたページも不正に改造されていた場合攻撃を受けていた期間に入力されていたクレジットカード番号が不正流出している可能性がある。

ところで JINS 側はこうした問題認識して今朝未明メンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。

推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応ちょっとおざなりすぎではないだろうか。

現実可能性は低いと思うが、例えば以下のような可能性が考えられる。

1. ハセカラ関係者っぽく見せかけた低レベルクラック ↑ を行なう

2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける

3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す

このようにすることで、クレジットカード情報収集していたという事実関係各位に認識させる時間可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実バカスクリプトキディ適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。

こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処必要ではないか

JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータ資産を防護する基本的姿勢が欠けているとしか思えない。

2017-02-21

ウサミン「遊戯王OCGがルール改定?」

(ウサミンの自爆芸はカット。なおどこの時代にするか悩んだが、バンダイ期は冗談がすぎて面白くないし、生贄なし期は競技性がなかったし、と色々考えて、カオス前のサイコショッカーエーススタンダード期が無難だと思いました)

ウサミン「うーん、よくわかんないですけど、具体的にどう困るんですか?」

伊織「例えば、私のオッドアイ宝玉獣はもう構築不可能よ」

ウサミン「不可能!?

伊織宝玉獣破壊されると魔法・罠ゾーンに宝玉化してたまっていくカテゴリなのよ。

からペンデュラムゾーン魔法・罠ゾーンが同一化しちゃうと、スケールをセットすると、宝玉獣がたまらないし、

宝玉獣をためればペンデュラムスケールがセットできないしで、もうこの二つのカテゴリを合わせる意味がないわ」

ウサミン「それはご愁傷様ですね……」

南条ヒーローはまけない!」

ウサミン「おお! さすが光ちゃんです!」

南条「けど、リンクモンスターEXに入れないと融合HERO複数枚展開できないのはなあ」

ウサミン「今は融合デッキ無限枚じゃなくて15枚なんでしたっけ?」

南条「Mを8種全員、融合HEROを六属性六種、に切り札のC・HEROカオス、これでぴったり15枚だったからなあ」

ウサミン「あーなるほど、光ちゃんみたいにHEROで戦いたい! って子もリンクモンスターをいれないといけないのは難しい問題ですね」

(※作者注:完全に南条くんがM・HEROを一人忘れてますが、ただのミスです。剛火ごめん。漫画GXでの活躍(ミラフォみてからフォームチェンジしただけだけど)は忘れないよ)

愛海「あたしはかんけいないよ」

ウサミン「そういうデッキもあるんですね」

愛海「うん、そもそもあたしは特定カテゴリを使うんじゃなくて、その時のメタゲームに併せて構築するからね」

ウサミン「メ、メタゲーム?」

愛海「リンク召喚トークンが使えるか否かでメタ読みが変わるし、地盤沈下新規ゾーン有効なのかも気になるかな」

ウサミン「はー、愛海ちゃんは予想外に頭使う系なんですね」

愛海「ひどいよ!」


日菜子「セフィラはどうなるんでしょうねー、日菜子はストーリーが好きで使ってるので…… むふふ、リンク召喚カテゴリDT世界に来れば、むふふ」

ウサミン「は、はあ……」

日菜子「でも、さすがにリンクモンスターがいないとEXデッキからペンデュラム召喚不可能なのは、厳しいですねえ」


ウサミン「幸子ちゃんはどうですか? 使ってるデッキは……」

幸子「空前絶後のおおおおお!!!

超絶怒涛天使アイドル

天使を愛し、天使に愛された女!

牛丼時計だぶるじぇい

全ての天使の生みの親、そう、ボクこそはあああああ

身長142cm! 体重37kg! デビューシングル1.4万枚!

デレステ引き継ぎ用バンダイナムコIDパスワード! KBCA!

スマホは今楽屋に置いてあります!!!!!

ナナさん、今がチャンスです!

もう一度言います可愛いボクとサイバーエンジェルって覚えてくださあああああい!!!

そう、全てをさらけ出したボクは

サイバーーーーーーエンジェエーーーーエエエエーーーール

こしいいいいいいいいいいいいい

みずうううう!!!!!!!! 

いえええええええい!!!

ジャスティス!」

2017-02-07

ドライブ旅行に便利なアプリ

Yahoo!カーナビ

https://appsto.re/jp/zEkg1.i

無料アプリ

一般優先、高速優先、おすすめルートの三通りが検索可能

Yahoo!アカウントログインすれば渋滞情報も利用できる。

時々トークンの取得に失敗する以外は大変便利。

Pocket Map

https://appsto.re/jp/uSUoH.i

基本無料アプリ(2枚目以上の写真登録から有料)

出かけるエリアに行きたい場所複数あるが、位置関係が分からルートに迷っている時に便利。

地点を検索→分類して登録し、地図上にまとめてピンを表示させて位置関係確認が容易に。

Android版は見つから

車中泊ExpressWebサイト

https://syahak.tvlplus.net

車中泊、仮眠に便利な場所地図上で確認可能

スーパー銭湯日帰り入浴施設の一覧も確認可能

(料金と営業時間も書いてあるため今いけるところを現地で調べるのにも便利。)

2017-01-20

久々のテゼレットはどう使う

奥義が最短で出した次の次のターンに使えることを考えると、

が基本運用か。

テゼレットだからな、エスパーコントロールにすべきかな。

アーティファクトがたくさんあると-2能力が強力になるので、

アーティファクトクリーチャートークンを生成できる呪文と相性がいいように見えるが、

全体火力で焼き払われると手も足も出なくなるのがネック。

まあ、そこは青なんだからカウンターすればいいか

よし。

2017-01-16

http://anond.hatelabo.jp/20170116122716

悪い所編

・最強装備は買える(トレジャーハント度が低い)

 ROとかはレアドロップ狙いみたいなとこありましたが、DQ10は装備は基本プレイヤー生産しているのをマーケットで買う。

 指輪ネックレスなどのアクセサリーは、入場券必要ボストークンを集める(現物が出ることも)

 従来のDQだと宝箱から出た武器防具が殆ど最終装備だったので悲しいといえば悲しい

トレジャーハント要素がクソ

 トレジャーハントをしたいという要望実装されたシステムがめんどくさすぎたので、

 もう今の時代レアドロップとかレアドロップ金策は肌に合わないのかもしれない

 過去の幻影を見てるんだよキミたちは

 多分ふくびきのがトレジャーハント感ある。

プレイしない職業レベルも上げないとならない

 FF14召喚士のみだったので他のキャラ放置してたけど、ドラクエは職レベルを上げる事で、

 キャラの素のステータスがあがるパッシブスキルがあるのでどの職もとりあえず50レベル前後まで上げないとならない

 今は緩和されて60までは経験値3倍とかだけど、このパッシブ上げが苦痛すぎて1年間休止したことある(当時も50まで2倍とかだったけど)

 まぁ、それで興味なかった職に興味を抱く、というきっかけにはなるかもだけど

・初期のクエスト報酬ケチくさすぎ

 初期実装マップ内の一度しかない宝箱の中身が笑っちゃうくらいクソ。

・それでいて、必ずクリアしないといけないクエストがある

 メインストーリの前提として、途中で必ずクリアーしないといけないクエストが科せられる。苦行

・バトルUIがクソクソ

 →たたか

  じゅもん

  とくぎ

  どうぐ

  さくせん

 じゃねーよ!!!!!

      とくぎ

 じゅもん たたかう どうぐ

      さくせん

って十字配置も選ばせろよクソが!!!

初心者向けにして却ってわかりづらい

 パーティ→なかま

 ギルド→チーム

 ってややこしすぎませんかね?

メニューがややこしい

 はなす、つよさ、どうぐなどのおなじみの物にまじって、

 せんれきとさくせんがイメージ難しい

 しかもよく使う作戦のが遠いし。毎日せんれきを間違って選んでしまう。

 それぞれの中に10項目くらい選ぶメニューがある。初期から煩雑になりすぎた。

スキルクールタイムが分かりにくすぎる

 基本体感でそろそろ溜まったなーってやる。クソか。

 一応バトルログにも表示されるけど、バトルログは基本画面に表示されず、

 開くと画面8割がふさがれる。バカか。

・バフアイコン欄が4つしか表示されない

 バフは5,6個とかすぐに超える。点滅で順番に表示される。

 しばらくアイコン注視しないと今かかってるバフを把握できない

・8人PTだと他の4人分の状況が見えない

 ホイミ選ぶ所でもページ送らないと見えないしマジクソ

視点が狭い

 最大に引いてても敵に密着するとカメラが寄る

 敵の行動の吹き出しが見えない。クソ。

NPCしゃべりが長い

 ドラクエ恒例の「ポロロロロ ポロロロ

 長い。石板っていう強化アイテム受け取るのに1個ずつしかもらえず、そのたびに2ページ分のセリフが流れるの本当クソ。

(その後のシステムもクソ)

・職の切り替えがしんどい問題

 昨今の強化システム弊害で、職業チェンジ後のセッティングがめんどすぎる。

 別に僧侶やりたくないのに切り替えめんどくて最近ずっと僧侶してる。

総じてバトル関係UIがクソ。

ドラクエらしさを重視しすぎてる。

はいえ、MMOとしては良いゲームだと思うよ~好きだよ~~

2016-12-14

連続爆破予告実行犯安藤良太氏に関する考察

まずこの記事にはある固有名称複数出てきますがそれらに他人誹謗中傷する意図はない事を前以て誓わせていただきます

ではまず安藤良太って誰よ?って話から始めます

元恒心教信者(ハセカラ民、恒心教徒ともいう)で2015年末~2016年2月中旬にかけて連続爆破予告事件を実行、

2016年2月逮捕起訴されて同年10月21日猶予判決を貰った21歳の元大学生です。

なぜ、そんな彼の話題を今更するのかと言うわけですが、まず12月1日12月2日サイモントン療法協会被害者の会掲示板通称サヒケー、現存していない)に彼の書き込みがありました。

権利関係で彼の書き込み転載する事は出来ないため、書き込み概要URLへの誘導に留めて以下にまとめておきます

静岡中央署のガサが入った(12/1)12/23修正

嫌疑は身に覚えがない爆破予告12/1)

健康保険証まで持っていかれた(12/1)

・再びガサ入れがありキャッシュカードと再購入したiPhone押収された(12/2)

任意同行に行き虚偽の上申書を提出した所解放された(12/2)

自白強要はなかったとする(12/2)

http://i.imgur.com/ghToK9i.jpg

http://i.imgur.com/d7nNTpU.jpg

http://i.imgur.com/on9fbmv.jpg


これらの資料見れば分かりますけど完全に違法捜査です。

嫌疑関係のない物の押収に加えてクレカキャッシュカードトークンなどのライフライン差し押さえ安藤氏の精神を摩耗させようという魂胆丸見えですし。


そもそも現在日本蔓延ってる爆破予告なんてTorが使われていて、犯人の推測こそ出来ても前科が無い限り特定なんてまずできません。

そしてそれらは近代法の前提である推定無罪原則からして法治国家であるならば起訴有罪判決に持ち込めちゃ行けない代物ですしガサ状出すのだって慎重にならなければいけない物なんです。

なぜか新潟県庁爆破予告書類送検されてしまいましたが…


そしてこれらがどうなったか、というと静岡新聞にて彼が品川静岡無賃乗車静岡中央署に逮捕された事が報道されました。

住所不定と記載されていましたが裁判の人定質問上尾市の自宅を引き払った事を証言してましたし特段不思議な事でも無いでしょう。

まぁカード押収して返さずに任意同行と称して静岡までセコセコ呼び出し続けてりゃ金もすぐ無くなってそりゃそうなりますわな、と言った感じです。

こんなもんが押し通って起訴有罪判決になったら法治国家としての日本は終わりと言っても過言じゃないでしょう。

今後の続報と安藤氏の無事を期待したいところです。


追記

静岡中央署のガサ云々は僕の勘違いでした、申し訳ないです。

2016-10-22

http://anond.hatelabo.jp/20161022152541

真面目に品評しよう

サバカレー

12ライフ払っても1ターン目に出せるなら神も真っ青。

カラデシュはアーティファクトいから+2だけで十分だね。

何が悪いってφが全て悪いんだよφが。マローのバカ

杉村三郎

稲妻らせんは1赤白ソーサリーでも十分強い。

よってこれも強いさ。

出したターンに小マイナス能力が使えるというのは、PWの運用に大きな柔軟性を与える。

カッシュ・ゼロロ

変身機会は訪れないだろう。1点の回復ですら許したくないバーン以外は彼を無視すると思う。

何らかの方法クリーチャー化してクリーチャータイプ人間付与して月霧で変身させよう。

真のカッシュ・ゼロロ

変身機会が訪れないので活躍できない。

めとろ

プラス対象が1マナに限られてるのがネックだ…。

1マナマナクリーチャーは今後作られない。

マイナスは出してすぐ使えると嬉しかったな…。

奥義は「トークンでない」がついてないので、トークン戦略なら達成自体現実的だろう。

ただ普通は、8ターン彼を守り、かつ10体もクリーチャーを両産できるなら、奥義を使うまでもなく勝てる。

結論として、俺は彼より捕食者の一撃を入れると思う。

うさうさモード

うーん。出せば勝てる爆弾なら魔性の教示者(2黒黒)で持ってくればいいからな…。

使い捨てるPWではないので手札で腐る、しかやや重いのが気になる。

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-08-15

南条デュエル!」

南条「私の先行! Eコールエアーサーチ。 アライブ! シャドミSSマスクチェンジサーチ! エアーNS! バブルサーチ! 四伏せ! バブルSS! 伏せてあった融合を発動! バブルエアーアブソルートZERO! ターンエンド!」

愛海「……? どうしたの? いきなり」

南条「はぁとさんのお山を登りたければ私を倒してからにするんだな!」

愛海「なるほど! つまり光ちゃんを倒せば、はぁとさんと光ちゃんの2人のお山を!!!!!」

南条「ええ!? い、いや! ヒーロー最初から負けることを考えない! かかってこい!!!!」

愛海「よーし! ドロースタンバイ!」

南条マスクチェンジ発動で、シャドミ墓地送って、ダークロウSS。シャドミ効果ブレイズを手札に加える!」

愛海「勝負ガチガチだけど、女の子のお山はふかふかで柔らかいんだよ」

南条「ふーん。確かにバハシャ餅じゃない分柔らかいね」

愛海「……初手ダークロウなんてヒーロのすることじゃないよ」

南条「ふーん。アブソルートじゃなくてフレシアでもよかったんだよ?」

愛海「く、くそおおお! メイン! フォトンサンクチュアリを発動! そして! トークンリリースして、ブルーアイズを通常召喚

……あれ? フォトンサンクチュアリにもチェーンないし、ブルーアイズも通るの?」

南条「うん、虚無も忠告も宣告もないよ」

愛海「よ! よし! なら、バトルフェイズ、ダークロウ攻撃! 滅びのバーストストリーーーム!!!!!」

南条はい、7400」

愛海「え!?!? バリアもないの!? 2枚も伏せてるのに!?

南条「うるさいなあ、ヒーローはそういうカードに頼らないんだよ!」

愛海「よ、よし、ならメイン2から動くね。霊廟で、トライホーンとエクリプス墓地に送るね。エクリプス効果光と闇の竜を除外。

手札からトレードイン使うね、手札のブルーアイズ送って二枚ドロー

おお、良い手札だよ! 福音ブルーアイズ蘇生! 二体でオーバーレイタイタニック!」

南条制圧制圧制圧、はあ……」

愛海「初手ダークロウの人の言う言葉じゃないよ……

エンドだよ」

南条「よーし、ドロースタンバイ、メイン! ブレイズNS! 効果で融合手札! 融合発動! ブレイズアブソルートでノヴァマス!」

愛海「タイタニックで融合吸うね」

南条「だよねえ、アブソルートの効果は怖いもんねえ、ならば! 伏せてあったマスクチャージ発動! マスクチェンジエアーマンを手札に! そのままマスクチェンジ発動! アブソルートを墓地に送ってアシッド!!!

愛海「うーん、アシッド効果で下げられても2700から戦闘破壊は防げるのかあ…… でもココは福音は使わないよ」

南条強気だな! ならば、アシッドダイレクト! 2600! ブレイズダイレクト! 1200」

愛海「4200」

南条「エンドだ!」

愛海「いくよ! ドロースタンバイ! メイン! 墓地トライホーンとエクリプスを除外して! カオスソーサーラー効果光と闇の竜を手札に!」

南条「予想外なのが来た」

愛海「元禁止カードの実力見せてあげる! 効果アシッドを除外! さらに、ブルーアイズも除外して、コラプサーペント!

そして、カオスソーサーラーコラプサーペントをリリースして、アドバンス召喚

これが私の相棒! 私はこいつと共に強くなる!

光と闇の竜!!!!!」

南条「ぐう、福音付きのそれは強いな」

愛海「そのとおり! 福音破壊代替効果はチェーンブロックを作らないからね!

じゃあ、アシッドにバトル!」

南条「7200」

愛海「エンドだよー、これは勝ったかなー」

南条ヒーローは何時いかなる時も諦めない! 私の最強のドローを見せてやる!

ドロースタンバイ! メイン!

私が引いたのは!」

愛海「無駄だよ! 何を引いても私の光と闇の竜は全てを無効化する!」

南条「っていうか、普通に前のターン回収しといた、エアーマン通常して、効果バブルマンサーチ」

愛海「む、無効で、光と闇の竜が2300」

南条エアーマンブレイズオーバーレイリベリオン

愛海「ぐぐぐうう、福音があるから!」

南条「ふーん、じゃあリベリオン効果で」

愛海「光と闇の竜効果で、1800」

南条攻撃

愛海「3500、効果カオスソーサーラー蘇生するよ……」

南条福音使わないの?」

愛海「うううううううう、うわーーーーーん、光ちゃんが虐めるよおおおおおおお!!!!」

南条「あれ、どっかいっちゃたや……

デュエルまだ途中なのになあ

とにかく! 悪は滅びた!!!!!」


(途中で飽きた、光と闇の竜いねん)

2016-08-03

>その後のAccess Tokenの取得は、一回ユーザが認可すると再度の取得には認可画面による対話操作必要としない仕組みを使い、アプリケーション内で自動的に取得できるような実装になっているんではないでしょうか

普通のOauth2.0の仕組みにのせるなら普通にリフレッシュトークンを使ってると思う。

件のサイトアクセストークンしかもらってないはずだから一定期間で使えなくなるんでは。

にしても多分ディベロッパ用の機能だとは思うけど、

エンドユーザが認可キーを悪意あるサイトコピペできるようなフォーマットを用意するのはどうなのよ。

http://anond.hatelabo.jp/20160802223201

2016-08-02

[]8月1日

○朝食:なし

○昼食:鯖のご飯

○夕食:適当パン野菜ジュース

調子

むきゅー。

定時じゃ定時じゃ! 定時で帰宅じゃ!

で、ゲームをするつもりが、ポケモンSMの新情報テンションが上がってしまい、ゲームはできなかった。

いや、うん、その、月曜日は午後十時から聞きたいラジオが二時間もあるからあんまりプライベート時間がないんだよね。

このラジオだけは、ガチで聞きたいから、ゲームとかしたくないのです。

ポケモンSM

情報で、リージョンフォームが公開されました。

僕の愛する悪ポケたちは、リージョンフォームあるのかなあ。

こおり・あくで、ゆきふらしバンギラスとかどうでしょ?(強い弱いじゃなくイメージの話ね)


それと、ZリングですよZリング

まずは、ゲームと連動するオモチャについて。

これでも一応良い年した大人なので、さすがにこの路線はつらいなあ……

まあ、本編での遊びが追加されないなら、買わないでおこう。

ガオーレと連動しそうだけど、いまんところガオーレは遊んでないからいいかな。

ポケモンGOとの連動はさすがにないかな?

(トレッタでメガリングを楽しげにかざしてただろって? おう! 何なら「進化を超える進化メガ進化!」ぐらい言ってたよ!!!!)

で、次に本編のゲーム中に出てくるアイテムとしてのZリング

これは技の威力インフレについていけてない悪タイプにはかなりの追い風なのでは?

どうやら、持ち物を持たせる必要があるようなので、メガアブソルのZワザみたいな重ねはできないのか。

となると、誰が良いかなあ。

普通に種族値サザンドラ辺りがいいかも。

ちなみにこれ、カードではどう表現されるんだろう。

カード外の新しいトークン?(なんていうの? ボードゲームにおけるコマとかを言いたい)が導入ぐらいの、サプライズがあるかも?


にしても、ポケモンの広がりは本当凄いなあ。

本編、ポケカポケダンコマスターGO、ガオーレ、ポケとる、みんスク名探偵アートピクロスポッ拳

世代だけでも、まだまだありそうだな。

ポケとるの前になんかトローゼ系の奴が思い出せなかった。バトルトローゼだっけ?)

久々に原点回帰で、VC積んでるからやりたいなあ。

2016-07-29

Shadowverse 冥府ウィッチについて

冥府ウィッチ解説します。

TCGプレイヤーの皆さんは何度か試用するとすべてがわかると思いますのでまずリストを置きます

https://goo.gl/QrvdoQ

以下わからない方へ。

あなたはどれほど詳しく解説を受け、各シチュエーションに対する回答を得たとしても今後このデッキを使うとあらゆる選択を間違い、勝てるゲームを落とし、たくさんの敗北を得るでしょう。

なのでここではマリガンや盤面の状況に対してのあれこれではなく負けるあなたを慰める何かを書きます

・すべてに勝つ必要はない

ランクマッチ目的は全勝ではなくBP収支をプラスにすることです。

そしてこのゲームはサイドボードなし一本先取であるため不利なマッチアップを克服することは困難です。

冥府ウィッチにおける不利なマッチアップとは先手のアグロ疾走ドラゴンなどを指します。

それらに対して勝てずともBPが増えるなら問題にはなりません。

・1ゲーム一喜一憂しない

あと1手足りなかった惜敗も先手ロイヤル進化可能前に10点削られて負けるのも同じです。

冥府3枚がデッキトップ10枚以内にあったゲームなどは高確率で負けるでしょう。

足りなかった1手がプレイミスである可能性は負けた後に考える必要はありません。もう遅い。

勝ちの場合もそうです。

・諦めない

「やっぱり難しいデッキはやめて脳死グロ使う……」

あなた脳死グロでもミスします。気が付いていないだけです。

さらに言えば冥府ウィッチは各ターンでの選択は難しいものではありません。

デッキ内の平均カードコストが低く、ターン中に選択肢が多くなりやすいだけです。

時間が無制限にあればとても簡単判断ばかりですし、慣れの問題でしょう。

ウィッチを使いたくないのであれば最初から触っていないはず。

慰めの言葉はもういいですか。

からない系プレイヤーには本来呼吸の仕方や椅子への座り方を解説するのが定番でしたが厳しすぎとの声を受けやめました。

リスト見てだいたい分かるけど何か有益ぽいものを読みたい方へもう少し書きます。以下メインコンテンツです。

マリガン

グロには盤面処理カードを、序盤に余裕のある相手には手を進めるカードを握りたいところです。

なるべく速い冥府達成を求められる対エルフ、対ドラゴンには新たなる運命キープ。

サモンスノーは育てるプランがある場合にのキーします。

デッキから得るべき枚数

新たなる運命を重ねて引いていないなら潜在的墓地20枚くらいある感じになります

5枚くらいデッキからトークンやカースを得るとあとはキャントリップで30枚足りそうですね。

サモンスノーを育てるためにターンを無駄にしてませんか?

・冥府を置く

冥府エルフに対して冥府ウィッチが明確に優れている点は序盤に冥府を置きやすいところです。

エルフ収穫祭や3回カードキャストの都合から盤面を埋めてしまう冥府を達成ターン以外で置きにくく、

結果的複数枚置きにくかったり、そもそも序盤に3枚引くと全部捨ててリノセウスだけで勝つ必要があったりします。

冥府ウィッチではそのターンに何かするよりも冥府を設置する方がバリューが高いと判断できる場合積極的に置きましょう。

投機的なプレイ

運が悪い、相性が悪い、その他不利な状況で堅くプレイして堅く負けては意味がありません。

冥府を2枚置きたい相手でも勝つために2枚目も捨てましょう。

盤面を処理して数ターン延命しても冥府達成できないならば勝つためにクロック無視して次ターン冥府を目指しましょう。

延命しても「そもそも冥府達成できず必ず負ける」ならば「疾走あれば負けるが冥府達成の可能性がある」に賭けるのが勝つためのプレイです。

冥府ウィッチに限ったことではなくあらゆるゲームの基本の話ですが手なりで除去をプレイする前に考えましょう。

他、細かいプレイについても常に勝ちを意識したプレイすることでミス、というか後悔を減らせます

・○○を試してみようかな

多くのBP犠牲にいろいろ試したんで列挙します。

土冥府→冥府達成が遅い。論外。実験開始とルーキーのみのタッチも同じく。

超越冥府→論外。

神秘の獲得→砕くとエーテルにできます

ガントレットヒーラー→手を進めず、盤面に触れず。仕事してるフリがうまいと思います

ヒーリングエンジェル→同上

ベルエンジェル→ほぼ同上。不利な状況でこれ持ってると勝つためのプレイからブレがち。

マーリン→超越サーチのためのカードでありこのデッキには超越は入ってないです。

二重錬成→トークン生成は足りていて、なおかつ重い。マーリンよりは強いが。

ゴブリンマウントデーモンシューターと入れ替えの余地あり。環境次第か。

アルケミックロア→冥府達成できそうなターンにしか撃てない

ファーストカース

ネクロソウルハントみたいなものです。

3点+墓地1 と2点+セカンドカースを得るならば後者のが冥府ウィッチには良い。

カンドカースはカード性能こそお粗末ですが少なくとも選択肢をくれる。


書きたいことは書いた。細かいプレイあれこれは各プレイヤーが考えることかと思います

2016-05-23

つくづく、ズートピアのジュディは自分人生を生きていない、あの物語主人公じゃない、っていう印象で、それがあの映画制作課程のgdgdによるものだと考えたら納得がいく。

最初提示されたテーマであるウサギ新米警官が不利な環境で頑張る、ってのは実質あんまり生きてないよね。

物語の大部分が肉食動物マイノリティ草食動物マジョリティ、だから最初のジュディの部分がどうも浮いてる。

いっそ警察最初から(武器を使うから体の大きさは関係ないとして、)草食動物オンリーにして、エンディングキツネ初の警察官誕生で締める方が話として綺麗なような…

後付けなのはジュディだけじゃなく羊のベルウェザーもなのかな。

ジュディのトークンバニーベルウェザーの髪モフモフって、あの世界の差別被差別構造を分かりにくくしている二大要因だから

本来対話して理解し合うべき二人がスルーで終ったのも後付けだからと考えるとしっくりいくかも

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-04-01

月刊Vim 3月号 - ゼロ除算編

:echo 1 / 0
:echo 0 / 0
2147483647
-2147483648

きっしょwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

他の言語もチェックしてみるか

golang

package main

import "fmt"

func main() {
	fmt.Println(1 / 0)
	fmt.Println(0 / 0)
}

division by zero

php

echo 1 / 0;
echo 0 / 0;

PHP Warning: Division by zero

python 2

print 1 / 0
print 0 / 0

ZeroDivisionError: integer division or modulo by zero

python 3

print(1 / 0)
print(0 / 0)

ZeroDivisionError: division by zero

nodejs

nodejsだと1/0と0/0で異なるメッセージが表示された。

console.log(1 / 0);

Infinity

console.log(0 / 0);

NaN

luajit

luajitだとnodejsで表示されたメッセージの短縮形で表示された

print(1 / 0)

inf

print(0 / 0)

nan

haskell

修正しました thx @anekos

main = do
    print(1 / 0)

Infinity

main = do
    print(0 / 0)

NaN

java

public class Test {
    public static void main(String[] args) {
        System.out.println(1 / 0);
    }
}
public class Test {
    public static void main(String[] args) {
        System.out.println(0 / 0);
    }
}
Exception in thread "main" java.lang.ArithmeticException: / by zero
        at Test.main(Test.java:3)

bash

#!/bin/bash

echo $((1 / 0))
echo $((0 / 0))
test.bash: 行 4: 1 / 0: 0 による除算です (エラーのあるトークンは "0")
test.bash: 行 5: 0 / 0: 0 による除算です (エラーのあるトークンは "0")



haskellnodejsとluajitはエラーにならないけどまあいい。

Vimはやべえよ。


結論言語わずゼロ除算はするな









しまった、4月だった。

2016-03-16

生きています

ショッカーさんへ。ご心配をお掛けしてすみません

305には現在いませんが生きています

相馬実家にはあれほど帰ると書いていたし決意していたけど、結局帰れませんでした。

「至急対応してほしい」という色々なクライアントから仕事の依頼は日常的に来ているのですが、

実家に帰るじゃないですか。だったら対応日数が少なくなるので最低限これとこれを終わらせてから

帰ってほしい」というクライアント要望複数クライアントから重なって、それぞれの「最低限」を

全力でコーディングしたり構築したりメール電話したりしていて、帰るのは無理になってしまいました。

自分能力限界や立ち回りの不器用さを不甲斐なく思っています。先日、エンジニア

1人辞めて代替が効かないので、私が相馬に帰ると各プロジェクト頓挫してしまます

まれから18歳まで育ててくれた母の一周忌に帰れなかった罪悪感で押し潰されそうになりました。

震災から5年でもあるのに、東京仕事忙殺される自分は何をやっているのだろうと自分を責めました。

母の一周忌仕事で帰れないとは家族に言い出せなくて、実家実家関連と思われる着信が30件ほどあったのですが、

無視してしまいました。最後には父がTwitterアカウントを取得して私にリプライを送ってきたのですが、ブロックしてしまいました。

つくづく自分は親不孝なクズだと思って、自分存在してはいけないように思いました。

仕事の「至急対応をお願いします」の電話SkypeLINEメッセージfacebookメッセージは続々と届くので、

放っておくとどんどん溜まっていきます株主から私がスタッフに支払いを大盤振る舞いしすぎていると批判

受けているので、誰かに代わりに仕事をしてもらうにしても会社内部留保を確保した上で金額を決めるように

言われています。そのため自分でないと出来ない仕事がけっこう増えました。

また、訴訟の件が起きてから、私は「人を見る目がない」ということで、株主間の合意で私には会社の口座のお金

誰かに振り込むことが禁止されました。いま会社の口座から振り込みが出来るトークン株主間で専任された方が

持っていて、私はその方に依頼することによってしか会社の口座のお金を動かすことはできません。その都度、

使途の説明必要となります訴訟の方は現在簡易裁判所継続中です。

またクライアント株主の方々は私のはてブブログTwitterfacebookをチェックしているので、

「そんなことを書くなよ!」と言われたり、「仕事が立て込んでいる時にもはてブしたり飲み会に出掛けていて

暇そうに見えますが」と言われたりします。実際は顧客から電話Skypeのこなくなる深夜が唯一落ち着いて

開発できる時間なので深夜に頑張っているのですが、常時監視されている感じです。

元々の持病も精神状態に大きく影響していると思うのですが、帰ろうと決意した母の一周忌に帰れなかったこと、

仕事の連絡が大量に溜まっていて代わりや分担をお願いする自由度が効かないこと、各プロジェクト成功しなければ

会社(≒私)に損害賠償請求されかねないこと…などなど、色々鬱積するものが溜まって、かといって妥結策が

あるわけでもなく、悩んだ末に人知れず死のうかなと思って、簡単な自殺手段サイトを見ていたりしたのですが、

死ぬのは一番の親不孝であることやいまのスタッフに多大な迷惑を掛けてしまうので、しばらく強制的にお休み

頂くことにしました。

私って東京で何をしているんだろうなと思って…。

メインで使っているスマホ3台はSIMカードを抜きました。Twitterfacebookアカウント停止(30日間は

復活できてしまうので30日以上経過するのを待つことにします)、はてなアカウントも停止、メールアドレス

誰にも秘密にしているアドレス以外は停止、新規仕事の問い合わせには対応出来ないのでコーポレートサイトも停止。

ただ、現在仕事の一部を手伝ってもらっている人には、私の資金の方から予定通り全額を継続してお振り込みします。

不器用メンヘラすみません。色々ショックなことが続いて心の傷がどうしても痛んで隠しきれないので、

しばらくお休みを取らせて頂きますクズすみません…。放置されるのが一番だと思います

生きています

ショッカーさんへ。ご心配をお掛けしてすみません

305には現在いませんが生きています

相馬実家にはあれほど帰ると書いていたし決意していたけど、結局帰れませんでした。

「至急対応してほしい」という色々なクライアントから仕事の依頼は日常的に来ているのですが、

実家に帰るじゃないですか。だったら対応日数が少なくなるので最低限これとこれを終わらせてから

帰ってほしい」というクライアント要望複数クライアントから重なって、それぞれの「最低限」を

全力でコーディングしたり構築したりメール電話したりしていて、帰るのは無理になってしまいました。

自分能力限界や立ち回りの不器用さを不甲斐なく思っています。先日、エンジニア

1人辞めて代替が効かないので、私が相馬に帰ると各プロジェクト頓挫してしまます

まれから18歳まで育ててくれた母の一周忌に帰れなかった罪悪感で押し潰されそうになりました。

震災から5年でもあるのに、東京仕事忙殺される自分は何をやっているのだろうと自分を責めました。

母の一周忌仕事で帰れないとは家族に言い出せなくて、実家実家関連と思われる着信が30件ほどあったのですが、

無視してしまいました。最後には父がTwitterアカウントを取得して私にリプライを送ってきたのですが、ブロックしてしまいました。

つくづく自分は親不孝なクズだと思って、自分存在してはいけないように思いました。

仕事の「至急対応をお願いします」の電話SkypeLINEメッセージfacebookメッセージは続々と届くので、

放っておくとどんどん溜まっていきます株主から私がスタッフに支払いを大盤振る舞いしすぎていると批判

受けているので、誰かに代わりに仕事をしてもらうにしても会社内部留保を確保した上で金額を決めるように

言われています。そのため自分でないと出来ない仕事がけっこう増えました。

また、訴訟の件が起きてから、私は株主から「人を見る目がない」ということで、株主合意で私には会社の口座のお金

誰かに振り込むことが禁止されました。いま会社の口座から振り込みが出来るトークン株主間で専任された方が

持っていて、私はその方に依頼することによってしか会社の口座のお金を動かすことはできません。その都度、

使途の説明必要となります。また、私の判断で人を雇うことが禁止されました。訴訟の方は現在簡易裁判所継続中です。

またクライアント株主の方々は私のはてブブログTwitterfacebookをチェックしているので、

「そんなことを書くなよ!」と言われたり、「仕事が立て込んでいる時にもはてブしたり飲み会に出掛けていて

暇そうに見えますが」と言われたりします。実際は顧客から電話Skypeのこなくなる深夜が唯一落ち着いて

開発できる時間なので深夜に頑張っているのですが、常時監視されている感じです。

私にプレッシャーを掛けるとプロジェクトが進むと思う人は多いのですが、

方面からプレッシャーを受け続けると自分は殻に閉じこもってしまうだけです。

元々の持病も精神状態に大きく影響していると思うのですが、帰ろうと決意した母の一周忌に帰れなかったこと、

仕事の連絡が大量に溜まっていて代わりや分担をお願いする自由度が効かないこと、各プロジェクト成功しなければ

会社(≒私)に損害賠償請求されかねないこと…などなど、色々鬱積するものが溜まって、かといって妥結策が

あるわけでもなく、悩んだ末に人知れず死のうかなと思って、苦しまずに死ね自殺関連のサイトを色々見ていたのですが、

死ぬのは一番の親不孝であることやいまのスタッフに多大な迷惑を掛けてしまうので、しばらく強制的にお休みを頂くことにしました。

私って東京で何をしているんだろうなと思って…。

メインで使っているスマホ3台はSIMカードを抜きました。Twitterfacebookアカウント停止(30日間は

復活できてしまうので30日以上経過するのを待つことにします)、はてなアカウントも停止、メールアドレス

誰にも秘密にしているアドレス以外は停止、新規仕事の問い合わせには対応出来ないのでコーポレートサイトも停止。

ただ、現在仕事の一部を手伝ってもらっている人には、私の資金の方から予定通り全額を継続してお振り込みします。

不器用メンヘラすみません。色々ショックなことが続いて心の傷がどうしても痛んで隠しきれないので、

しばらくお休みを取らせて頂きますクズすみません…。放置されるのが一番良いと思います

2015-12-19

[][][]

bitcoin・blockchain

ビットコイン - Wikipedia


はてなブックマーク - 新井俊一のソフトウェアビジネスブログ: 今話題のブロックチェーンとは何なんだ? 部外者の技術者として考察してみる。

はてなブックマーク - イーサリアム共同創業者Vitalik Buterinが語る、ブロックチェインの真の価値 | ビットコインニュースのBTCN

「ビットコインはインターネットの再来だ」

ビットコインがブロックチェーンより重要な理由 | TechCrunch Japan

ブロックチェーン技術は、蒸気機関や燃焼機関と同様に扱われるべき世紀の発明であり、金融界どころか、その外までをも変貌させてしまう可能性を秘めている。」

http://jp.cointelegraph.com/news/115873/what-is-the-reason-that-a-world-financial-institution-invests-in-a-block-chain-technology-as-a-favorite-of-the-fin-technical-center-all-togetherjp3

ロシアの政治家でIT起業家でもあるニコライ・ニキフォロフはブロックチェーンテクノロジーに注目


ハッシュ関数改ざんを検出する

http://itpro.nikkeibp.co.jp/article/COLUMN/20071031/286012/?ST=selfup&P=2



Amazon.co.jp: 仮想通貨革命 電子書籍: 野口 悠紀雄: Kindleストア

2015-11-14

アニメシンデレラガールズ」はEDH《大祖始》だったのかもしれない

アニメアイドルマスター シンデレラガールズ」が最終回を迎えてから、約半月が経過した。

作品のもの感想視聴者それぞれに思うところがあり、また既に多数の感想記事が上げられていることから割愛するとして。

《溶鉄の尖峰、ヴァラクート》アニメとしての『ビビッドレッド・オペレーション』(http://wasasula.hatenablog.com/entry/2014/06/29/012233)という記事があった。こちらをリスペクトし、今回はシンデレラガールズとはどういうデッキなのか、について迫りたいと思う。

シンデレラガールズ原作にあたるゲームは、いわゆる普通フォーマットゲームではない。現在スターライトステージ稼働中はいえ、アニメ制作段階では、アニメ原作と呼べるものソーシャルゲームのみであった。

ゲーム内の登場人物100人を軽く超えている。とてもじゃないが、通常の60枚構築ではゲームの、その中のキャラクターの魅力を表現できない。その上、構築にあたってデッキビルダーは「特定カードデッキに入れること」を要求された。

そこで発想の転換が行われた。アニメシンデレラガールズ」はスタンダードデッキではなく、統率者戦、EDHのデッキとして構築する。

EDHとは、伝説クリーチャー1枚を統率者として指定し、統率者が持つ色の99枚ちょうどのハイランダーデッキを構築する多人数戦用のフォーマットである

大切になるのが統率者選びだが、入れたいカード、入れなくてはいけないカードが5色に散らばっていた時点で選択肢は狭まっていた。5色の伝説クリーチャー、《大祖始》。

Progenitus / 大祖始 (白)(白)(青)(青)(黒)(黒)(赤)(赤)(緑)(緑)

伝説クリーチャーハイドラ(Hydra) アバター(Avatar)

プロテクション(すべて)

大祖始がいずれかの領域からいずれかの墓地に置かれる場合、代わりに大祖始を公開しそれをオーナーライブラリーに加えた上で切り直す。

10/10

後は、強いカードを片っ端から入れていくだけだった。幸い、資金は潤沢にあり、必要カードは全て手に入った。

三色アドバンテージの塊、《残酷根本原理》。

《歓楽の神、ゼナゴス》と《化膿獣》による一撃必殺。

美しく高い性能を誇る、《悪斬の天使》。

軽量アーティファクトとそれを支える《求道者テゼレット》。

玄武岩モノリス》《ブライトハース指輪》による無限マナ、そして《ゴブリン大砲》。

赤と青、相反する二色により生み出される速攻持ちの無限トークン

強いカードだけで組まれ100枚。

アニメ第一話、デッキを用意してゲームを始める直前の統率者顔合わせ……その時提示した《大祖始》を見て、対戦相手……つまりは我々視聴者は、「とんでもないデッキがくる」と覚悟をした。

アニメシンデレラガールズ」とはつまり、以下の様なデッキだった。

統率者:大祖始

クリーチャー

タルモゴイフ

悪斬の天使

鏡割りのキキジ

帝国徴募

やっかい

士気溢れる微集兵

修復の天使

シルヴォクののけ者、メリー

台所の嫌がらせ

残忍なレッドキャップ

包囲サイ

無限に廻るものウラモグ

壊死のウーズ

石鍛冶の神秘

歓楽の神、ゼナゴス

荒廃鋼の巨像

化膿獣

ボガーダンのヘルカイト

シヴのヘルカイト

ボロスの反攻者

瞬唱の魔道士

山賊の頭、伍堂

最後トロールスラー

ラッカワーム

テラストド

ワームとぐろエンジン

聖別されたスフィンクス

飢餓の声、ヴォリンクレックス

プレインズウォーカー

精神を刻む者、ジェイス

求道者テゼレット

野生語りのガラク

遍歴の騎士、エルズペス

ヴェールリリア

呪文

Mana Crypt

太陽指輪

魔力の櫃

玄武岩モノリス

ブライトハース指輪

ダークスティールの鋳塊

殴打頭蓋

稲妻すね当て

梅澤の十手

寺院の鐘

危険な櫃

師範占い独楽

頭蓋骨絞め

demonic Tutor

吸血の教示者

忌むべき者のかがり火

苦悶触手

ぶどう

苦花

ティムールの隆盛

残酷根本原理

歯と爪

force of will

arcane denial

mana drain

サイクロンの裂け目

至高の評決

神の怒り

塵への帰結

汚損破

スフィンクスの啓示

出産の殻

意外な授かり物

青の太陽の頂点

時を越えた探索

精神力

全知

渦まく知識

生体融合外骨格

自然要求

剣を鍬に

四肢切断

流刑への道

実物提示教育

騙し討ち

欠片の双子

ファイレクシアの闘技場

土地

Tundra

Underground Sea

Badlands

Taiga

Savannah

Scrubland

Volcanic Island

Bayou

Plateau

Tropical Island

神聖なる泉

湿った墓

血の墓所

踏み鳴らされる地

寺院の庭

神無き祭殿

蒸気孔

草むした墓

聖なる鋳造

繁殖

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん