がるの健忘録 このページをアンテナに追加 RSSフィード

2018-04-02

[][]password_hashをどうやって使おうか?(04/15修正)

なんか最近「パスワード、いくつかの単語を組み合わせた長い文字列のほうが安全だよねぇ」的なお話が云々。

それを考えた時、今まで割と気にならなかった「警告 PASSWORD_BCRYPT をアルゴリズムに指定すると、 password が最大 72 文字までに切り詰められます。」が、途端に気になりだしてきたり。


ふと考える2つのコード、果たしてどっちがベターなのだろう?

或いは、変わらんかなぁ?

一応おいちゃんの中にはイメージがあるんだけど、ふと、問いかけてみたいように思ったので、書いてみる。

どうも、どっちも危ないっぽい。後述を参照のこと。


コード1(アウト)

$pass = パスワード;
if (72 < strlen($pass)) {
    $pass = hash('sha512', $pass, true);
}
$h = password_hash($pass, PASSWORD_DEFAULT, ['cost' => 10]);

コード2(アウト)

$h = password_hash(hash('sha512', $pass, true), PASSWORD_DEFAULT, ['cost' => 10]);

costの明示指定は趣味だ気にスンナw*1


さて。コード1とコード2、どっちがどうなんだろう???


追記。

徳丸さんがfacebookで書かれていたんだけど。

「password_hash 関数バイナリセーフでない」んだそうだ……………え?まぢで?

徳丸さんが載せていた、検証コード。

$password = "LmUb9dTqXUTTCuCxzCct3n2lIf/zS3IeZ15mtCivl0TQlD97YZtxK+u0j4AploaErAu9uYBBfqNs4R2nQITnyq+nuLZd";
$crack = "ma";
// Use sha512's raw(binary) output
$h = password_hash(hash('sha512', $password, true), PASSWORD_DEFAULT);

// Verify
$r = password_verify(hash('sha512', $crack, true), $h);

var_dump($r); // TRUEが返る

うん通った orz

コード1なら「上述は防げる」けど、「72文字を超える文字列同士で「任意箇所に\0が入ってくる」なら突破できるから、あんまりよろしくないぽげ。


さて思案。

バイナリが駄目なら、base64にすればいいぢゃない」とか思うんだけど、sha512はbase64にしても88バイト使うから駄目なんだよねぇ。

ってなわけで、おとなしく素直に「16進数表記のsha256」が落としどころかなぁ、と。とりあえずは。


改めてコード1

$pass = パスワード;
if (72 < strlen($pass)) {
    $pass = hash('sha256', $pass);
}
$h = password_hash($pass, PASSWORD_DEFAULT, ['cost' => 10]);

改めてコード2

$h = password_hash(hash('sha256', $pass), PASSWORD_DEFAULT, ['cost' => 10]);

このどっちか、になるんかなぁ今の所だと。

*1:いや実際のところ、12くらいを指定する事が多くなってきたしねぇ

2017-05-18

[][]軽めネタ2種

ちょいと前に、twitterで軽くアンケートをさせていただいていたのをすっかりとまとめ損ねていたので。

ふとした疑問。

ECサイト(色々あると思うのでお好みのECサイト)にて。「買い物カゴに商品を入れる」アクションでCSRF対策は必要でしょうか? 主観バリバリでよいので、アンケートさせてください。

https://twitter.com/gallu/status/717927849726861312


不要のほうが多いのが、興味深いような納得感があるような。

おいちゃん的には「CRUDのうち、CUDにまつわるものは一通りCSRF対応の対象」って考えているのですが。

この辺にもまぁ、色々な色があって面白いなぁ、と。

ECサイトでいうと「勝手に商品をカゴにぶち込まれる可能性」があって。いやまぁ大体、支払いのタイミングで気づきそうな気もするのですが、「うっかり気づかない」のほかに「ECサイトの性質的に(大量に買う前提なので)気づきにくい」とかあったり、なんてのを考えると、色々。


もう一つ。

そういえば、な疑問。

「社内(あえて規模は書かない)で使うシステム」のセキュリティって………

https://twitter.com/gallu/status/793076216450338816


これは割れたw

19% 通常のopenなWebと同じ程度にがっつり

32% IPAの推奨に準拠する程度にはしっかり

31% 多少穴があっても気にならない

18% XSSやらSQL-Injectionやらも無問題

興味深いのが、2割くらい「穴がっぽがっぽでも無問題」ってあたり。「多少の穴があっても」を含めると5割。

多分「社内の管理ツールだから」なんだろうなぁ、と。

おいちゃん的には「内部犯行とかもあるしねぇ」って考えちゃうので、その辺はまぁ、人それぞれ。


おいちゃんのスタンスとしては割とはっきりしていて。

上のECのにしてもなんにしてもそうなんだけど「IPA推奨レベル、程度まではしっかりとセキュアに」が基本。

なんでかってぇと、それくらいなら「(事前にちゃんと学習コストが支払われている前提で)さほどセキュリティかけるのにコストがかからない」ので、天秤的に、やらないのほうに傾きようがないから。

で、それ以上の「特別にコストかけてでもがっちょりとセキュリティをはるか?」については、ケースバイケース。


うんまぁ前提が「IPAの内容とか、徳丸本とか、それくらいのレベルの学習はきちんとなされていること」なんだけど。

学習コスト自体は……エンジニア特性その他にもよるにしても基本「支払ってるでしょ? 支払うでしょ? そのルート作るでしょ?」って発想が強いしなぁ正直。

最近だと法的リスクの問題もあるし(苦笑


どれが正解、ってもんでもないのですが。

まぁ「こんな話もあったよ〜」的なネタとして。

2017-05-03

[]どうすっかねぇ(ユニットテスト変)

いくつも起因するお話はあるのですが、例えば最近おきたおもころいあたりだと、この辺(から、少し発展させた流れ)。


https://corp.gmo-pg.com/newsroom/pdf/170501_gmo_pg_ir-kaiji-02.pdf

P16

通常、コードレビューは、

コーディングを担当していないメンバーで

実施

されるところ、

保険特約料支払

サイト

の開発では、オンライン部分の構築

を担当していた

メンバー

がコーディングをしつつ、自らコードレビューも行

っていた。また、

保険特約料支払

サイト

においては、

コードレビュー後

に、検証が十分に行えていなかったこともあり、結果的にセキュリティコー

ドが出力されることになった

*1


「自分でコーディングして自分でコードレビュー」ってあたりで色々と駄目感が漂う感じではあるのですが、じゃぁ「ほかの人がチェックしてたら気付けたんだろうか?」ってあたりで、一つ二つ。

で…まぁ今回は(できてなかったとはいえ)「コードレビュー」なので、「ほかの人がちゃんと読んでたらきっと気づいたんじゃないかなぁ」と好意的に考えたいところではあるのですが。


これが「ユニットテストによるチェック(と、ユニットテストコードのコードレビューっつかチェック)」だとすると。

ちょいと憂慮している可能性があって、そこについて、どうやってヘッジしていきましょうかねぇ? というあたりで、割と長々と、考えていたりしたので、思考整理かねてBlogってみようか、と。


例えば。それはもぉドドド簡単な関数ですが、以下の関数があって、それをテストしたいと考えます。


関数仕様

関数名は f_add

・引数は2つ。intを想定。処理は「二つの引数を算術加算した結果をreturn」

・引数の「int以外のケースのエラー処理」は未想定。stringなら「PHPのデフォルトの変換に従う」とかしておく


例えばPHPUnitだと、こんなテストコードになると思われるのですざっくりですが。

public function testHoge() {
    $this->assertSame(f_add(1, 0), 1);
    $this->assertSame(f_add(1, 1), 2);
    $this->assertSame(f_add('a', 'b'), 0);
}

これでテストコードが通れば、まぁとりあえず「実装はよいかなぁ」になるケースが多いのかなぁ、と思うのですが。

が。

が。


function f_add($i, $j) {
    if ( $i === 1 and $j === 0) {
        return 1;
    }
    if ( $i === 1 and $j === 1) {
        return 2;
    }
    if ( $i === 'a' and $j === 'b') {
        return 0;
    }
}

って実装になってたら、どうすんだべさなぁ??? っと。


上述は些か「わかりやすく駄目すぎるコード」ではあるのですが。

実際に、これに近いような「駄目」コードを拝見した記憶が全くないわけではないような記憶が闇と深淵の彼方にわずかばかりに確認されている事が否定しきれない事実でありまして*2

持ちろん「コードレビューしろ」って話にはなるかと思うんですが、「コードレビューしっかりしているうちはやらかさないんだけどだんだんコードレビューを薄くしていくと途端にやらかし始めるケース」なんてのも見受けられるわけでして……いやまぁぶっちゃけ「どうしたもんかなぁ?」と。


多分問題の根っことしては「"テストが通る事"は二次目標のはずなんだが一次目標としてとらえられて苦労するケースをどうするか(一次目標等は http://d.hatena.ne.jp/gallu/20101101/p1 参照)」ってあたりなんだろうなぁ、と。

で、これが「エンジニア間」であればまだ色々となんとかなりそうなのですが、発注側が「受け入れの検収タイミング」でこれに近い事をやらかされると「研修OK、いさ実際に使いだすと問題がじゃかすか」って話になって。

ここに「契約でがっちんがっちんに"テストが100%通る事"」になってると、発注側的に困るシーンもあるんじゃないかなぁ、などというあたりで、冒頭のPDF関連のお話にも少し絡んできそうな気がするわけですよ。


最終的にはまぁもちろん「受発注ともに、お互いとお互いのビジネスに敬意を払いましょう」ってお話にはなると思うのですが「払えない輩がいるからこその法的束縛」が必要なのですが……この辺って、どんなもんなんですかねぇ色々と。


なんてな事を、定期的に考えたり思案したりしています。

*1:しかし、よぉわからん改行が大量に入ってるなぁ……なんだべさ??

*2:要約:あった

2016-06-06

[][]「後で」っていつだろう?

ものすごく直近としては、teratailでの、とある質問(複数)&他の人の回答を見たあたりで


セキュリティ的にシャレにならんもんが書いてある

・一瞬、突っ込もうか悩む

・「否定的な返答の可能性」が脳裏に横切って、面倒なんで放置


ってのを大体脳内で1秒くらいでやりとりしたあたりが直近なのですが。

うんまぁネタ自体は「わりとあちこちに転がっている」ので。


割とよくあるのですが

・コード(設計)上の、(はっきり言うとかなり初歩的な)セキュリティホールを発見

・指摘

・「一端動かすのが大事なのです! セキュリティは後で直すのです!」という返答

という一連のやり取り。


指摘については「やんわり」から「がっつり」までバリエーション試してるので、多分どれでやっても一緒なんだろうなぁ、という印象値。

で思うのだけど「後でっていつよ?」


ちなみにいくつかの案件でみた「後で」のその後の経過って、大体ワンパターンで。


・初めは「一端動かすのが大事!」という理由でセキュリティドン無視

・サービスが動き出す

セキュリティを考慮するには、ある程度の工数が必要(な程度に汚い作りと設計になってる)

・「そんなコストは現在かけられない。あとで余裕がでたらかける」といってセキュリティ無視


って流れで固定。

まぁ「リスクが見えない人」にとって、セキュリティにかけるコストは無駄だわなぁ。


もちろん可能性とし「ちゃんと後日の修正コストを見越しての、設計とコーディングとスケジューリング」が出来ているところが0とは言わない。

でも、例えば「通信インタフェースの設計でミスってる」場合、そのレイヤーから修正するのって、かなり手間ぢゃない? って思うざますの。


根っこにあるのは「勉強不足」と「知識不足」。

その不足が「学習が足りない」のか「発展途上」なのかはまた別議論なんだけど。「学習が足りない」んなら正直「そのレベルで金もらって仕事すんな」って感じだし、発展途上なら「今このタイミングで学ぼうよ後回しなんてしないでさ」って思う。

それを「後で」って棚に上げる時点で、なんていうか「どんなもんなのかねぇ?」と。


なので。

セキュリティは一端無視」って言われた時点で、おいちゃんのプロジェクトでないのなら「あぁそうですか(微笑み)」で終了だし、おいちゃんのプロジェクトなら…多分、言った人間切って終わり、かなぁ(苦笑


以上、ふと思いだしたので、戯言程度に。

2015-03-16

[][]保全用

些か興味深いものがあったのですが、ちぃと魚拓の取りにくい感じなつくりになっていたので。

せめて「テキスト文書だけでも」と思い、保全。


ここの作り的に「改行が1つだと表示的に改行にならない」ので、改行文字だけちぃと増やしました。

具体的には


s/\n\n/\n\n\n/g


ってな感じのことをしました。

それ以外は一切いじってないです。


元ネタ

プライバシーポリシー

https://talentio.com/m/agreement/privacy

プライバシーポリシー

当社は、人材採用や人事管理など、人材に関する多様な事業を主力事業とする企業として、 個人情報・プライバシーを大切に保護することを当社の重要な社会的使命と認識しております。 役員及び従業者(以下「従業者等」といいます)は, 当社が事業で取り扱う個人情報・プライバシー関連情報及び当社従業者等の個人情報・プライバシー関連情報に関して、 個人情報保護に関する法令及び当社に関連する事業法の個人情報保護規定を遵守します。 また,当社は,常に社会的要請の変化に着目しつつ個人情報・プライバシー保護を徹底した事業運営を行います。

当社の提供する人材採用ツール「Talentio」(以下、「本サービス」といいます。)における個人情報の取扱いについて、 以下のとおりプライバシーポリシー(以下「本ポリシー」といいます。)を定めます。

個人情報の取り扱いについて


個人情報の定義について


個人情報とは、職業安定法(昭和22年法第141号)第4条第9項により定義された個人情報、すなわち、 「個人に関する情報であって、特定の個人を識別することができるもの (他の情報と照合することにより特定の個人を識別することができることとなるものを含む。)」を意味するものとします。

個人情報の利用目的について


当社は以下に掲げる利用目的のために個人情報を収集します。

(1)

本サービスの会員情報の認証、管理、事務連絡及び各種サービス機能を提供するため

(2)

当社と契約した事業者または求人企業に3.(4)の規定に従って情報を提供するため

(3)

当社がオンラインまたはオフラインで開催するセミナー及び各種イベント等の参加状況等,運営管理をするため

(4)

当社サービスに関するメールマガジン、その他告知情報を配信するため

(5)

アンケート、キャンペーン等の依頼、連絡、プレゼント発送等を行うため

(6)

ユーザーからの問い合わせ、質問に対する回答を行うため

(7)

当社及び第三者の商品等の広告・宣伝、販売の勧誘のため

(8)

本サービスに関する当社の規約、ポリシー等(以下「規約等」といいます。)に違反する行為に対する対応のため

(9)

本サービスに関する規約等の変更などを通知するため

(10)

上記の利用目的に付随する利用目的のため

当社が収集する情報


本サービスにおいて当社が収集する個人情報は、以下のようなものとなります。

(1)

個人ユーザー(当社の個人向けサービスに登録したユーザーをいいます。)から直接ご提供いただく情報

当社は個人ユーザーの皆様が本サービスを利用する際に、下記情報をご提供頂きます。

個人ユーザー本人の:

氏名

メールアドレス

生年月日

職歴、スキル、興味関心を含むキャリア情報

写真

その他当社が定める入力フォームにユーザーが入力する情報

(2)

個人ユーザーが本サービスの利用において、自ら,他のサービスと連携を許可することにより、当該他のサービスからご提供いただく情報

個人ユーザーの皆様が、本サービスを利用するにあたり、ソーシャルネットワークサービス等の 外部サービスとの連携を許可した場合には、その許可の際にご同意いただいた内容に基づき、 以下の情報を当該外部サービスから収集します。

当該外部サービスで個人ユーザーが利用するID(パスワードは含みません)

その他当該外部サービスのプライバシー設定により個人ユーザーが連携先に開示を認めた情報

(3)

企業ユーザーの皆様から収集する情報

当社は企業ユーザー(当社の法人等向けサービスに登録したユーザーをいいます。)の皆様が本サービスを利用する際に、 下記情報をご提供頂きます。

企業ユーザー担当者の:

氏名

メールアドレス

その他当社が定める入力フォームにユーザーが入力する情報

(4)

データ収集対象者から当社が収集する公開情報

本サービスではインターネット上で個人情報が公開されている個人(以下「データ収集対象者」といいます。)について、 インターネット上で公開されている情報の中で、下記の情報を収集します。 収集対象のウェブサイトにはソーシャルネットワーキングサイトを含みますが、 ソーシャルネットワーキングサイトでデータ収集対象者が公開対象を限定して公開している情報は収集対象に含みません。 また、当社がデータ収集対象者の公開情報を収集した後に、当該データ収集対象者が公開情報を変更し、または非公開とし、 もしくは公開対象を限定した場合、当社において保有している当該データ収集対象者の情報に反映されますが、 一定のタイムラグが生じます。

氏名

メールアドレス

生年月日

職歴、スキル、興味関心を含むキャリア情報

その他当社がサービスを向上させる目的で必要と判断する公開情報

本サービスに関する第三者提供(オプトアウト)について


当社は、当社が保有する個人データのうち、データ収集対象者の個人データを、本サービスの、 企業ユーザーのみが閲覧できるように設定したウェブサイト上に掲載する方法により、企業ユーザーの皆様に提供致します。 企業ユーザーの皆様には利用規約上の個人情報に取扱いに関する事項にご同意頂いております。

データ収集対象者の皆様からお申し出頂いた場合には、ただちに提供を停止致します。 個人データの提供の停止を希望される場合は、次の連絡先までご連絡下さい。


【連絡先】

住所:東京都渋谷区神宮前2-33-16

メールアドレス:info@talentio.com

その他の第三者提供について


当社は、個人情報のうち、個人情報については、 上記3.及び個人情報の保護に関する法律(平成15年法律第57号,以下「個人情報保護法」という。) その他の法令に基づき提供が認められる場合を除くほか、あらかじめユーザーの同意を得ないで、第三者に提供しません。

個人情報の委託について


当社は事業運営上、業務委託先に個人情報の取り扱いを委託することがあります。 この場合、当社は、個人情報を適切に保護できる管理体制を敷き実行していることを条件として委託先を厳選したうえで、 契約等において個人情報の適正管理、機密保持などによりユーザーの個人情報の漏えい防止に必要な事項を取決め、 適切な管理を実施させます。

第三者による個人情報の取扱いに関する免責事項


以下の場合は、第三者による個人情報の取扱いに関し、当社は何らの責任を負いません。

(1)

ユーザー自らが本サービスの機能または別の手段を用いて事業者、求人企業等の第三者に個人情報を明らかにした場合

(2)

ユーザーの活動情報またはユーザーが本サービスの利用に関して投稿等した情報により、第三者にユーザー本人が特定されるにいたった場合

(3)

本サービスからリンクされる外部サイトにおいて、ユーザーにより個人情報が提供され、またそれが利用された場合

(4)

ユーザー本人以外がユーザー個人を識別できる情報(ID,パスワード等)を入手した場合

ユーザーの追加情報の取得について


当社は、当社の事業の円滑な運営の目的で、当社がユーザーの個人情報を提供した事業者から、 内定の事実、入社予定会社、入社予定日、予定年収その他本サービスの利用に関するユーザーの追加情報を取得することがあります。

統計処理されたデータの利用


当社は、提供を受けた個人情報をもとに、個人を特定できないよう加工した統計データを作成することがあります。 個人を特定できない統計データについては、k-匿名化や適切な一部抽出(サンプリング)等の手法を用いて作製することとし、 公表または第三者提供を行う場合は、個人情報が含まれていないことを確認することと致します。

本人確認について


当社は、ユーザーの会員登録の場合や会員が本サービスを利用する場合、 個人情報の開示、訂正、削除もしくは利用停止の求めに応じる場合など、 個人を識別できる情報(氏名、電話番号、メールアドレス、パスワード等)により、本人であることを確認します。 ただし、本人以外が個人を識別できる情報を入手し使用した場合、当社は責任を負いません。

特定個人を識別しないで用いる属性情報・行動履歴の取得及び利用について


当社は、ユーザーのプライバシーの保護、利便性の向上、広告の配信、及び統計データの取得のため、Cookieを使用します。 また、当社はCookieやJavaScript等の技術を利用して、会員登録時等にご提供いただいた情報のうち年齢や性別、職業、 居住地など個人が特定できない属性情報(組み合わせることによっても個人が特定できないものに限られます)や、 サイト内におけるユーザーの行動履歴(アクセスしたURL、コンテンツ、参照順等)を取得することがあります。 これらの属性情報及び行動履歴を個人情報に紐付けることはせず,紐付け可能な形で取得することはありません。 なお、Cookieの受取りは、ブラウザの設定によって拒否することができます。拒否した場合本サービスをご利用頂く上で、 一部機能に制約が生じることがあります。

個人情報の開示


当社は、ユーザーから、個人情報保護法の定めに基づき個人情報の開示を求められたときは、 法令に従って、ユーザーご本人からのご請求であることを確認の上で、ユーザーに対し、遅滞なく開示を行います (当該個人情報が存在しないときにはその旨を通知いたします。)。 なお、個人情報の開示につきましては、手数料(1件あたり1,000円)を頂戴しておりますので、あらかじめ御了承ください。

個人情報の訂正及び利用停止等


(1)

当社は、ユーザーから、 (1)個人情報が真実でないという理由によって個人情報保護法の定めに基づきその内容の訂正を求められた場合、及び (2)あらかじめ公表された利用目的の範囲を超えて取り扱われているという理由 または偽りその他不正の手段により収集されたものであるという理由により、 個人情報保護法の定めに基づきその利用の停止を求められた場合には、法令に基づき、 ユーザーご本人からのご請求であることを確認の上で遅滞なく必要な調査を行い、その結果に基づき、 個人情報の内容の訂正または利用停止を行い、その旨をユーザーに通知します。 なお、合理的な理由に基づいて訂正または利用停止を行わない旨の決定をしたときは、ユーザーに対しその旨を通知いたします。

(2)

当社は、ユーザーから、ユーザーの個人情報について消去を求められた場合、当社が当該請求に応じる必要があると判断した場合は、 法令に基づき、ユーザーご本人からのご請求であることを確認の上で、個人情報の消去を行い、その旨をユーザーに通知します。

プライバシーポリシーの変更手続


当社は、ユーザーに関する情報の取扱いに関する運用状況を適宜見直し、継続的な改善に努めるものとし、 必要に応じて、任意で本ポリシーを変更できるものとします。この際、重要な変更が含まれる場合には、ユーザーに個別に通知を行います。 又、本ポリシーの変更履歴は、変更部分が分かる形で公開します。

お問い合わせ窓口


ご意見、ご質問、苦情のお申出その他ユーザー情報の取扱いに関するお問い合わせは、下記の窓口までお願い致します。


住所:〒150-0001 東京都渋谷区神宮前2-33-16

ハッチ株式会社

E-mail:info@talentio.com

(C) Copyright 2015 Hatch Inc All Rights Reserved.