What are ssh-keygen best practices?
Most users would simply type ssh-keygen and accept what they're given by default. But what are the best practices for generating ssh keys with ssh-keygen? For example: Use -o for the OpenSSH key format rather than the older PEM format (OpenSSH 6.5 introduced this feature years ago on 2014-01-30) How should one calculate how many rounds of KDF to use with -a? Should -T be used to test the candidate
SSH Key Best Practices
Ensure Separation Ensure SSH Keys Are Associated With a Single Services Tie SSH keys back to an individual services, rather than just a generic key that is associated with multiple services github / acquia /aws etc . This will provide an effective SSH audit trail and more direct oversight. Use a separate key per client you SSH from So don’t copy the private key from your laptop to another laptop f
JWT アクセストークンからの個人情報漏洩 - Qiita
内包型アクセストークン、典型例としては JWT アクセストークンは、関連するデータを自身の内部に持っています。下記の条件が成り立つと、論理的な帰結として、そのようなアクセストークンから直接個人情報が漏洩します。 個人情報が含まれている 暗号化されていない ステートレス 意図しない者に盗まれる ここで「ステートレス」とは、「個人情報を保存するためのデータベースレコードを認可サーバー側に持たない」ことを意味しています。 もしもアクセストークンの実装が「内包型／暗号化されていない／ステートレス」であり、また、システムがクライアントアプリケーションに個人情報を提供する必要があるなら、当該システムは、アクセストークンに情報を埋め込むことを避け、個人情報を問い合わせるための Web API を提供すべきです。 ユーザー情報エンドポイント (OIDC Core Section 5.3) はそのような A
「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
FIDO at LINE: LINE FIDO2-Serverをオープンソースとして公開しました
FIDO2はこの2つの標準を統合し、従来のモバイル環境だけでなく、ウェブなどどこにでも使用できるように改良した規格です。ウェブブラウザのためのWebAuthn1と認証器のためのCTAP（Client to Authenticator Protocol）という2つの規格で構成されています。現在、さまざまなウェブブラウザでWebAuthn APIをサポートしています。ウェブブラウザがクライアントの役割を提供するため、認証を提供するサービスでは、ウェブブラウザが提供するAPIを利用して、より簡単にさまざまな環境で認証サービスを提供できます。その結果、ユーザーはより便利で安全に認証できます。またU2Fの場合は、CTAP2規格が下位互換性をサポートするため、従来のハードウェアベースの認証をそのまま利用できます。現在、WebAuthn規格をサポートするブラウザの現状は以下のとおりです。 出典：http
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係 - Qiita
JWS/JWE/JWT/IDトークンの包含関係 JWS (JSON Web Signature) と JWE (JSON Web Encryption) の直列化方法には、それぞれ JSON 形式とコンパクト形式がある。 JWT (JSON Web Token) は JWS か JWE だが、いずれにしてもコンパクト形式である。仕様でそう決まっている。 仕様により、ID トークンには署名が必要なので、ID トークンは JWS もしくは「JWS を含む JWE」という形式をとる。 ID トークンは「JWE を含む JWS」という形式はとらない。なぜなら、仕様により、ID トークンを暗号化する際は「署名してから暗号化」という順番と決まっているため。 アクセストークン/JWT/IDトークンの包含関係 アクセストークンの実装が JWT だとは限らない。 仕様により、ID トークンは必ず JWT で
ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife
おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで
Chrome 93で実装されたCross Device WebOTPフローを試してみた - r-weblife
おはようございます ritou です。 8月ですよ。お仕事の進捗大丈夫ですか？ 最近、Google方面からDecoupled AuthNの香りがしたので追ってみました。 何の話? この話です。 developer.chrome.com WebOTPとは? Webアプリケーションがモバイル端末でSMS経由のOTP認証をしようと思った時、画面に「認証コードを送信しました」なんて出た後にSMSを確認できるアプリを起動して確認してまたブラウザに...とかをやったことがある人は多いでしょう。 WebOTPとは、モバイル端末上のブラウザであればアプリの切り替えをせずにワンタップでSMSで受け取ったOTPの値を読み込んで検証リクエストに繋げられる、しかもSMSを発信したWebアプリを特定できるフォーマットになっていることでフィッシングサイトからはこのフローを使えなくするような仕組みのことです。 web.
FIDOアライアンスのUXガイドラインには何が書いてあるか - r-weblife
おはようございます ritouです。 前の投稿でも取り上げたWebAuthnとかFIDO認証って呼ばれてる認証方式のお話です。 ritou.hatenablog.com 今回は、FIDOアライアンスからUXのガイドラインが出ているので紹介します。 fidoalliance.org FIDO UX Guidelines - FIDO Alliance UX GUIDELINE PDF - FIDO Alliance 一言で言うと MacとかiOSとかAndroidとかWindowsの生体認証が使えるデバイス上でWebアプリを使ってるユーザーに対して、新規登録/ログインフローのなかでをどうやってデバイスを登録させてFIDO認証を使わせるか っていうお話です。 今回のターゲットとしては一般的なユーザーが使いつつ、強固なセキュリティが求められる銀行のWebアプリケーションのようなところを想定してい
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
マイクロサービス時代のセッション管理 - Retty Tech Blog
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
Behind GitHub's new authentication token formats
EngineeringSecurityBehind GitHub’s new authentication token formatsWe're excited to share a deep dive into how our new authentication token formats are built and how these improvements are keeping your tokens more secure. As we continue to… We’re excited to share a deep dive into how our new authentication token formats are built and how these improvements are keeping your tokens more secure. As w
社内認証パスワードレス化のすゝめ
パスワードレスとは 「パスワードレス」とは言葉通り「パスワードが要らない」という意味です。パスワードにはたいてい「英数字・記号を含む8文字以上の複雑な文字列にしてください」「一年ごとに変更をしてください」といった煩わしい制約が存在します。利用者にしてみれば毎回違うパスワードを考えたり覚えたりするのは負担ですし、結局簡単なものや同じようなパスワードを使いまわしがちになり、管理者としても望んだ結果ではないという問題があります。パスワードレスはそういった煩わしさから利用者・管理者双方を解放します。 ヤフーの社内認証事情 ヤフーには一万人を超える社員が在籍しており、毎日一回以上認証の機会があります。 社員が社内ツールにアクセスすると、まずはじめに共通の入口である内製の社内認証基盤へとリダイレクトされます。そこで社員は実際のログイン手段として以下の三種類の認証方式から選択します（図1）。 社内ID/
SMS認証はダメ。セキュリティ対策の注意点を徹底解説 | ライフハッカー・ジャパン
セキュリティの甘かったSMSサービスLucky225さんはMediumで次のように説明しています。 2021年3月11日（木）のある時点まで、NetNumberは、あらゆる携帯電話番号のNNIDの再割り当てや乗っ取りを、認証も検証を行なわずに許可していました。 おそらく、この筆者やほかのジャーナリストから説明を求められたNetNumberは、内部調査を行ない、それが事実であることがわかると、一時的に携帯電話番号の乗っ取りをできなくして、最初から何の問題もなかったかのように偽装しようとしたのだと思われます。 （中略） 携帯電話番号の代わりにVoIP番号を使ってさまざまなサービスを利用している人たちが、今回の攻撃では脅威にさらされることになりました。 一方で、プライバシーを気にせずに本当の携帯電話番号でサービスを利用している人たちのほうがむしろ安全だったのです。 SMSを別の電話番号に転送する
Athenz - Yahoo!デベロッパーネットワーク
Athenz（アセンズ）は、Role Based Access Control（ロールを利用したアクセス制御）を利用して、サービス間の認証・認可を行うシステムです。 旧Yahoo! Inc.にて開発されたシステムであり、2017年にOSS化されました。 2021年1月にはCNCF Sandboxプロダクトとなり、活発に開発が行われています。 Athenz 当社では2015年からAthenzを利用しており、2017年のOSS化にも貢献しています。 社内では多くのアプリケーションが稼働し、それぞれがAPI連携にてデータのやりとりをしています。それらのアプリケーション間の認証・認可の基盤システムとしてAthenzを活用し、当社が提供するサービスのセキュリティ向上に寄与しています。 社内にて利用してきた実績をもとに、Athenzへの改善提案・関連プロダクトの開発・提供や、各種カンファレンスにて社内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSH Key Management Overview & 10 Best Practices | BeyondTrust
Comparing SSH Keys - RSA, DSA, ECDSA, or EdDSA?
GitHub - line/line-fido2-server: FIDO2(WebAuthn) server officially certified by FIDO Alliance and Relying Party examples.
GitHub - onagano-rh/keycloak-tutorial