GitHub - dstotijn/hetty: An HTTP toolkit for security research.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
10 Docker Security Best Practices | Docker Best Practices | Snyk
Docker container securityThe topic of Docker container security raises concerns ranging from Dockerfile security—relating to the Docker base images and potential security misconfigurations,—to the Docker container security at runtime regarding network ports, user privileges, Docker mounted filesystem access, and others. In this article, we will focus on the Docker container security aspects relate
CowrieにHASSHが実装された - 人間ハニーポット作戦
HASSH機能の紹介 9月30日、CowrieにHASSH機能が実装されました。 HASSHとは、9月27日にSalesforceが公開したOSSのSSHクライアントフィンガープリンティングツールです。 技術詳細はsalesforceが公開しているblog, githubをご覧ください。 engineering.salesforce.com github.com 一応簡単に解説しますと、SSHのハンドシェイクで鍵交換をする段階でパケットに含まれるアルゴリズムの情報からMD5を計算します。これがFingerprintというクライアントの特徴になります。 鍵交換がされた時点でFingerprintが取れるので、SSHでログインを成功させる必要はありません。 HASSH機能を試す 本当に特徴が現れるのか、実際に1日程度植えて観測してみました。 観測期間は2018年10月10日10時32分~201
ブロックチェーンという言葉に騙されないために - いもす研 (imos laboratory)
近年、仮想通貨ビットコインが注目されているのにともない、その根幹技術であるブロックチェーン技術が金融業界で注目されています。しかし、ブロックチェーンという言葉自体が流行してしまった結果、様々な金融関連企業が正しく理解しないまま手を出し始めているように見えます。そして、技術的な内容がほとんど表に出てくることはなく、批判する人が少ないという問題を感じたのでこの記事を書きました。ブロックチェーンでできることとできないことを整理し、皆が今後ブロックチェーンの記事により深いツッコミを入れられるようになればと思います。自分はブロックチェーンの専門家ではないため若干の間違いもあるとは思いますが、見つけ次第 @imos まで連絡いただけると幸いです。適宜修正します。 背景 ブロックチェーンとは ブロックチェーンとは、いくつかの未完了の取引を「ブロック」という単位でまとめ、ブロックの正当性を証明するものと共
ブラウザ拡張の権限でどこまで悪いことをできるのか？とその対策【デモあり】 - Qiita
[2018/07/07 追記] 本記事ではChrome拡張について説明していますが、Firefox1やEdgeの拡張機能もほぼ同じ仕組みで動いています。 [2023/11/06 追記] #参考 ページを追加しました。 Chrome拡張。便利な機能を簡単に追加できるので使っている人も多いと思います。 ただ、インストール時の権限の注意書きが分かり難いので無条件に承認（追加）していることもあるのではないかと思われます。 そこで、本記事ではChrome拡張の権限の種類・確認方法の他、拡張がどこまで（悪いことを）できるのかとその対策を3段階の権限（危険性）レベルごとに紹介していきたいと思います。 便利だが危険性もあるChrome拡張 Chrome拡張をインストールすると、Webページを読むというブラウザ本来の機能だけでなく様々なことができるようになります。 例えば、Webメールの新着通知や記事などの
衝撃のAugust
なんかFacebookへの投稿で「Augustのオフィスで凄い衝撃を受けた。日本のスマートロック会社はもう遅れすぎていてヤバイ」と煽るような事を書いたのが運の尽き。「ガタガタ言ってないで、早くブログで詳細書け！」と各方面からプレッシャーを受けてしまったSF在住中年起業家Kenです。ただ自分の考えの整理になる以外にも、やはりIoTというジャンル（？）をハード売り切りだけで捉えてしまうのと、本気でプラットフォームを目指すのとでどれだけ差が出るかを思ったより早く、具体的に示している事例かも？と感じたので整理してみる価値があると考えました。 サンフランシスコ市内のオフィス。プレスのために用意したデザインモックなどが綺麗に展示してあったり、評価用の様々なタイプのドアや鍵がずらりと並んだ倉庫のように広く、でも綺麗で素敵なオフィスでした。$50M調達とかすると色々とできていいなー（ボソ）。まぁそこじゃな
インターネット10分講座：暗号アルゴリズムの危殆化 - JPNIC
実は、一般数体ふるい法の計算量は、以下のような漸近的な評価が与えられているのでおおよその推定は可能ですが、正確な計算量の予測にはあまり適していません。 ただし、 そこで、関係式収集ステップの計算量を部分的な実験結果から推定する方法を用いて、CRYPTREC※1では素因数分解問題に関する評価結果を2006年度に公表しています※2。 図1：1年間で関係式収集ステップを完了するのに要求されるコンピュータの処理性能予測（［3］からの引用） この評価結果から、分解にかけるコストに依存するものの、1024ビットのRSAモジュラスの素因数分解はおおよそ2015年.2020年頃から分解の可能性が高まってくるということが読み取れます。従って、今後、新規にシステムを構築する場合には、1024ビットよりも長いサイズのRSAモジュラスを選択することが望ましいものと考えられます。 移行に際してまずはじめに問題となる
ダークネットのはなし #ssmjp
The document summarizes cryptography techniques such as hashing functions, MAC, digital signatures, and FIDO authentication. It discusses SHA-2 and SHA-3 hashing standards, how MAC provides data integrity while signatures provide non-repudiation. ECDSA is introduced as an elliptic curve digital signature algorithm. FIDO aims to standardize multi-factor authentication using authentication devices a
RSA公開鍵から素数の積を取り出す方法 - hnwの日記
RSA暗号はHTTPSやSSHの通信で利用されている暗号化方式です。公開鍵として巨大な素数の積を交換しあって暗号に利用しており、この素因数分解が困難であることにより安全性が担保されています。このことは教科書にも載っているような内容で、ご存じの方も多いかと思います。 ところで、その素数の積を実際に見たことってありますか？少なくとも僕は見たことがありませんでしたし、大抵の人は見たことが無いのではないでしょうか。本稿ではこの公開鍵の情報を見る方法を紹介します。 OpenSSH公開鍵の中身を見る まずはOpenSSHの公開鍵の情報を取り出してみます。OpenSSHの公開鍵は次のようなものです。 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCw+XdXSrhBcDFAXPcisrc8im4y8ytC46HEQ0GsWOph9OPK1elTQmBD5LATGfp4JG4
オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場
オレオレ認証局が忌避されるべきものとされてきた理由は、X.509 PKIが保証する安全性は、最も信頼性が低い認証局（trusted root）のそれに等しいからです。 しかし、X.509 v3以降ではName Constraintsが導入され、「特定のドメインに対してのみ証明書を発行可能な認証局」を定義できるようになっており、同constraintをcritical key usage extension*1として宣言したルート証明書を安全な経路で配布、インストールすることができれば、上記のようなX.509 PKIの系全体に対する影響は発生しないことになります*2。 ここで問題になるのは、どの程度のウェブブラウザがName Constraintsに対応しているのか、という点になりますがhttps://news.ycombinator.com/item?id=5194103によると、Chro
LINE「独自暗号化」のメリットと安全性について
LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced t
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
いまさら聞けないパスワードの取り扱い方
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Knowledge Base - Securing
EC2でnginxの過剰な404|403に対しfail2banをかける - Qiita
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
https://dev.classmethod.jp/articles/cve-2014-3566-poodle-issue/
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
RailsアプリケーションのセキュリティチェックするRails Brakemanを試してみる - Qiita
