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

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

2017-09-17

Qiitaにおけるまとめサイト職人に関する情報

Yashima Hirofumi

1981年9月まれ

千葉県市川市在住

現職NTTレゾナント

http://qiita.com/HirofumiYashima

https://www.linkedin.com/in/hirofumiyashima

https://www.wantedly.com/users/17773706

プログラミング情報共有サービスQiitaで、他人記事動画スクリーンショットを使いまとめ記事を作り投稿し続けるオジサン

Qiitaを書いている時に気持ちが高揚しているのか時にポエムや持論に至る事も多々

Yashima Hirofumiが書く記事タイトルは大体こう

・【 Smart contract × multi-A.I.agent system 】BlockChain の smart contract プログラム定義された ”報酬”(reward)を 用いて、個々のノード = 個々の深層強化学習エージェント の 振る舞い が、”群れ” の 全体系 として、タスク問題解決 するため の 最適な振る舞い に なる ように 協調制御する マルチエージェントシステム構成アプローチ

・【 BlockChain DApp 分散アプリケーション企画立案者・実装開発エンジニア 必見 】 開発&リリース運用中 の 自分のDApp が 生み出す仮想通貨 経済圏市場価値 を、各国財政当局中央銀行 の 新手の政策介入 から 防衛 せよ

・【 仮想通貨 × IPアドレス匿名化 】(XVG)VERGE トークンTor 及び I2P を 用いて、メッセージ送信元・送信先IPアドレス の 秘匿 を 図る 暗号通貨情報機関民間調査会社 は、TorによるIPアドレス秘匿化 を 一定条件下 で crack可能 との 報道もあり、信頼しきる のは リスク含み

・【 Microsoft × Facebook 発 】ONNX : Open Neural Network Exchange プロジェクト ~ 3つの深層学習ライブラリ(Caffe2、PyTorch、Cognitive Toolkit)の あいだ で、深層学習モデルソースコード相互変換するプロジェクト

ブロックチェーン仮想通貨人工知能IoTといった話題性をできるだけ取り入れ単語を散りばめたタイトルGoogle検索汚染するが、内容は他人産物転載であり、新規性十中八九無い。

Facebookでも全能アーキテクチャといったグループに多数参加し、自分の書いたQiita記事宣伝する活動に邁進していて、自分以外にこういった増田もいる事から、顔が知られているが好かれてはいない模様である

https://anond.hatelabo.jp/20150602120230

プログラミング関係ないポエム投稿所、まとめサイトとして利用されている事についてQiitaがどう思っているのかかなり疑問だ。

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-08-29

FF14の3年間

もうFF14を初めて3年になる。その間のことを振り返ってみようと思う。

まず降り立ったのはリムサ。召還が強いというwiki情報鵜呑みにして、蛮神を従えるというジョブイメージがカッコイイという理由で巴術士を選択した。

しかし色々触っていると、ペット制御がめんどくさい、魔法が地味、dot管理がめんどくさいという何につけてもめんどくさいだらけのジョブだと気付いて同じキャスター呪術士へ。

前々からネットゲームではキャスターソーサラー職の高火力高コスト設計に強く惹かれていて、毎度その選択にしていたからというのもあった。

ひとまずレベル30まであげて、IDでの立ち回り、スキル回しが気になり始めて調べてみると、どうやらまとめではいちいちサンダーを投げなくて良い、ファイラでいい、50で覚える迅速フレアコンバートフレアが強い、という基本的呪術士としてのお仕事勉強した。

呪術から黒魔導士にあがるころ、公式日記になんとなく書き込んだところ親切なプレイヤーが私のFC見学にきませんかと声をかけられる。そのフレンドをCさんと呼ぶとする。FCマスターであるCさんは竜騎士だった。サブでタンクやヒーラーも嗜んでいた。

トントン拍子でFCに入り、IDに入り浸る。PTプレイでのヘイト管理の仕方を教えてもらう、初めてのメインクID体験する、初めての24レイド、はじめての・・・

本当に本当に大切な思い出であったと思う。このゲームの楽しみ方を教えてくれた。毎晩チャットし、仕事のことやFFについての雑談をした。

Cさんには大変にお世話になった。Cさんの丁寧な話し方、口調、冷静な判断に何度も助けられた。自然にあの人の周りにはいい人が集まった。いい人にはいい人が集まる。その一員になれたことがちょっとだけ誇りでもあった。

レベルカンストトークンを貯め始めたころ、Cさんから難易度レイドにFCで挑む提案を受け、FCメンバーで揃って最下層まで行く。

もちろん全滅するのだが、そのさいCさんは、今までしてきたことを試されていますねと言った。

DPSとしての勤めを果たせていなかったことを痛感する。もちろんCさんは、高難易度レイドを軽々攻略できる竜騎士ではなかった。ただ、全員のPTDPSが足りないだけで、ただ、プレイヤースキルが足りなかっただけだ。

でも皆、そのCさんの発言で、「これはゲームだけどお遊びではない」ということを思い知ったのだ。皆が足をひっぱるまいとスキルまわしを相談しあった。ギミックを復習した。DPSを計った。お遊びだと、永遠にツインニアを倒せないからだ。

しばらくして、ついにクリアすることができた。高難易度レイドでは適性がないといわれていた黒魔導士クリアできた。うれしかったけど、Cさんはふっきれたようにログイン頻度が落ちた。私は、「こういうのは、もういいかな」と思った。

仲間同士できつい思いをしてクリアするレイドは美談として語られがちだが、リアル睡眠時間犠牲にし、リアルの休憩時間ギミックの復習に費やし、ためたゲーム通貨を装備に費やす果たしてこのコストレイドのクリアに値するかといえば、私はそうは思わなかった。それくらい、FF14レイドは現実のいくつかを犠牲にした。

Cさんはそんななか、FCマスターとして皆のことを気遣って励まし、装備を用意し、立ち回り方のアドバイスをくれた。お金稼ぎの仕方や、レイドに行ってない初心者の手伝いに走っていたりした。

それからしばらくは、蛮神に挑戦したりフレンドのエターナルバンドに参加したり釣りを楽しんだり、それなりにエオルゼア世界を楽しんだ。去る人もいればずっとフレンドのままの人もいる。FF14に誘ったリアル同僚の男の子とエタバンをしてリアルでも付き合っている。それなりにエオルゼア世界を楽しんだ。

2年をすぎるころ、Cさんが突然FCを抜けた。彼(もしくは、彼女)の気持ちをうかがい知ることはできなかった。マスターがやめたので、別の人がマスターをした。その人は毎日インしてFCメンバーの遊びにつきあった。

Cさんとは今でもフレンドだし、なにか遊びに行くときに付き合ってくれる。でも今でも、なぜFCをやめたのか、なぜある一定のフレンドのつながりを切って隠居生活突入してしまったのか、その気持ちを知らずにいるし、汲み取ることは出来ないと思っている。

3年目になり、私はCさんのFCマスターをしている。皆3年の間にそれぞれの理由フェードアウトし、やめってった。残った中で私がマスターを受け継いだ。ずっと過ごしてきたFCハウスいつまでも残しておきたかった。メンバーアクティブでいうと5人しかいない。入った当時の半分だ。

そのうちの1人も最近、ひとりでがんばってみようと思います という手紙だけくれてやめていった。私はなぜ、そうなったのかわからない。Cさんがやめていった理由がわからないように、気持ちを汲み取ることができなかった。また同じ事をしてしまっている。ショックは大きかった。Cさんのようになりたかったけど出来なかったのだ。

ネットゲームは遊びだし、皆それぞれの気持ちエオルゼアにいる。

汲み取れないことだってあるだろう、でも、誰かに寄り添って気持ちを確かめたり変えたりすることだってできるはずだった。

私は今でもCさんを、マスターを、追い続けているのだと思う。

2017-08-11

猫・ドラゴントークンすげー可愛い

MTGの猫って可愛いあんまりいない(無害な申し出はNGだ)と思ってたけどこいつ可愛い

10枚くらい欲しい

2017-08-07

日本証券会社セキュリティ対策ゴミすぎる

ありとあらゆる国内証券会社で、株取引画面にアクセスする際のスマートフォンによる二段階認証アクセストークンといった、IDパスワード流出してしまった”後”の対策が一切されていない。

まりIDパスワード流出した時点で、第三者によって自由に株取引がされてしまリスク利用者は常に負っているということになる。

例えばGoogleYahooAmazonでは、認証されていない端末やブラウザからアクセスがあった場合は、登録されている電話番号SMS送信し、本文に記載されているワンタイムパスワード入力しないとログインができないようにする「二段階認証」を採用している。

国内でも、大手銀行ネットバンキングでは、出金手続きをする際は専用のアクセストークンスマホアプリに表示されるワンタイムパスワード入力を求められる。

しかし、何故か国内企業証券口座に関してはこういったIDパスワード流出してしまった”後”の対策が一切されていない。

証券会社側の弁護もしておくと、銀行口座への出金に関しては、契約者の名義と出金先の銀行口座名義の姓名がカタカナで一致しないと出金できない仕様になっているところが多いようだ。

しかし株取引に関してはIDパスワードだけで自由に行うことができてしまい、ネット上でのイタズラ目的などで不正取引をされ、結果的に莫大な金銭的損失を被る可能性は常にある上に、登録されている個人情報に関しては見られ放題で、更に姓名がカタカナで一致すれば銀行口座への出金まで可能になるなど、やりたい放題ということになる。

個人的に気に食わない身近な人物はもちろん、株関連のブロガー、株取引を実況する動画配信者などのネット活躍する人物ターゲットをしぼって、個人情報を抜き取ったり、不正な株取引金銭的な損害をあたえることが充分に可能ということになる。torをつかってIPアドレス偽装してしまえば、刑事事件に発展したとしてもアクセス情報から犯人特定することは実質的不可能になってしまい、中学生でも簡単完全犯罪ができてしまうということになる。

もちろん、前述のような対策をとったからといって100%リスク回避できるというわけはないが、現時点で一般的実施されている二段階認証やワンタイムトークン採用すれば、そのリスクの大部分は回避できるであろうと思われるのにも関わらず、国内の多くの証券会社がその対応をしていないのは、単純に対応を怠っているとしか思えない。

私が確認したところでは

ではIDパスワード流出した”後”におけるこれらの対策はされていないようだった。

利用者としては、大金を預けている以上は最低限のセキュリティ対策をしてほしいところではあるが、専用窓口でその旨を伝えても事務的対応をされてしまい、何だかなぁという感じだった。

2017-07-13

https://anond.hatelabo.jp/20170713111118

銀行ワンタイムパスワードトークンも、時刻式ですよ。

実際、三菱東京UFJのやつは、カードに時刻補正機能を持たせていますし。

ただ、高精度な水晶振動子は、年差5~10秒の誤差しか生まないので、

パスワードカード電池寿命 約5年の間に、仮に50秒の誤差が発生しても、

ワンタイムパスワード有効期限が2分あれば、問題は生じません。

体に障害のあるお客さまが、カード操作し、その番号を入力し終わるまでのタイムラグ考慮したパスワード有効期限は

時刻のズレを十分に補償できてしまうのです。

ワンタイムパスワードトークン

あれどういう仕組なんだろう。

Googleの二段階認証アプリは、スマホ上でうごいて時刻で同期する仕組みがあるから、時刻をシードにしてパスワードを生成してサーバー側と合わせるんだろうけど、銀行ワンタイムパスワードトークンって時刻を合わせる機能ってないよな。

時刻は何年も使ってたらずれると思うけど、電池を交換する機能がないから、そもそも1,2年で使い捨てるもんなのかな。

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/

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