スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/05:27 [PR] |
08/01/15:32 パスワードを一方向暗号化しても簡単なパスワードを使っていたら意味がない皆さんは、DBにパスワードを格納する時、暗号化していますでしょうか?
基本的に特殊な要件が無い限りは、一方向の暗号化をすべきです。 どうしても、要件的に復号できる必要がある場合は、仕方が無いので復号可能な暗号化を用いましょう。 ITリテラシがないユーザーが直接データベースに入ってパスワードを書き換えることがあるケース等本当に稀なシーンにおいては平文で保存するということがあるかもしれません。 セキュリティの強度としては 1 1方向暗号化のパスワード 2 復号可能なパスワード 3 平文 という順になるかと思います。 さて、それでは、1方向の暗号化さえしておけば安心でしょうか? 実はそうではありません。 例えば、次の3つのmd5 hashされたパスワード、なんだか既視感ありませんでしょうか? たまにテスト環境とかで見かけますね。 (a) 21232f297a57a5a743894a0e4a801fc3 (b) 098f6bcd4621d373cade4e832627b4f6 (c) 5f4dcc3b5aa765d61d8327deb882cf99 これらの元となるパスワードは、それぞれ (a) admin (b) test (c) password になります。 一方向なのになぜわかったのか。 【答え】 メジャーなものはググれば出て来ます。 そうで無いものも世の中には暇な人がいるので地道に変換して辞書を作っている人がいます。 簡単なパスワードを使っていると、md5で一方向で暗号化されたところで、これではあまり意味がありませんね。 ん? DBの中身が見れている時点で元のパスワードなんてどうでも良い? そうですね。確かにそのアプリについてはその通りでしょう。 でも、本当に怖いのはそこから先なのです。 皆さん、世の中のいろんなアプリで当然パスワードは毎回違うものを使っていますよね?「いつものやつ」なんて言って使い回していないですよね? もしも使い回していたら、大変です。 その中の一つがハックされれば、その他のアプリについても同じパスワードを用いてアクセスが可能になってしまう可能性があります。 最近はログインIDをemailにしているアプリも多いですね。 そしたらIDを特定する負担も減るのでよりやりやすくなりますね。 もしも、そのemail自体のパスワードが「いつものやつ」を使っていたら最悪です。 たまたま慎重にパスワードを「いつものやつ」とは異なるもので登録していたアプリも、メールを利用したパスワードの再発行機能などでパスワードをリセットされてしまいます。 ということで、パスワードにはいろいろと気を使う必要がありますね、という話。 【追記】 次の記事で「正確には暗号化とメッセージダイジェストは異なる」という話を書いてます。
PR
|
07/20/13:45 その案件は本気でとりに行くべきかどうか?ある日会社にシステム開発を依頼したいという一本の電話がかかってきました。
案件にもいろんな種類があります。 電話を受けたあなたの頭にはこんな疑問が湧いていることでしょう。 その案件は本気でとりに行くべきかどうか? まず、大前提を書いておきます。 答えは 「はい。本気でとりに行くべきです。当たり前です。 せっかく弊社に興味をもってご連絡いただいた貴重なお客様です。 なんとかして気持ちに応える(結果として受注する)ための最大限の努力をするのは当たり前です。」 さあ、以上の当たり前の結論を先に書いておいて、ここから仮の話をいたします。 もし、超売れっ子になり、お客様が長蛇の列をなすようになったら、その時はどうしても選択しなければなりません。 その時どのように判断すれば良いでしょうか? 今日はファイブフォース分析というのをご紹介します。 マイケル・E・ポーターの名著「競争の戦略」で紹介されている分析方法ですね。 本来は産業構造を分析して、その分野に進出するかどうかなどを判断するためのものです。 規模は全然違いますが、それを案件を取りに行くべきかどうかという問題に応用してみます。 ファイブフォースとは以下の5つを指します。 記憶を頼りに書くので、正確な表現ではないかもしれません。 1.新規参入者の脅威 2.代替品の脅威 3.買い手の交渉力 4.売り手の交渉力 5.競合他社との関係 このうち上の2つは外部要因、下の3つは内部要因とか言われます。 さて、ここで具体例を挙げて考えてみましょう。 ECサイトをフルスクラッチで構築したいという案件だったとします。 1.新規参入者の脅威 まず、この案件にたいする参入障壁がどの程度か考えます。 ECサイトであれば、カート機能など少なくとも動的なページを出力する必要があります。 よって、プログラムを扱えるかどうか、という参入障壁があり、静的なページしか作れないWebコーダーなどは参入できません。 また、クレジットカードの決済が必須であれば、何かしらの方法で決済の仕組みを取り込める技術が必要です。 逆に、発注はメールフォームでOKとかであれば、参入障壁は下がりますね。 2.代替品の脅威 今回、ECサイトをフルスクラッチで構築したいということですが、場合によっては、楽天に出店するだけだったり、そもそもオークションサイトなど既存のサービスの利用で目的を達成できる可能性もあります。そういった代替品について考えてみます。 また、フルスクラッチではなくオープンソースのインストールだけでECサイトを作る業者のサービスも代替品と言えます。 3.買い手の競争力 例えば、クライアントが何度もECサイトを立ち上げている経験やITリテラシーがあり、また、東京などの大都会で、多数の業者から見積もりをとれる状況などあれであれば、買い手の交渉力は高く、弊社としては高い単価では通しにくいと言えます。また、逆に、クライアントが僻地に存在し、開発会社など近くにひとつもないような状況であれば、買い手の交渉力は低く、高い単価でも通る可能性が高いです。 4.売り手の交渉力 これは、つまりPGの調達の話です。例えば、その案件の要件として特殊な開発言語を使用することが明示されているとします。そうすると、なかなかPGを見つけることが難しいです。そのような場合は、売り手の交渉力が高く、コストを下げることが難しいと言えます。逆に、PHPなど開発者人口が多い言語を選べるのであれば、売り手の交渉力は低く、コストを下げやすいと言えます。 5.競合他社との関係 例えば、クラウドワークスのような、多数の競合と敵対するのか、3社コンペなどのように最初から絞られた中での戦いなのか、などについて考える必要があります。競争が激しい方が、コストもかかり、利益も上げにくいことになります。情報があれば、コンペ相手が、バッケージメーカーなのスクラッチ開発会社なのかにより戦い方を変えたりします。 以上が「ECサイトをフルスクラッチで構築」という案件についてファイブフォース分析をしようとした場合の観点の一例です。 競争が激しくなく、自社が競争優位に立てる案件を選ぶのが良いです。 参入する前の戦略的なフェーズで選択を間違わなければ、参入後の戦術レベルのところで苦労をすることは減ります。 戦略レベルの失敗は、なかなか、戦術レベルで取り戻すことは難しいです。 さて、最後に大事な前提のおさらいです。 これは、あくまで、お客様が長蛇の列をなしていてどうしても選ばなければならないとき、という仮定の話です。 現実で選り好みをすると・・きっと、社長に怒られます(笑)
|
07/04/16:30 vagrant boxで何度もスクリプトをテストしたいなら最近、chefとかサーバーの管理(構築)を自動化するのが流行っていますね。 で、それぞれの形式に合わせてスクリプトを書いたりすると思いますが、いきなり本番サーバーに適用する人はいませんね。 まずは、ローカルの仮想サーバーでテスト、とするのが普通かと思います。 私は、packerで自分で作ったvagrantのboxをベースにいろいろと試しています。 で、まっさらな状態でスクリプトのテストしたいなら、不要なboxをvagrant destroyとかで一旦削除して、再度vagrant upで仮想サーバーを作成すればよいですね。 でも、実際にchefとかで一歩一歩スクリプトを書いては実行というのを繰り返したい時に何もテスト済みの最初のコードから実行する必要はありませんね。最終的には頭から流し直すにしても。 そんな時に便利なvagrant pluginの紹介です。 vagrant plugin install sahara これでsaharaというvagrant pluginがインストールされます。 使い方は超カンタン 今の状態まで何かあったらrollbackしたいというタイミングで vagrant sandbox on コマンドを打てばOK。 実行結果を永続的に反映したいなら vagrant sandbox commit 実行結果をロールバックしたいなら vagrant sandbox rollback とすれば良いですね。 試行錯誤するsandboxモードから抜けるには vagrant sandbox off とすれば抜けられます。 とてもシンプルですが強力ですね。
|
06/20/19:14 思考のスピードで何かを表現することはできないふと思った。 思考のスピードで何かを表現することはできない。 例えば、画面設計。 画面設計も手書きであれば、1画面2分もあればできる。 問題は、それで出来上がった設計はあくまで設計者の頭の中だけであって、 それを伝えるには何倍もの時間が必要ということ。 そもそも私の場合、手書きの文字は読めない・・という問題が・・・ある。 昔から、数学の宿題で指された時は、 ノートのぐにゃぐにゃした文字を眺めるフリをしながらその場で考えて黒板に書いてた。 ただ、仮に、私の字がとても綺麗だったとしても、 考える作業と、伝えるための作業は別にするのが良いと思う。 そもそも作業の目的が違う、目的が違えば使うツールや手段も違う。 集中して考えるときは、フリーハンドで象形文字みたいなものをぐにゃぐにゃ描くのが良い。 学生時代はA3の画用紙ノートが大好きだった、それを豪快に使ってどんどんページを切り替えながら書いていく。 で、ある程度(30分くらい)集中して考えたら、あとは頭の片隅にその問題を追いやって、良い考えがふとした瞬間に湧いて出るのを待つ。アイデアを出す時には、工数よりも期間を重視する。つまり、同じ3時間でも、集中して3時間考えるより、1日1時間を1日おきに3日やった方が良いアイデアがでる。 逆に、手を動かす作業は、一気に集中して作業する。その方が、ワーキングメモリーを有効活用できて効率が良い。 大人になって思うことは、きっと、仕事は、考える作業は1割くらいで、仕事の9割くらいは伝えるための作業なんじゃないかということ。 そして、伝えること、表現すること、って結構難しい。 今日は(も?)オチのない話。
|
06/16/13:23 CentOS7でifconfigとかnetstatとか使いたいなら皆さん、CentOS 7 使っていますか?
私も個人で使ったり、最近では仕事でセットアップしたり、chefの勉強で仮想環境で触ったりしています。 CentOS 7になって、名前が変わったコマンドがいくつかありますね。 ifconfigとかnetstatとか打ってもそんなのないよと怒られますね。 まだまだCentOS 6時代の記憶が鮮明すぎて、CentOS 7のコマンドなんてすぐにでてこないこともあります。 そんなあなたは、とりあえず、 yum install -y net-tools ということで、net-toolsというパッケージをインストールしておけば、 ifconfigとかnetstatとか使えるようになりますね。 まぁ、これらは廃止予定なので、使わないほうが良いんです(当たり前です)。 でも、人生の時間は1日24時間しかないので、機会がないとなかなか本気で覚える気になりませんね。 私も以前突然相談されたときにそのサーバーがCentOS7で、ヤバ、IPアドレス確認すらできない・・・とパニクったことがあります。(かっこ悪かったですね) ということで、今日は非推奨な逃げ道のご紹介。 近々、ちゃんと整理して覚えよう・・・
|