「キー」を含む日記 RSS

はてなキーワード: キーとは

2016-05-02

行間多い増田を見て、若いなあ、ブログ文化かなあと感じつつ

増田は空行ってエンタキーでの改行連続じゃできないじゃん

行間多めにあけてる増田って、pタグとか打ってるわけだよね

意図した行間なんだよね

そう思うと何かプロスキルを感じる



追記:

はじめて知ったわ

http://anond.hatelabo.jp/20160502002322

もっと世の中からパソコン使える人が減って、windows使えるだけとか日本語キー入力できるだけ程度で

ヌル仕事ガンガン回ってくるような世の中になるといいなと思います

傘ってなんでもっと進化しないんだろう

すぐにパクられるし無くすし強い風が吹けば壊れるし

折り畳み傘はわざわざ袋から出して開くまでに時間がかかるし使い終わって屋内に入る時はびしょびしょの傘を閉じてカバンの中に入れるまでの時間もかかる

何十年も変わっていない

キングダムハーツキーブレードのように念じれば「シャキーン!」と手のひらに現れて欲しいなあ

2016-05-01

絶対音感とか相対音感とかよく知らんけど、採譜能力がずば抜けてる人は尊敬してる。

セッションだと何のキーの上の何のコードの上かが既に分かってるから絶対音感に頼る必要はあまりないのよな。あるに超したことはないが。

というか、即興やる人と耳コピヲタク以外絶対音感って必要ないんじゃないかなぁ。

あと絶対音感ってAbsolute pitchだと思ってたらPerfectも使われるんだね。和訳気持ち悪いのかと思っていたら元から変だった。

タッチパッドが効かなくなった

アップデートした後だから勝手に設定切り替わったのかと思ったけど、win10にしてからスタートキーが開かないのでどうしようもない。

ログイン画面だと動くけどログインすると効かなくなる。

ケータイで調べてるとfn+タッチパッド切り替えキーを押せとある

よく見るとそういうのがあり押すと直ったがめんどくせー死ね

Windows8.1環境でcmd.exeを起動する方法

http://valvallow.blogspot.jp/2016/04/windowscmdexe.htmlの内容はだいたいは8.1でもできるがヘルプでcmdを検索(何もヒットしない)からはできないし「すべてのプログラム」が「すべてのアプリ」になってる

Windows8以降の操作があまりにも知られていないのでなかったのを追加(Windows10もほぼ同じだがコルタナからcmdでもできるのが8.1と違う)

キーボード場合

Win+Xを押して↑キーメニューからコマンドプロンプト」を選んでEnter

Win+S(またはWin+Q)を押して「cmd」を入力してEnter

Winスタート画面を表示し「cmd」を入力してEnter

Win+EでExplorerを起動しAlt+Fでファイルメニューを表示しPでコマンドプロンプトを起動

マウス場合

画面左下で右クリックしてメニューの「コマンドプロンプト」をクリック

画面右上(または右下)へマウスポインタを移動しチャームから検索」を選んで「cmd」を入力して「コマンドプロンプト」をクリック

画面右下のWindowsボタンクリックしてスタート画面を表示し「cmd」を入力して「コマンドプロンプト」をクリック

Explorer上部のリボンにある「ファイル」をクリックし「コマンドプロンプトを開く」をクリック

タッチパネル場合

画面左下を長押ししてメニューの「コマンドプロンプト」をタップ

画面右端からスワイプしてチャーム検索タップして「cmd」を入力して「コマンドプロンプト」をタップ

画面右下のWindowsボタンタップしてスタート画面を右上の検索ボタンタップして「cmd」を入力して「コマンドプロンプト」をタップ

Explorer上部のリボンにある「ファイル」をタップし「コマンドプロンプトを開く」をタップ

2016-04-28

天然の釣りだと好意的に見る

http://anond.hatelabo.jp/20160424205934

新学期、娘の通う幼稚園でクジを引き、父母会役員になってしまった。

と、同時に区の私立幼稚園PTA連合会理事兼任することになってしまった。

軽くググって見たが、幼稚園PTA要職に就かないで、各PTAを束ねるPTA連合会理事になる方法はあるのだろうか。

自治体連合会理事というのは主にPTAの正副会長から選出されるようだ。

(仮にPTAでなくPTA連合に参加しない父母会であれば、増田PTA連合会理事に選出されることもない)

まり父母会、というのはPTAから独立した組織でなく、実はPTAグループに属する幼稚園PTAの事であり、元増田十中八九、今年度の江戸川区内の私立幼稚園PTA副会長に絞り込まれることになる。

なんか個人が特定できてしまいそうな情報が散りばめられてるなあ。適度にフェイク入れてるのかとは思うけど。 - camellow のコメント / はてなブックマーク

心配されているが、元増田書き込み真実なら、PTAPTA連合会区別が付いてない天然かわいい新人ママだよね。

数年前は、「26,000円ありがとう」なんてタスキを

から掛けさせられてお母さん達踊ってたそうな。26,000円は江戸川区私立

幼稚園補助金金額だ。税金等払うもの払っての補助じゃないの?

という所は、かわいらしい勘違いから複雑な釣りポイントが仕込まれている。

税金等払うもの払っての補助じゃないの?

これである

どう考えても、保護者以外の大勢赤の他人が払ってくれた税金があってこそ貰える補助金である

ここの話の筋がよじれているから、ある者はミソジニーの作り出したヒラエルキー構造を読み取って、傷ついた心のまま

そんなランチ食べるお金があるなら

会費を上げたいなんて発言はやめてほしい。

という連合会会費(PTAから徴収と思われる)の話とお金の話つながりで一緒くたにして燃料にしてしまう。

納税者ありがとう釣りさよなら、そして、全ての園児に、おめでとう。

(勿論、私立公立不公平性の是正範囲を超えているなら問題である

また、トラバブクマ

無駄を変革できなかった、というより、これが変と思わないオッサンは充分に変態扱いされる価値があるな。 - Pokopon のコメント / はてなブックマーク

が星を集めているが、元増田発言

数年前は

とあるとおり、実はすでに解決されてしまっているのである

(「誰に媚びているのか、媚びる必要あるのか」問題を提起したかったのだろうか。

 予算をつけてくれた区長予算をぶんどってくれた会長理事会古参?)

(他にも細かくポイントがあると思われるがちょっと時間が無いのでここまで)



繰り返しになるが、なんで各所に釣りポイントが散りばめられているのかというと、

娘の通う幼稚園でクジを引き、父母会役員になってしまった。

とまったく理解を進めないまま役員になってしまった経緯がしっかりと述べられているよね。

天然かわいい

http://anond.hatelabo.jp/20160428113146

たぶん増田と同じ程度に絶対音感を持ってるけど、

カラオケでどれだけキー変えても迷わず歌えるし、増田提示するような場面で困った事はないかな。

(頭の中の鍵盤で最初の音を数えれば、それを基準にその後も問題なく歌える)


世間では絶対音感がもてはやされてるけど、自分感覚としては

絶対音感自分の中の基準をもとに、一つの音の絶対的な音の高さを測る能力)と

相対音感(二つの音間の具体的な幅を測る能力)は別の能力だと思うし、

訓練次第でどうにでもなると思う。

絶対音感保持のメリット

自分は一応絶対音感がある(但し机を叩く音が音階に聴こえない程度のもの)。

世の中的には絶対音感があると有利と言われているけれど、最近そうでもないんじゃないかと思い始めた。


絶対音感保持最大のデメリットとしては、転調が苦手になること。

結構これ致命的なんじゃないかと思う。

絶対音感がなければ、キーボードではトランスポーズ機能を駆使すればて12キーで弾ける必要はなくなるし。

バンドVo.にキー変えてって言われても動じずに済む。


絶対音感があることのメリットってなんだろうね。

ジャズの難しいテンションの音なんかも判別やすくなるというけれど、ややこしい音は自分もよくわからないw

それに鋭い相対音感があれば、そんな音も度数でわかってしまうのではないだろうか。


増田にいる絶対音感保持者にその辺聞いてみたいです。

http://anond.hatelabo.jp/20160428094109

完全に間違ってる。逆にするとファンクションキーまで手を伸ばすときの負荷があがる

文字以外のキーまで覚えている人は少数だから確認にも手間取る



キーボード違いだがデスメタルなんかだと「俺はこんなセッティングでもここまで弾き倒せるんだぜ」と

アピールするためにわざと垂直に近い状態に設置するキーボーディストが大量に居る。真似したことあるけど

非常に弾きにくい。極限まで下にたらしたギターと一緒で年齢とともに普通位置に移動する

https://www.youtube.com/watch?v=XVifw7Atg2Y

2016-04-27

酒飲みとかい反社会勢力

アルコールは脳を萎縮させます

アルコールは容易に致死量に達します。

アルコール社会秩序を乱します。

アルコールは家庭を崩壊させます

アルコール凶悪犯罪者を生みます



酒豪(笑)(笑)(笑)(笑)(笑)酒飲み(笑)(笑)(笑)(笑)(笑)(笑)(笑)

ただのアル中がなに市民権を得ようとしているわけ?wwwwwwwwwwwwwwwwwwwwwwwwwww

ボトルキー(笑)(笑)(笑)大人趣味(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)飲みニケーション(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)(笑)

適当なことぬかしてんじゃねえよ雑魚wwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

あなた方の破滅はまともな人類すべての願いです。死んでください。

もうなんだか色々と辛い


同性愛者の話だから苦手な人は読まない方がいいかもしれない



増田には付き合って10ヶ月くらいになる彼氏さんがいるわけですが

不満というかなんというか…不信感が日に日に募っていく



どうして知り合ったか

アプリで遊ぼうと呼びかけていた彼がおり、その日は丁度休日で暇してたので呼びかけに乗ってみる事にした

まぁ特に何とも思わなかった人なんだが、でもせっかくだし友達くらいにはなれたらいいなと思ってた

そんな思いを伏せつつ、とりあえず街中散策

それなりに会話も弾み、時刻は夕方過ぎ

これからどうしようか、なんて会話をしてたら(増田の)家に行っていいですか?との返事

別にいいよ、家汚いけれどそれでもいいならと了承

そこから家に上がり、挿入なしのHをした



かい会話は覚えていないけれど、その中でまた会いたいとか好きだとか告白された気がする

彼の事は悪い印象は特になかったのでOKしてみた

いいなと特に思わない普通の人を好きになるのはこれが初めて

俺が好きになっていくのはもうちょっと後になるのだけど細かいところは忘れた




で、そんな事はともかく、何が辛いって

・彼がHを求めてこない

浮気してる

性的質問話題を振ってものらりくらり

・基本わがまま

こんな感じである

浮気してるってのは別にいいんだけど(この世界じゃよくあるし)

浮気を隠そうとしてるのか、ひたすらに嘘を吐き続けていることが何より辛い

同棲してないので、「自分時間が欲しい」と言って帰ったりするんだけど

でもその後に浮気してるの知ってる

むっつりスケベのド変態なくせして、自分には求めてこない

一度言われたんだよね

増田くんとは精神的な付き合いがしたい」

あなた容姿に惹かれた訳じゃない」

セフレ?いないよ」(いないとは言っていない)

うん、それってさ、都合の良い男ってやつ?ヒモATMキープ君?

別に俺が求めればそれなりにしてはくれるんだけど

未だに挿入は一切したことがないんだこれが

え、それってなんなの?やっぱ振り回されてるの?俺アホなの?

他の男とは繋がってるくせして俺はなし?

こういう事を本人にぶつけたところでかわされたり逆切れしたりするんだよなぁ




大体俺が何もしないと本気で何もしないで一日が終わる

ポジション的な事を書いておくと

彼はリバ(攻めも受けもやれる)らしい

対して自分はタチ(攻め)

もう一つ書いておくなら彼は遅漏なのでイかせるのはとても難しい

頑張っているのだけど、まともに俺が彼をイかせた事がない

H自体めっちゃ下手だとかそこまではない筈なのだが感じてはくれるものの、どうしてもイってくれない

そういった欲求不満を外部で発散してるんだろうことは想像つく

でもさぁもうちょっと俺に対してむきあってくれてもいいんじゃないの…



彼はHの欲求はさほど無いだとか言う

H自体はしたいけど俺とはさほどしたくないという意味なのだろう

でなければ浮気しまくりということにはならないし



そらーセクロスけが全てではないとは思う

が、こんなの性の不一致で離婚案件ですよ奥さん

出会って1年経つその時まで待ってほしい」と言われた事もあるもの

その時に全く何も無かったら別れるつもりでいる

せっかく本気で好きになった人なのに寂しすぎる

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 のような場合は期限切れがあってはならないので、パスワード等を預かる

http://anond.hatelabo.jp/20160426133852

そもそも、公式配信で見たい人は「無料 アニメ 動画」じゃなくて、他のキーワード検索するだろうから、ある種の最適化の結果なんだろうとは思うが。放置されているのは謎。

アプリケーション情報探していると、youtubeの「こうやってキージェネ使って認証パスすれば無料Adobeも使えるぜ!」みたいな動画が出てきてウンザリする時がある。

2016-04-25

Vim使いの生き様

Vimを使いはじめる←←←←←←←←←←←←←←←←←←←←←←←←←←←Vimに興味を持つ

↓                                       ↑

Vim操作を体で慣らしていく→→→サクラエディタSublime Textに逃げる→→→ゲームオーバー

プラグインガンガン入れる→→→プラグイン開発に手を出す→→→ダークサイドに落ちる→→→フハハハ!そのまさかだ!→→↓

↓                     ↑                              ↑    ↓

プラグインを減らしていく          ↑                              ↑    ↓  

↓                     ↑                              ↑←←←←← 

Vim本来バインドの使い方を学習する→→操作プラグインを追い求める

↓                           ↑

vimgolfを始める→→→キー入力を減らすことに目覚める→→↑

                 ↓

              さら研究する

世間所謂おすすめNo.1ランキング1位のスペック自分妥協点との乖離について

一言でいえば全然満足できない

 

おすすめNo.1される理由が安い値段ギリギリ範囲内で不具合を起こさな

たったこれだけなんだよね

 

値段に対してこの機能が優れてるんだぜ!とか

この値段でこのスペックコスパいいぜ!とか

 

そういう賢さが全く無い

 

単に安くて、故障しないっていうだけ

あるかないかの違いだけ

 

例えばキーボードとかおすすめのを買うと100%キーの間の間隔が無かったりする

特徴、無い

強いて言えば安くて初期不良がないだけ

 

こんなんこぞって買う客ばっかりって馬鹿ばっかりか貧乏人ばっかりってことじゃん

なんで世間馬鹿たちって賢い買い物できないの?

俺の場合は取りあえずあればいいというものを買ったから性能とかどうでもいいけど

そんな俺みたいな理由だけのユーザーで一位になれるわけもないから

このキーボード本命に購入した人間が大半なんだろ?

あと1000円出せばずっと使い続けたくなるやつも買えそうなのに

なんでその1000円を惜しむの?

意味分からん

その1000円払わなかっただけで感じてしまう余計なストレスとかは計算しないんだろうか?

まあ、馬鹿が多い方が助かることもあるんだろうな…

 

というわけで今はもうレビュー1位とかランキング1位のものを買う時は

とりあえずあった方がいいものやクソでも構わないもの使用率の低いものを選んで購入してる

俺みたいな感想を抱く人間にはレビューもまるで役に立たない

このレビューついてればいいみたいなレビュー至上主義は俺にとって何の役にも立たない

俺みたいなユーザーを納得させるものを構築できればさらマーケットは広がると思うのだが…

2016-04-24

キーボードの有線apple US テンキー有りを購入した

今はまだムズムズするけど、慣れたら今までより早くなるんだろうなーってのはわかる

これで、windows JISキーwinlinux用)、macbook JISキーmacbook pro用)、apple USキーmac用)の3種

最終的にデスクトップは全部 apple USキーでまとめる予定

macbook JISキー配列クソすぎて、USにしなかったことを今でも後悔している

controlキー位置とか冒険しすぎだろ!

どうしてそこにcaps lock置いたんや…

フミコフミオとシッキーの件で一番クソだったはてなー

ダントツシロクマ


フミコフミオゲスだったけど、ゲスなりに真剣に怒ってた

シッキーバカだったたけど、バカなりに真剣批判した

それを見たシロクマが「あれっ?ねえねえ何してんの?あっ、分かったネットバトルでしょ?二人ともネットバトルしてるんだ!そっかぁーネットバトルかぁー。……あ、ネットバトルなら僕も一言いうね!僕はねーえーっと、しっきー君はカンフーが足りない!!!!」

アホだろ

こういうアホが、四六時中アホな『総括』をしているから、はてなでは同じような議論が繰り返し繰り返し蒸し返されるんだろうな

きちんと議論が尽くされる前に、『ネットバトル』とかいうクソな話題に回収されるから


シロクマネットバトルって言ってるからネットバトルだー!って考える連中もアホだけど、まあアホの親玉が一番アホだろう


興味のないトピックなら黙ってればいいのにね





とか書くと、またブーメラン教のブーメラン狂信者ブーメラン認定して見えないブーメラン勝手幻視してブーメラン刺さってる発言してくるから本件一応言及しておきます

フミコフミオの書き方が悪いと思います

しかしながら、自殺をほのめかして耳目を集める北条のやり方が許されるのも間違っていると思うので、もっと穏当なやり方がないか、みんなで考えていくべきではないでしょうか

以上です

今年30になるアラサーオタク女の悩み続き

http://anond.hatelabo.jp/20160420193246


この投稿後日談です。


結論から言います彼氏にフラれました。やっぱり私は向こうにとってキープ的存在だったそう。

そりゃそうだよね、デートだって月一するかしないのレベルだったし付き合ってると思ってたのは私だけだったんだろうね。

3年無駄にしちゃったわ…


まあでも好きだったから泣きました。かなり。

これを機に結婚相談所行ってみます

オタク女に恋愛は無理でした。

2016-04-22

はてなに嫌いな人が居る

それも何人か。

気づけば頭のなかでその人のことを考えてイライラしてたりする。

正直、今まで現実で人を嫌いになった経験があまり無いので、なぜネット上の人物にこうも嫌悪感が持てるのか自分でも不思議でならない。

何がだめなんだろうか。ネット嫌悪を増幅する何かがあるのだろうか、それとも相当その人がクズなのだろうか。

よくよく考えれば、現実特定の人物を嫌いになっても、その人となりを知っていくにつれて、許せるようになった例が結構ある。

ネットだと、一種人間味というか、そういうものが見えにくいから嫌悪キープできるのだろうか。

2chとか増田特定人物に粘着する人を、今までは傍観できていたのだが、一歩間違えば自分もそちら側に堕ちてしまうような気がして恐ろしくなる。

http://anond.hatelabo.jp/20160422120929

PageDownキースクロールしたくらいで仕事した気になってる奴wwwwww

2016-04-21

フルキータイプ(101とか109とか)のキーボードで、Numlockキーってなんのためにあるの。

2016-04-20

今年30になる独身アラサーオタク女の悩み

まだギリギリ20代だけど今年30になる。

気がつけば同年代の周りの友人はほとんど結婚していて、早い人は子供を二人とか産んでたりもする。

26、27歳くらいの頃はまだそんなに結婚に対して焦ってなかったけど、ここ1、2年、週末のFacebook自分より年下の知人たちの結婚投稿で溢れてて自分が完全に出遅れてるのに気づかされたw


いちお彼氏がいないわけではない。

今の彼氏とは3年ちょっと付き合ってる。でも向こうは当分結婚とかには興味ないんだとか。

今の彼氏のことは好きだけど、「結婚」したいならさっさと別れて婚活すべきなんだろうか?

29と30じゃ婚活市場ではかなり差が大きいよな…


将来は好きな人結婚したいなんて昔は夢見てたけどそんなこと言ってる場合じゃないよな。

そもそも恋愛結婚したいならもっと早く(高校生くらい)からたくさん恋愛して経験値積むんだったわorz




追記

気付いたらブクマ増えててびっくりしたw

今の彼氏は…自分から初めてちゃんと告白して付き合った相手なんです。だから私の方はとっても好きというか。

でも向こうはそこまで私のことが好きじゃなく、ご指摘通りキープ的な感じなのかもですが。


初めての告白20代後半って遅いですよね。今まで好きな人がいなかったわけではないけど、根暗な私はそんな大胆なことができず、少年ジャンプ同人系を読み漁る不毛青春を過ごしてしまったわけです。

人生やり直せるなら10代に戻って勇気を出して告白して恋愛面の経験をきちんと積んで大人になりたい。

2016-04-19

http://anond.hatelabo.jp/20160419211309

Delete_Allさんは叩かれないよ、たぶん

北条さん相手じゃ話にならない。

北条さんが注目されはじめた当初、PCに敏感なはてなー彼女を遠巻きに眺めて当たり障りないことを言っていた気がするけど、今じゃもうだめだろね。

Delete_Allさんはバランス感覚なんて言葉三輪車こいでるように思えるほど、絶妙イメージコントロールをこなしてきたよね。

けっこう危ういところをかなりこなしてきたように見える。

自分好意的な人をファンに、できなければ「好意的」なままキープ、自然と生じるアンチに対しては無関心層へと誘導する術がとにかく巧みだ。

それをなんとなくする(ように見える)のだから、並大抵には真似できないように思える。

なにかの資質にとても恵まれた人だと思うし、もしかしたらただのバカかもしれない。

からないんだよね。

北条さんへのブコメって「こいつわかる、こいつこうだろ」って感じだったと思うんだけど。

なんかすごい差なのよね。