How Go Mitigates Supply Chain Attacks - The Go Programming Language
Filippo Valsorda 31 March 2022 Modern software engineering is collaborative, and based on reusing Open Source software. That exposes targets to supply chain attacks, where software projects are attacked by compromising their dependencies. Despite any process or technical measure, every dependency is unavoidably a trust relationship. However, the Go tooling and design help mitigate risk at various
セキュリティツールの評価は難しい - knqyf263's blog
前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、Trivyという脆弱性スキャナーのメンテナをやっています。 github.com とある有名な方による以下のツイートがありました。 I just discovered, during @cloudflare #SecurityWeek no less, that Trivy (the vuln scanner) doesn't detect known issues in Alpine images. Including a critica
マイナンバーカードと電子署名の本(無料配布) - cuspy diary
2018年開催の技術書展5で配布した「マイナンバーカードと電子署名の本」を無料配布します。 マイナンバーカードと電子署名の本(PDF)たまにSNSなどで再販しれくれないかと要望が来ていたのだけど、BOOTHなどの販売ページを用意するのが面倒で放置していました。 そのたびに無料公開しようかなと考えていましたが、それは購入してくれた人に対して不義理になるのではと考えてるうちに3年が経ち、さすがにもう良かろうと思うので無料配布します。古い内容があるかもしれないのでその点ご注意ください。 そういえば最近Markdownが話題ですが、この本もMarkdownで書いて組版しています。 誤りなどありましたら、原稿レポジトリでissue報告をお願いします。 https://github.com/hamano/myna-book どうしてもお金を払って読みたいという人はGithub sponsorで支払いで
Let's Encryptのルート認証局移行についてちょっと調べてみた - Qiita
私も大変有り難く利用させてもらっている、みんな大好きLet's Encryptはいろんな方の寄付のおかげで無料で利用できるSSLサーバー証明書の発行サービスですが、何やらルート認証局の移行が話題になっているので、ちょっと調べてみました。 問題の概要は、こちらのブログでとても詳しく解説されており、とても参考になりました。ありがとうございます。 公式から出ている説明だと、出てくる証明書の関係がわかりにくく、図もちょっと間違っていたので、別の図を起こしました。簡単には、DST Root X3ルート証明書が期限切れを迎えそうなので、新しいISRG Root X1ルート認証局に移行したいわけです。 certbotを使っていると /etc/letsencrypt/archive/ドメイン/ に発行された証明書、チェーン、秘密鍵の履歴が残りますが、その時期を頼りにどうなっていたのか見てみます。 2020
図解 X.509 証明書 - Qiita
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
JWT(JSON Web Token)を使った認証を試みる
Oauth2やOpenID Connectなどすでに導入されているJWT(JSON Web Token)。 今後IoTとかを考えると認証手法としては結構有効な認証方法だということで、改めて眺めてみた。 JSON Web TokenJSON Web Token(JWT) jot(ジョット)と発音する。 JSONを電子署名したurl-safe(URLで使用できない文字が含まれる)なclaimのことを指す。rfc7519 また同じような言葉もあるので一旦整理する。 JWS は署名したもの JWE はEncryptしたもの 一般的にJWTというとJWSのことをいう。 電子署名(公開鍵+秘密鍵方式)をしているため、データの読み出し、書き込みができる。 しかし、その内容の改竄はチェックできる。 JSONの内容を秘匿化するわけではないので、内容は誰でも見ることはできるという点は注意が必要。 jwt.io
Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか - ぶるーたるごぶりん
セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか 自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。 新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。 ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。 本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になる
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策：徳丸浩氏が8つの試練を基に解説（1/3 ページ） ECサイトやWebサービスでセキュリティインシデントを起こさないためには何をすればいいのか。2019年12月に開かれた「PHP Conference Japan 2019」で徳丸浩氏が、架空企業で起きたセキュリティインシデントを例に、その対策方法を紹介した。 ECサイトやWebサービスを提供する会社で発生したセキュリティインシデントに関するさまざまなニュースが後を絶たない。どうすればこうしたインシデントは防げるのだろうか。 『体系的に学ぶ安全なWebアプリケーションの作り方』（通称：徳丸本）の筆者として知られる徳丸浩氏（EGセキュアソリューションズ 代表取締役）は、2019年12月に開かれた「PHP Conference Japan 2019」のセッション「オニギリペイのセキュリ
SSH秘密鍵のパスフレーズは（つけるなら）11文字以上にしましょうねという話 - 本当は怖いHPC
twitter上で、「SSHの秘密鍵って、盗まれて.bash_history見られたらアクセスし放題だから危ないからパスフレーズを付けるべき」という話があった。個人的には、パスフレーズは気休め程度にしかならないと思っているので付けていない。そもそも、SSH秘密鍵のパスフレーズは、ネットワーク越しのパスワードとは違うもので（だから違う名前がついているのだが）、ZIPファイルのパスワードと似たようなものだ。攻撃者がファイルをローカルにコピーしてじっくり解析できる。 よって、パスフレーズが役に立つのは、 秘密鍵（とシェルのログ）を盗まれ、 秘密鍵を盗まれたことに気づき、 素早くすべての接続先ホストにおいて盗まれた秘密鍵を無効にする という場合だ。このシナリオなら、攻撃者によって接続先に不正にアクセスされるのを防ぐことができる。 パスフレーズによって、どれくらいの猶予が生まれるのか？ パスフレーズ
パスワードハッシュ化で用いるソルト(Salt)とペッパー(Pepper)/シークレットソルト(Secret Salt)の役割と効果 - Qiita
パスワードハッシュ化で用いるソルト(Salt)とペッパー(Pepper)/シークレットソルト(Secret Salt)の役割と効果Security認証password はじめに 背景 Webサービス開発等でパスワードをデータベースに保存する際、ソルトを付与した上で一方向関数等を用いて(ハッシュ化して)保存することはすでに一般的です。 http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html ソルトだけでなく何らかの秘密文字列を含んだ上でハッシュ化して保存する実装を目にしたことがある方もいると思います。 Rails向けのdeviseGemでも"Pepper"という名前でそういった実装がされています。 https://qiita.com/kenjiszk/items/d38e398bc120cf4bbd1c#%E3%82%BD%E3
匿名化技術についてまとめてみた【k匿名性, l多様性,t近接性,差分プライバシ】 - Qiita
概要 昨今ビックデータやそれを活用するAI技術などが特に技術的な注目を浴びていますが、これに伴って個人情報が侵害される危険性も増しました。しかし、個人情報を保護するような技術はAIなどの技術に比べて軽視される傾向にあると思います。 僕はそんな個人情報を保護する技術、匿名化技術を研究しています。匿名化技術をより皆さんに理解して頂きたくて、この記事を書くことに決めました。 注意 この記事を書くにあたり、できるだけ正しい記述を心がけますが、内容のわかりやすさを優先して僕の解釈を混ぜています。よって、不正確な部分が生じていることがあると思います。お気づきの際は適宜コメント等で指摘してくださると大変助かります。 そもそも匿名化とは？ 匿名化という言葉が指す行為とは「データから名前や社会福祉番号などのすぐに個人が特定されるような情報を削除すること」と判断される方が多いと思います。しかし、例えば位置情報
pkiday_tls13.key
ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data ClientHello ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData Finished Application Data Application Data ClientHello Finished ApplicationData end_of_early_data ServerHello EncryptedExtensi
TLS1.3時代の新常識
TLS • TLS (reliable) endpoint endpoint CC BY 3.0 https://www.youtube.com/user/TheWikiLeaksChannel ClientHello+ ApplicationData end_of_early_data Finished ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新規タブリンクの恐ろしい仕様、Chrome 88で変更へ ～Safari/Firefoxに合わせた安全な仕様に／“rel=noopener”を付け忘れても大丈夫【やじうまの杜】
BCrypt(Blowfish暗号)について調べたので文書化してみました
セキュリティプロトコルの形式検証ツール“ProVerif” - Qiita
Salt & Pepper, please: a note on password storage
コードで理解するPlayframeworkの脆弱性
クラウド・Webホスティングサービスのセキュリティと運用技術の研究
