GitHubで扱うPersonal access tokenの利用方法をセキュアにする - 10X Product Blog
こんにちは、セキュリティチームの@sota1235です。 セキュリティチームでは昨年の夏頃からGitHub上のセキュリティリスクを洗い出し、順に対応や改善を行っています。 そのうちの1つとして、昨年の秋ごろからGitHubのPersonal Access Tokenの取り扱いの改善を行ってきました。 具体的には以下の取り組みを行いました。 CI等で利用されているPersonal Access Tokenの利用廃止 OrganizationにおけるPersonal Access Token(classic)の利用禁止設定 今回はこの2つの取り組みについて、どのような課題設定を行い、どんな手順で完了したのかをお話しします。 以下のような課題感、疑問をお持ちの方に対する1つの回答になりうると思うので該当する方はぜひご一読ください🙏 GitHubにおけるPersonal Access Token
TLS 1.3 開発日記 その22 公開鍵暗号の動向 - あどけない話
P256とかX25519とかPSSとか聞いても、よくわからない人のための用語解説。 長い間TLSの世界では、鍵交換にも認証にもRSAが使われてきた。必要となる安全性が大きくなると、RSAの公開鍵は急激に大きくなり、したがって鍵交換や認証のコストが大きくなるという問題がある。 楕円曲線暗号(ECC: Elliptic Curve Cryptography)は、RSAやDiffie Hellmanに比べると、小さな公開鍵で同程度の安全性を実現するという特長を持つ。特許問題が不透明なせいで楕円曲線暗号は長年敬遠されてきたが、この数年で(少なくとも鍵交換に対しては)一気に普及してきた感じだ。 おおざっぱに言うと、楕円曲線暗号で実現できるのは、DH(Diffie Hellman)とDSA(Digital Signature Algorithm)であり、RSAは実現できない。 鍵交換のDHに関しては、
認証にまつわるセキュリティの新常識 - Speaker Deck
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-6…
Applied Crypto Hardening: bettercrypto.org
We would like to express our thanks to the following reviewers and people who have generously offered their time and interest (in alphabetical order): Brown, Scott Brulebois, Cyril Burghardt, Krzysztof Dirksen-Thedens, Mathis Dulaunoy, Alexandre Endres, Johannes Gühring Philipp Grigg, Ian Haslinger, Gunnar Horenbeck, Maarten Huebl, Axel Knecht, Pascal Koetter, Patrick Ben Kovacic, Daniel Lenzhofer
商用環境で設定しておきたいセキュリティ関連 HTTP ヘッダまとめ - A Memorandum
TL;DR X-Content-Type-Options X-Frame-Options(XFO) X-XSS-Protection Content-Security-Policy (CSP) Upgrade-Insecure-Requests Strict-Transport-Security (HSTS) Public-Key-Pins (HPKP) 設定 TL;DR X-Content-Type-Options MIME スニッフィングの無効化 X-Frame-Options(XFO) フレーム表示を制限しクリックジャッキングを予防 X-XSS-Protection XSSフィルタの有効/無効 Content-Security-Policy (CSP) XSSなどの攻撃を軽減するセキュリティレイヤー Strict-Transport-Security (HSTS) HTTP の代わり
AWS セキュリティとコンプライアンス
1. 2016 / 03 / 15 アマゾン ウェブ サービス ジャパン 株式会社 プロフェッショナルサービス本部 高田 智己 【 AWS 初心者向け Webinar 】 AWSにおけるセキュリティとコンプライアンス 2. ご質問を受け付け致します！ 質問を投げることができます！ • Adobe Connect のチャット機能を使って、質問を書き込んで ください。（書き込んだ質問は、主催者にしか見えません） • 最後の Q&A の時間で可能な限り回答させていただきます。 ①画面右下のチャッ トボックスに質問を 書き込んでください ②吹き出しマークで 送信してください 3. AWS 初心者向け Webinar のご紹介 • AWS についてこれから学ぶ方むけの ソリューションカットの Webinar です • 過去の Webinar 資料 – AWS クラウドサービス活用資料集ページにて公開
git-secret
Synopsis Intro There’s a well known issue with deploying and configuring software on servers: generally you have to store your private data (such as database passwords, application secret-keys, OAuth secret keys, etc) outside of the git repository. If you do choose to store these secrets unencrypted in your git repo, even if the repository is private, it is a security risk to copy the secrets ever
Homemade DDoS Protection Using IPTables SYNPROXY
Homemade DDoS Protection with IPTables SYNPROXY Software Portal Home > Knowledgebase > HOWTOs > Homemade DDoS Protection Using IPTables SYNPROXY Homemade DDoS Protection Using IPTables' SYNPROXY *NEW* 2016-04-18: Updated guide to DDoS protection with iptables available! First off, if you want the real deal and get your service DDoS protected from even the most complex types of DDoS attacks by secu
How To Safely Generate A Random Number — Quarrelsome
Use urandom Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. Use urandom. But what about for crypto keys? Still urandom. Why not {SecureRandom, OpenSSL, havaged, &c}? These are userspace CSPRNGs. You want to use the kernel’s CSPRNG, because: The kernel has access to raw device entropy. It can promise not to share the same state between applications. A good kernel CSPRNG, like FreeB
qpstudy 2015.11.14 一歩先を行くインフラエンジニアに知ってほしいSSL/TLS
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;Read less
SSHサーバセキュリティ設定ガイド V1.0 Rev.1 (2015-03-15)
Copyright © Nippon CSIRT Association. 2015. All rights reserved. SSH サーバセキュリティ設定ガイド Ver 1.0 日本コンピュータセキュリティインシデント対応チーム協議会 SSH サーバセキュリティ設定ガイド 2 －目次－ 1 はじめに..............................................................................................................................................................4 2 前提条件.................................................................................
scryptがGPUに破られる時 | びりあるの研究ノート
一般的によく知られている SHA-256 や MD5 などのハッシュ関数は非常に単純な設計となっており、非力なパソコンや組み込み機器、スマフォなどでも高速に計算できます。 しかしながらその一方で、ハッシュ関数を手当たり次第に計算し、もとの入力値を復元するいわゆる「ブルートフォース攻撃」が容易であるというデメリットがあります。 特にこのような SHA-256 や MD5 といったハッシュ関数は、GPU を用いるか、もしくは専用のハードウェア (FPGA もしくは ASIC) を製作することで非常に高い効率で計算（攻撃）ができてしまうことが知られています。 そのため、GPU ないし専用ハードウェアを用いたとしても、攻撃効率の改善が難しくなるような新たなハッシュ関数がいくつか提案されています。 その中で比較的古く (2012年ごろ) に開発され、他のハッシュ関数にも影響を与えている「scrypt
Using an offline GnuPG master key
OpenPGP subkeys have many benefits (well summarized on this Debian wiki page), one of them being that if you have both an encryption subkey and a signing subkey (at least), you don’t need your master private key for your daily usage of OpenPGP—you will only need it for signing someone else’s key or to modify your own key (adding or revoking User IDs, adding or revoking subkeys, updating the prefer
単一のAWSアカウントに潜む重大な危険 | POSTD
Amazon Webサービス（AWS）のアカウントは、AWSでビジネスを展開している人にとって非常に大事なものです。ですが、AWSアカウントをたった一つしかもっていない場合、重大なセキュリティの危険に直面することになるでしょう。何が問題なのか、そしてどうすれば解決できるのかを、この記事でご紹介したいと思います。 危険性をはらむデフォルト設定：単一のAWSアカウント 単一のAWSアカウントには、EC2仮想サーバ、S3バケット、RDSデータベースなどビジネスに必要な様々なリソースとともに、IAMユーザが含まれています。アカウントへのログイン方法は基本的に2通りあります。ユーザ名とパスワードを入力するAWS Management Console、またはCLIやSDKで用いられるAWSアクセス認証情報を使うのです。以下の図は、その仕組みを示したものです。 訳注 account「このアカウントにはI
色んなXSS – nootropic.me
2015/4/16(木)：ページの一番下に追記を記述しました。 その昔、なんとかキャンプというセキュリティのイベントに参加した時「アウトプットが大事」と言われたのを思い出しました。 でも、普通自分の見つけた知識は後生大事に抱えておきたいもんだと思います。 そこで今回はそういった何かしょーもないものを捨てるべく、溜め込んだ色んなXSSのPoCを少し書き出してまとめました。 今まで自分で見つけたものや海外のSecurity Researcher達から収集したものもあります。 さて、今回リストアップしたPoCの見方ですがいくつかの項目があります。 一番上の「手法」はタイトルみたいなものだと思って下さい。 二番目の「PoC」はスクリプトを実行する為のコードです。殆どがアラートが出るだけのスクリプトの為危険なコードは無いつもりですがご自分のブラウザで実行する際は自己責任でお願いします。リンクをクリッ
Myths about /dev/urandom
There are a few things about /dev/urandom and /dev/random that are repeated again and again. Still they are false. /dev/urandom is insecure. Always use /dev/random for cryptographic purposes. Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems. /dev/urandom is a pseudo random number generator, a PRNG, while /dev/random is a “true” random number generator. Fa
パスワードの最適変更間隔とその定量的効果の評価
パスワードの最適変更間隔とその定量的効果の評価 twitter:@pseudoidentifie CC0 簡単のために、ユーザが候補とするパスワード選択空間と攻撃者が想定する攻撃パスワード空間は同一とし、個のパスワード候補が含まれるとする。また、攻撃者は、パスワード空間中から、ランダムに攻撃パスワードを順次選択し、攻撃を行うものとする（本攻撃方法は決して典型的な攻撃方法とは限りません）。また攻撃は、秒間隔で実施されるものとする。 ユーザがパスワードの変更を行わない場合、秒で、全パスワードの攻撃が可能であり、ユーザのパスワードを攻撃者は知ることができる。攻撃者がパスワードを知るのにかかる平均時間は以下となる。 次に、ユーザは、をより小さい自然数として、秒間隔でパスワードの定期変更を行う場合を考える（ユーザは個のパスワード候補からランダムにパスワードを選択するものとする）。また、簡単のために、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.cryptrec.go.jp/report/c14_oper_guideline_SSLTLS_web_1_1.pdf
セキュリティ対策情報 | セキュリティ対策のラック
how to defend DNS authoritative server against DNS WaterTorture
