Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog
追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー
パスワードのハッシュに使うべきPBKDF2、Bcrypt、HMACの各言語実装一覧 - このブログはURLが変更になりました
いつも忘れるのでメモ。 元ネタ:Are you sure SHA-1+salt is enough for passwords? 日本語訳:「SHA-1+salt」はパスワードに十分だと思いますか？ こうしたスキームをいくつか選ぶことができる： PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 Bcrypt http://www.openwall.com/crypt/ HMAC http://en.wikipedia.org/wiki/HMAC 各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。 ということで、各言語での実装を調べてみた。実装が正しいかは調べてない。別実装もあるかもしれない。 言語 PBKDF2 Bcrypt HMAC Java Bouncy Castl
パスワード保存とソルトの話
先日、twitterへのハッキング行為が発見された、という発表がなされました。一部のユーザのデータが漏洩したということです。 この件について個人的に懸念を感じたため、それをこちらに書いておきました。原文では encrypted/salted password と呼ばれていたものが、日本語の公式ブログでは「暗号化されたパスワード」となり、これが朝日新聞では「パスワード」と表記されているという問題です。 専門知識があれば、ここにどういう違いがあるかはわかるのですが、そうでなければわからないのも無理はありません。しかし、わからないからといって省略して良いわけでもありません。パスワードと encrypted/salted password は大きく異なります。 ではどう違うのか？ この話について、ひと通りの解説をしてみるのも良いのではないかな、と思ったのでしてみます。 「パスワード」は保存されない
PBKDF2によるパスワード暗号化の手順
会員制ウェブサイトのように、ユーザからのパスワードを保存するシステムでは、必ずパスワードを暗号化して復元できないようにして保存しなければなりません。なぜなら、もし情報漏洩が起こったときにユーザのパスワードが漏洩してしまったら、他のウェブサイトなどへも侵入され、致命的な結果につながりえるからです。 もしあなたが技術者でなくても、技術者や外注先にたいしてパスワードの暗号化保存を要件に入れるべきです。そのときはこの記事をお見せください。 (もちろん全てのウェブサイトで使うパスワードを変えるのが望ましいでしょうし、もし可能ならパスワードに頼らないハードウェアトークンによる認証などの強力な仕組みを採用するのが良いのでしょうが、現状では皆がそこまでできていないのが現実かと思います。) これまでですと、パスワード保存にはSHA1やMD5のハッシュ関数の適用などによって暗号化していることが多かったかと思い
受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
GPLにおいて納品は頒布ではない？ - uehaj's blog
いままで、GPLソフトウェアを改変／拡張もしくは利用の対象としたプログラム製造請負契約において、その成果物の「納品」は、GPLの「頒布」に該当すると思ってました。つまり、頒布を行わなければ生じないGPLの義務（ソース公開義務その他）は、納品時にも課されると。 このことは、受託開発業務ではとても重要な話です。 しかしながら、IPAからダウンロードできる「GNU GPLv3 逐条解説書」には以下のようなことが書いてあります。 44ページ目 例えば、企業Aがシステム開発会社Bに、他者(GPLv3 プログラムのライセンサ)が開発 し公開しているGPLv3 プログラムCの改変等の作業を委託し、その成果物C’を納品させる場 合、第 0 条第 7 パラグラフの定義によれば、上記の目的で当該プログラムC・C’を A・B間 で授受する行為も、コンベイに相当すると解される。したがって、A及びBは、GPLv3
お前このサブネットでも同じ事言えんの？ - 知らないけどきっとそう。
,、,, ,、,, ,, ,, _,,;' '" '' ゛''" ゛' ';;,, （rヽ,;''"""''゛゛゛'';, ﾉｒ） ,;'゛ i ＿ 、＿ iヽ゛';, ,;'" ''| ヽ・〉 〈・ノ |ﾞ゛ `';, ,;'' "| ▼ |ﾞ゛ `';, ,;'' ヽ＿人＿ / ,;'_ ／ｼ、 ヽ⌒⌒ / ﾘ ＼ | "ｒ,, ｀"'''ﾞ´ ,,ﾐ゛ | | ﾘ、 ,ﾘ | | i ゛ｒ、ﾉ,,ｒ" i _| | ｀ー――----┴ ⌒´ ） （ヽ ＿＿＿＿＿＿ ,, ＿´） （_⌒ ＿＿＿＿＿＿ ,, ィ 丁 | | | 前回のエントリ で軽く触れましたが、ARPスプーフィングを用いると、サブネット内からデフォルトゲートウェイを通って外に出て行くはずのパケットを、自分のホ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
