パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
【FuelPHP】疑問から始まってコアにマージされるまでの話。
FuelPHPで疑問に思ってソースを読んで追加してみて動作確認して、 プルリクエストを投げてマージされるまでのお話です。 複数データベースをまたぐ分散トランザクション処理を行いたい場合、どう書けばいいのか悩んでいました。 XAトランザクション？ 2相コミット？ PHPではあまりそういった実装を見たことがない。。。 一応こんなのもあるけど ibase-trans // 動くけど微妙な気がするコード // これで本当にACID特性が満たされるのか・・・ try { \DB::start_transaction('database1'); \DB::start_transaction('database2'); // database1に対するCURD操作 // database2に対するCURD操作 \DB::commit_transaction('database1'); \DB::comm
データベースを使った自動テストについて
データベースを使った自動テストについて データベースを使った機能テストや単体テストについて要点をまとめておきます。 筆者の経験を強く反映していますので比較的定性的な内容となります事を予めご了承下さい。 テストデータを保守する テストの実行前に投入するテストデータは、凡そcsvファイルやxmlファイル、エクセルファイル等で管理する事になります。 仕様の変更に伴いテーブルの定義を変更する事で、それらのファイルの内容とデータベースの間に不整合が発生します。 テーブル定義の変更とテストデータの保守は常にまとめて作業するべきです。 これは同じ作業者がやるべきという事ではありませんが、ほぼ同時期に行われるべきです。 RDBを使っている場合、ExcelやAccessといったデータベースにODBC接続し易いツールを使うとデータを作り込み易いのですが、 テストデータを長期間に渡って保守する事を考えると、 テ
解析まで10分！最強のMySQLチューニングツール「Jet Profiler」 - Lancers開発ブログ
こんにちは、keiです。 今回は、MySQLのチューニングに大活躍な「Jet Profiler」というツールをご紹介します。 Jet Profilerとは Jet Profilerは、MySQL向けのクエリアナライザです。 クエリチューニングは、DBパフォーマンスチューニングの中でも重要な作業の1つですが、 Jet Profilerを使えば、その作業をGUIで直感的に行うことができます。 フリーウェアの形態で提供されており、機能限定版であれば無料で利用することができます。 購入する場合は、$499となります。 詳細情報、ダウンロードは公式ページからどうぞ。 http://www.jetprofiler.com/ja/ Jet Profilerの魅力 その1 導入のしやすさ 通常のWindowマシンに、普通のアプリケーションをインストールする感覚でインストールが可能です。 イン
FuelPHP での Migration の使い方 (2) - A Day in Serenity @ kenjis
FuelPHP での Migration の使い方 で説明されていない項目について補足します。 デフォルト値を設定する フィールドの指定に default[デフォルト値] を追加します。 $ oil g migration create_table1 title:string[50]:default[abc]生成されるファイルは以下のようになります。 <?php namespace Fuel\Migrations; class Create_table1 { public function up() { \DBUtil::create_table('table1', array( 'id' => array('constraint' => 11, 'type' => 'int', 'auto_increment' => true), 'title' => array('constraint
インストーラの作り方調査 - 趣味の延長線
インストーラを作りたい。 できれば、サーバにソースをアップロード→ブラウザアクセス、一部データ(管理ID,パスワードなど）を入力→実行 で、できるだけ全てが済むようなインストーラを。 基本的なインストーラの作り方の一例を記載した記事を見つけたので、読解しつつ、ポイントまとめ。 Writing an installer for your CakePHP application - cakebaker 上記記事の内容を踏まえて見ると、CroogoやCandyCaneインストーラが、割と容易に理解できました。 基本インストーラについて フロー要約 1. route.php：app/tmp/以下に”インストール済み”目印のファイルがない場合、以下のinstallerコントローラ実行 2. indexアクション：特に処理なし。インストール開始メッセージ＆ボタンでも表示するか？ 3. database
AndroidアプリにおけるDBファイルの正しい使い方
はじめに Androidアプリケーションを作成する上でSQLiteを使用してデータベースを扱うことは多々あります。データの永続化や検索といった処理を容易に実装することができるので、多くのアプリケーションで使用されています。しかし、AndroidにはSQLiteを使用するための方法が以下のようにいくつか用意され、それぞれファイル作成時のパーミッションの挙動が異なっています。 SQLiteDatabase#openOrCreateDatabaseを使用して作成する Context#openOrCreateDatabaseを使用して作成する SQLiteOpenHelperクラスを使用して作成する もし、開発者がこれら方法の挙動を十分に理解していない場合、知らずのうちに脆弱性を作り込んでしまいます。 実際に、いくつかのアプリケーションではSQLiteDatabase#openOrCreateDa
index.rb [nofuture.tv]
この項目はまだ作成されていません。もし、文書作成の権限がある場合は、文書の作成をクリックして最初の文書を作成することができます。
グーグルがNoSQL軽量ライブラリ「LevelDB」をオープンソース化。SQLiteとの比較ベンチマークも公開
グーグルがNoSQL軽量ライブラリ「LevelDB」をオープンソース化。SQLiteとの比較ベンチマークも公開 キーバリュー型データストアは、いわゆるNoSQLデータベースの代表的な種類の1つ。LevelDBは以下のような特徴を備えています。 基本的な操作は、Put(key,value), Get(key), Delete(key) 1つのトランザクションとして複数の変更操作が可能 データは自動的に圧縮し保存される SQLite、Kyoto TreeDBとの比較ベンチマークも LevelDBはC++で書かれたライブラリで、今後のChromeブラウザのIndexedDBはLevelDBで実装されると説明されています。 Upcoming versions of the Chrome browser include an implementation of the IndexedDB HTML5
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL - GnuCash
SQLで木と階層構造のデータを扱う――入れ子集合モデル