何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた
2021.02.16 「私はロボットではありません」はワンクリックでなぜ人間を判別できる？ 仕組みとその限界を聞いてきた WebサイトにIDとパスワードを入力するとき、ときどき「私はロボットではありません」にチェックを求められることがあります。 僕はロボットではないので、当然チェックを入れて認証を進めるわけですが……。でもちょっと待ってください。なぜクリックひとつで、人間かロボットかを判断できるんでしょう。 これはきっと、人間ではないなんらかの不正アクセスを防ぐ仕組みのはず。でもチェックを入れるくらい、プログラムを作ってなんやかんやすれば、シュッとできるのでは？ 「私はロボットではありません」は、どんな仕組みで人間とロボットを判別しているのか。もっといい方法はないのか。これまでの歴史的経緯も含め、情報セキュリティ大学院大学の大久保隆夫教授に聞きました。 気づかないうちに「人間かロボットか」
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策：徳丸浩氏が8つの試練を基に解説（1/3 ページ） ECサイトやWebサービスでセキュリティインシデントを起こさないためには何をすればいいのか。2019年12月に開かれた「PHP Conference Japan 2019」で徳丸浩氏が、架空企業で起きたセキュリティインシデントを例に、その対策方法を紹介した。 ECサイトやWebサービスを提供する会社で発生したセキュリティインシデントに関するさまざまなニュースが後を絶たない。どうすればこうしたインシデントは防げるのだろうか。 『体系的に学ぶ安全なWebアプリケーションの作り方』（通称：徳丸本）の筆者として知られる徳丸浩氏（EGセキュアソリューションズ 代表取締役）は、2019年12月に開かれた「PHP Conference Japan 2019」のセッション「オニギリペイのセキュリ
ゲームでよくされるチート手法とその対策 〜アプリケーションハッキング編〜 - Qiita
ゲーム、特にソシャゲ、ネトゲにおいて様々なハッキング(チート)が実際に行われます。 大きく分類すると、アプリケーションハッキング(クライアントサイドでのハッキング)とネットーワークハッキング(サーバーへのハッキング)とその他のハッキングがあります。 多くはエンジニアがよくやらかすバグであったり、知識(経験)不足を狙ってくるものです。 今回は内容のボリュームの関係上、アプリケーションハッキングについてのみ、実際によく行われるチート行為やその方法、対策などについて中心に挙げていきたいと思います。 ボタン連打 何が起こる? コスト(課金石など)を払うことなく無限にアイテムが増殖する。 やり方 上記のような「ボタン」を連打する。 データベースの排他制御(トランザクション + ロック)を行う。 連打ができないように一度ボタンを押したら処理が完了するまで押せないようにする。 具体例・解説 1.について
誰にでも分かる易しい情報漏洩のしかた - 基礎編 - Crieit
Webサービス上にてユーザーの名前を表示したい場合、例えばPHPのLaravelであれば下記のようにして表示します。 お名前：{{ $user->name }} データをMySQLから取得後、メモリ上にはTwitterのトークンなどが存在しますが、ここではテンプレート上で名前しか表示していないので問題はありません。わざわざトークンを表示する、ということもないと思うのでこういった場合には問題になりません。 ユーザー情報をAPIで取得する場合 最近はフロントエンドとバックエンドが分かれることが多くなり、直接テンプレート上に表示する形ではなく、バックエンドから情報をJSON形式に変更してフロントエンドに伝える、という形が多くなりました。 例えばユーザー情報をPHPのjson_encodeでJSONに変換すると、下記になります。 { "id": 154, "name": "taro", "twit
HTTPS通信時のURLは暗号化されるか - うまいぼうぶろぐ
2018/06 追記 古い記事ですがちょこちょこアクセスいただいているので更新。 最近は常時SSL、IPv4枯渇、CDN導入などの理由でSNIが良く使われるようになってきていますが この場合、ホスト名(URL全体ではない)は平文で送信されます。 client 側でキャプチャしたパケット curl -k https://sni.example.com/hogehoge $ sudo ngrep -d en3 -q -W byline port 443 and host 192.0.2.1 interface: en3 (192.168.6.0/255.255.255.0) filter: (ip or ip6) and ( port 443 and host 192.0.2.1 ) T 192.168.6.108:55460 -> 192.0.2.1:443 [AP] ...........
HTTPメソッドGetで個人情報送ってもいいんじゃないの？ - Qiita
タイトルの内容を思ったきっかけは社内勉強会で体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践を読んだことでした 改めてなぜダメなのかと言われるとしっかり根拠を持って説明できないなと思い調べてみました Getでもいいのかなと思ったパターンは以下のようなケースです 例えば、会員登録機能などで確認画面から戻るボタンで入力フォームに遷移する場合に、入力した内容をそのまま保持したままにしたい。その際にはHTTPSの場合であればGetで戻っても大丈夫なのかな？ GetとPostの使い分けはどういう場合？ GetとPostの使い分けは以下のようなケースの場合で考えればいいようです Getメソッドは参照（リソースの取得）のみに用いる Getメソッドは副作用がないことが期待される 秘密情報の送信にはPOSTメソッドを用いること 引用：安全なWebアプリケーションのつくり方
アクセストークンに有効期限を設けるべきかどうか - Qiita
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
JWT形式を採用したChatWorkのアクセストークンについて - ChatWork Creator's Note
JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった
徳丸浩の日記: ECサイトからクレジットカード情報を盗み出す新たな手口
エグゼクティブサマリ 聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。 はじめに 今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。 「ＳＯＫＡオンラインストア」の件 このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い たしました。 http
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
WEBAPI利用時のアプリケーションID隠匿について
JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「パスワードの送信にURLクエリパラメータを使ってはいけない」のは何故か？
SSL Server Test (Powered by Qualys SSL Labs)
Railsエンジニアのためのウェブセキュリティ入門
Amimoto サポート
TwitterのOAuthの問題の補足とか
Share grafana iframe in a web site with security