パスワードを決める画面でのアホなルールを集めたリポジトリ dumb-password-rules | 秋元@サイボウズラボ・プログラマー・ブログ
dumb-password-rules/dumb-password-rules パスワードの登録や更新画面で出てきたおかしな制約やエラーを募集している GitHub リポジトリがあります。 あほなパスワードの文字制限を分類 多数の事例が載っていますが、代表的なものをグループ化してみます。 文字種や記号を謎に制限 「% は使えません」「\ は使えません」 – 内部でエスケープしちゃうんですねわかります。ちゃんと作ってあればこんな特例要らないと思うんですが。 「記号で使えるのは ? ! $ €% & * _ = – +. ,:; / () {} [] ~ @ # だけです」 「記号はアンダースコアとハイフンだけ使えます」 「数字や記号は使えません」 「使える記号がありますが、どの記号が使えるかは秘密です」 「パスワードは5-15文字です(が、スペースは文字数としてカウントしません)」 「パスワ
ゼロ幅文字にエンコードした隠し情報で、文書をリークしたメンバーを特定 | 秋元@サイボウズラボ・プログラマー・ブログ
とある会員制掲示板からの文書の流出に困った運営者が、ユニコードの見えない文字「ゼロ幅文字(Zero-Width characters)」を使って流出させたユーザーを特定した、という話が出ていました。 数年前の話、Tom さんが所属していた競技ビデオゲームのチームでは、ログインが必要なプライベートの掲示板を使って連絡していました。その掲示板に書かれた秘密情報や戦術に関する重大アナウンスなどがしばしば掲示板外のウェブにコピペされ、チームにとって大きな問題となっていたそうです。 外部ユーザーの攻撃で中身が漏れたというよりは、メンバーの誰かがコピーしているのでは、と考えた Tom さんは、当時気になっていたユニコードのゼロ幅文字を使ったトリックを仕掛けたそうです。 ユーザーを特定する情報を、見えない文字に変換して埋め込む ログイン中のログインユーザーのユーザーIDを、一定のルールによってゼロ幅文字
cybozu.com を真に常時 SSL にする話 - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。 今回は cybozu.com を安全に利用するために暗号化した通信（SSL）を常時使用するための取り組みを紹介します。 HTTP と HTTPS HSTS とその弱点 Preloaded HSTS Chrome のリストに cybozu.com を組み込む まとめ HTTP と HTTPS Web ブラウザのアドレスバーに "www.cybozu.com" と打ち込むと、通常は暗号化されない HTTP 通信が行われます。そこでまず考えられるのは、Web サーバーにて HTTP 通信を受け付けたら、HTTPS に永続的リダイレクトをすることです。Apache なら以下のような設定になるでしょう。 <VirtualHost *:80> ServerName www.cybozu.com Redirect permanent / https://www.c
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
Kazuho@Cybozu Labs: アクセスログからアテンション（注目情報）をデータマイニングする手法について
多数のユーザーの行動記録からアテンション情報（注目されているデータが何か）をデータマイニングしたいというのは、大量のデータを扱っているウェブサイトにおいては自然と出てくる要求です。そこで、先月末にサービスを終了したサービス「パストラック」において使用していた、アクセスログから注目度（人気度）の高いウェブページや人名等のキーワードを抽出するためのアルゴリズムを紹介しておきたいと思います。 たとえばはてなブックマークのような、ユーザーの能動的な行為（「ブックマークする」という作業）から注目情報を抽出するのは決して難しいことではありません。それは、直近の一定期間内のブックマーク数＝注目度、という前提が上手に機能するからです。現に、はてなブックマークの人気エントリーは、最近24時間程度の期間内にブックマークしたユーザー数の多い URL を降順で並べているように見受けられます。 しかし、アクセスログ
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
Kazuho@Cybozu Labs: Apache で X-Reproxy-URL ヘッダを使えるようにするモジュール mod_reproxy を書いた
ウェブアプリケーションにおいて、認証がかかっている画像や大きなファイルを配信する場合には、Perlbal 等でサポートされている X-Reproxy-URL ヘッダが有効なことが知られていて、その理由としては、 (メモリを大食いする) アプリケーションサーバのプロセスを転送終了まで占有しない HTTP ベースの分散ファイルシステムとリバースプロキシが直接交信するので、ネットワーク負荷が低い といった点が挙げられます。「でも、Apache は X-Reproxy-URL ヘッダをサポートしてないんだよねー」という話が、先日の YAPC::Asia 2009 においても話題になっていました[要出典]。回避策としては、ワンタイムURLのような手法もあるのですが、セキュリティな懸念もあります。 なんとかしたいなと思っていたのですが、気が向いたので、Apache に X-Reproxy-URL ヘッ
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
