並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 464件

新着順 人気順

ハッシュ化の検索結果1 - 40 件 / 464件

  • ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ

    ※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント(ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー)の作成、安全な取り扱い、

      ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
    • ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita

      pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた(中略)パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。(それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。) 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。

        ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
      • ドコモとソフトバンク、パスワードをハッシュ化せず保持 「パスワードを忘れた」からユーザーへ開示【追記あり】

        ドコモとソフトバンク、パスワードをハッシュ化せず保持 「パスワードを忘れた」からユーザーへ開示【追記あり】 LINEMOがパスワードを平文保持している――そんな報告がTwitterで上げられている。ITmedia NEWS編集部で確認したところ、LINEMOの他にドコモとahamo、ソフトバンク、Y!mobileの会員サービスでも、ユーザーに対してパスワードを平文で提示する機能を持っていることが分かった。事業者側によるパスワードの平文保持は、不正アクセスなどで情報漏えいが起きた際のリスクになる可能性がある。 【編集履歴:2022年3月16日午後2時 ドコモへの追加取材に伴い、タイトルとドコモ引用部の記述を変更し、追記を行いました】 【編集履歴:2022年3月16日午後7時30分 ソフトバンクへの追加取材に伴い、ソフトバンク引用部の記述を変更し、追記を行いました】

          ドコモとソフトバンク、パスワードをハッシュ化せず保持 「パスワードを忘れた」からユーザーへ開示【追記あり】
        • CDNは5時間で開発できる | POSTD

          「CDN」(content delivery network)という言葉からは、Googleのような大企業がいくつもの巨大なハードウェアを管理し、1秒当たり何百ギガビットものデータを処理する様子が想像されます。しかし、CDNは単なるWebアプリケーションです。私たちのイメージとは違いますが、それが事実です。8年前に買ったノートパソコンを使って、コーヒーショップの席に座りながらでも、きちんと機能するCDNを構築できます。この記事では、これから5時間でCDNを開発しようとするときに、直面するかもしれないことを紹介します。 まずはCDNの機能を明らかにしておきましょう。CDNはセントラルリポジトリ(通称:オリジン)からファイルを吸い上げ、ユーザーに近い場所でコピーを保存します。初期のオリジンはCDNのFTPサーバーでした。現在、オリジンは単なるWebアプリとなり、CDNはプロキシサーバーとして機

            CDNは5時間で開発できる | POSTD
          • KADOKAWAのハッキングの話チョットワカルので書く

            私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。 個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。 (関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨) 三行VPN→プライベートクラウドの管理システムとオンプレ認証→各システムと言う流れで侵入されていると思われるオンプレのディレクトリサービスとクラウドのidMが接続され、オンプレの認証資格でSaaSは一部やられた可能性がある現在クラウドにリフトアップ中で、新システムはモダンな対策された方法で保護されており無事だった。が、それ故にオンプレへの対策が後手だったのでは会社のシステムはどうなってるか私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさ

              KADOKAWAのハッキングの話チョットワカルので書く
            • パラノイアのプログラマと第6感 - megamouthの葬列

              今だから白状すると、昔、運営していたサービスの一般ユーザーのパスワードをハッシュ化(暗号化)せずに平文でDBに保存していたことがある。 言いわけは、幾つかある。 一つは、今では当たり前のようについているパスワードリマインダーの仕組みが当時は一般的ではなかったこと。 ユーザーがパスワードを忘れた、と問い合わせしてきた時に、最も自然な方法はまさに当人が設定した「パスワード」を一言一句違わず登録メールアドレスに送信することだった。あなたのパスワードは○○○です。ああそうそう、そうだったね。こういう感じだ。 当時のユーザーはそれを不審がらなかった。 またサポートコストの問題があった、パスワードの再発行を、そのためのトークンを含んだ長いURLを、大半のユーザーが嫌がっていた。 サポート部門はOutlookExpressに表示された長すぎるURLのリンクが途中で切れててクリックできない、という苦情にい

                パラノイアのプログラマと第6感 - megamouthの葬列
              • FLoCとはなにか - ぼちぼち日記

                1. はじめに Google がChrome/89よりトライアルを開始しているFLoC (Federated Learning of Cohorts)技術に対して、現在多くの批判が集まっています。 批判の内容は様々な観点からのものが多いですが、以前より Privacy Sandbox に対して否定的な見解を示してきたEFFの批判「Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know.」が一番まとまっているものだと思います。 これまで Privacy Sandbox 技術に関わってきた身としては、各種提案の中でFLoCは特にユーザへの注意が最も必要なものだと思っていました。しかし、これまでのド直球なGoogleの進め方によって、FLoCのトラ

                  FLoCとはなにか - ぼちぼち日記
                • パスワードはおしまい! 認証はパスキーでやろう

                  はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ(複雑で長い文字列、90日でパスワード変更など)が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン

                    パスワードはおしまい! 認証はパスキーでやろう
                  • 何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog

                    不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認

                      何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog
                    • やはり俺の情報教科書はまちがっている。 - Qiita

                      目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには 2025 年入試から大学入試共通テストでも出題されるようになり、教科「情報」の重要性が高まっています。 これで 2030年に79万人不足すると言われる IT 人材 の問題が解決!…と言いたいところですが、先日も『課題感ある教科1位「情報」』という調査結果が

                        やはり俺の情報教科書はまちがっている。 - Qiita
                      • Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか

                        Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています

                          Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか
                        • [独自記事]7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明

                          セブン&アイ・ホールディングスが決済サービス「7pay(セブンペイ)」の不正利用を受けて外部のIDからアプリへのログインを一時停止した措置について、原因となった脆弱性の一端が明らかになった。日経 xTECHの取材で2019年7月12日までに分かった。外部IDとの認証連携機能の実装に不備があり、パスワードなしで他人のアカウントにログインできる脆弱性があったという。 同社は2019年7月11日午後5時、FacebookやTwitter、LINEなど5つの外部サービスのIDを使ったログインを一時停止した。「各アプリ共通で利用しているオープンIDとの接続部分にセキュリティー上のリスクがある恐れがあるため」(広報)としている。 この脆弱性は、不正利用が判明した後に外部からの指摘で明らかになったもので、セブン&アイのグループ共通ID「7iD」の認証システムに存在した。外部ID連携機能を使っている人のI

                            [独自記事]7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明
                          • 攻撃して学ぶJWT【ハンズオンあり】 - Money Forward Developers Blog

                            こんにちは。 マネーフォワードの新卒Railsエンジニア、きなこ と申します。 マネーフォワードX という組織で、日々プロダクトの開発に勤しんでおります😊 突然ですが皆さんは JWT という技術をご存知でしょうか? 私は趣味でCTFというセキュリティコンテストに出場するのですが、最近ホットだと感じるのがJWTに関連する攻撃です。 今年の1月に初めてJWTを題材にした問題に遭遇し、その後JWTの出題頻度が強まっていると感じ、社内に向けてJWTにまつわる攻撃を通して学ぶための記事を書いたところ、たくさんの反応をいただきました。 今回の記事はその内容を社外向けにアレンジし、ハンズオンを通して実際にJWTを改竄し、受け取るAPIを攻撃することでJWT自体を学べるようにしたものです。 本記事はJWTに興味があるWeb開発者を想定していますが、そうでない方も楽しんでいただけるようにハンズオンを用意し

                              攻撃して学ぶJWT【ハンズオンあり】 - Money Forward Developers Blog
                            • GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん

                              全1回、このシリーズは今回で最後です! TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ! Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ! 今回は

                                GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん
                              • iPhoneのBluetoothをオンにしているだけで付近の人に電話番号が漏れてしまうことが判明

                                by 贝莉儿 NG セキュリティサービス会社であるHexwayに所属するDmitry Chastuhin氏は自社ブログへの投稿で、「iPhoneでBluetoothをオンにしていると電話番号が付近の人に漏れてしまう」という不具合が見つかったと発表しました。 GitHub - hexway/apple_bleee: Apple BLE research https://github.com/hexway/apple_bleee Apple bleee. Everyone knows What Happens on Your iPhone – hexway https://hexway.io/blog/apple-bleee/ iPhone Bluetooth traffic leaks phone numbers -- in certain scenarios | ZDNet https:/

                                  iPhoneのBluetoothをオンにしているだけで付近の人に電話番号が漏れてしまうことが判明
                                • 暗号の歴史と現代暗号の基礎理論(RSA, 楕円曲線)-後半- - ABEJA Tech Blog

                                  はじめに このブログに書かれていること 自己紹介 注意 Part3 現代の暗号 共通鍵暗号方式と鍵配送問題 鍵配送問題とは? 共通鍵暗号方式と公開鍵暗号方式の違いとメリット・デメリット RSA暗号 RSAで使われる鍵 処理手順 暗号化の手順 復号の手順 RSA暗号の数学的背景 一次不定式が自然数解を持つ理由 eとLの関係性 そもそもなぜこの式で元の平文に戻るのか?の数学的根拠 証明パート1 フェルマーの小定理 中国剰余定理 RSA暗号をPythonで 楕円曲線暗号 楕円曲線とは? 楕円曲線の式 楕円曲線における足し算の定義 楕円曲線における引き算の定義 無限遠点 楕円曲線における分配法則と交換法則 楕円曲線の加法を式で表現 点Pと点Qが異なる場合 点Pと点P 同じ点を足し合わせる場合 有限体 有限体とは? 有限体上の楕円曲線 楕円曲線暗号における鍵 ECDH鍵共有 数式ベースでの手順説明

                                    暗号の歴史と現代暗号の基礎理論(RSA, 楕円曲線)-後半- - ABEJA Tech Blog
                                  • 【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO

                                    この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『AWS における安全な Web アプリケーションの作り方(AWS-55)』の模様をレポートします。 セッション概要 情報処理推進機構(IPA) の公開している「安全なウェブサイトの作り方」をはじめとしたセキュリティを考慮した安全なウェブアプリケーションの設計ガイドラインがいくつか知られています。本セッションでは、アプリケーション開発者向けにガイドラインに則ったアプリケーションを AWS 上でどのように実装するのかを AWS プラットフォームレイヤーとアプリケーションレイヤーのそれぞれの観点から項目ごとに解説し、アプリケーション導入前、または導入後のセキュリティ対策の指標となることを目指します。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテク

                                      【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO
                                    • Webサービスにおけるマイページの仕様とセキュリティ観点 - Flatt Security Blog

                                      はじめに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 本稿では、ログイン機能をもつWebアプリケーションにおける実装上の注意を、マイページ機能から派生する機能のセキュリティ観点から記載していきます。特に、XSS(Cross-Site Scripting)やSQLインジェクションのような典型的な脆弱性と比較して語られることの少ない「仕様の脆弱性」にフォーカスしていきます。 これから述べる実装上の注意点は、実際にはマイページ機能であるかどうかに関係なく注意するべきです。 しかし、開発者の視点に立つと「これこれの機能にはどのようなセキュリティ観点があるか」という形が読みやすく、また他の機能の仕様のセキュリティを考える上で想像力を働かせやすいものになるのではないでしょうか。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専

                                        Webサービスにおけるマイページの仕様とセキュリティ観点 - Flatt Security Blog
                                      • 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog

                                        2023年8月15日、GMWは同社が運営するサービスが不正アクセスを受けたことで、「pictBLand」及び「pictSQUARE」のデータベース情報が外部へ流出した可能性があると公表しました。また当該サービスのWebサイトを閲覧した際に別のサイトへ接続する状態になっていたことも明らかにしています。ここでは関連する情報をまとめます。 累計130万人登録のSNSに不正アクセス GMWが運営するサービスが不正アクセスを受け、pictBLandのサイトが一時改ざんされた他、データベース情報が外部に流出した可能性がある。サービスの累計登録者数は約130万人で、今回の不正アクセスによる影響を受けたアカウントの件数は約80万件。*1 不正アクセスとの関連があったとみられる事象が複数確認されており、それらは以下の通り。今後デジタルフォレンジックを行う企業へ調査を依頼することで影響範囲の特定を行うとしてお

                                          不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog
                                        • おすすめ.ssh/config設定 - 2023-04-03 - ククログ

                                          はじめに つい先日、GitHubのRSA SSHホスト鍵が突如差し替えられるという一件がありました。 We updated our RSA SSH host key 詳細に関しては識者による解説に委ねますが、ちょうどタイムリーな話題だったので、SSHをより安全に利用するという観点でおすすめ設定についていくつか紹介します。 なお、クリアコードではSSH以外にもおすすめzsh設定やおすすめEmacs設定という記事も公開しているので参考にしてみてください。 2023年5月11日更新:StrictHostKeyCheckingをyesにする場合の安全なknown_hostsの更新方法について追記しました。 おすすめ設定について クリアコードでは、.ssh/configのおすすめ設定を https://gitlab.com/clear-code/ssh.d にて公開しています。 これは、社内で.ss

                                            おすすめ.ssh/config設定 - 2023-04-03 - ククログ
                                          • メールアドレスをハッシュ化したものを公開してもよいのか - しまたろさんの掃き溜め

                                            注意 この記事は攻撃の実行を教唆する目的で書かれたものではなく、特定の状況におけるセキュリティ上の問題点を指摘するために公開しているものです。この記事に書かれた内容を実行して発生した結果について、筆者は一切の責任を負いません。 はじめに インターネット上で他人のメールアドレスをmd5で二重ハッシュしたものを公開されている方を見かけたため、解析する実験を行いました。 メールアドレスのユーザー名部分は多くの場合小文字のアルファベットと数字のみ(36文字)のそれほど長くない列で構成されており、ブルートフォース攻撃(総当り攻撃)によって簡単に特定できてしまうと考えられます。 またドメイン部分に関しても、一般の方が使うメールプロバイダが限られていることを考慮すると、サイズの小さい辞書でも十分な確率で当たるものと考えられます。 実験 今回はhashcatという、GPUでハッシュ値を解読するソフトウェア

                                              メールアドレスをハッシュ化したものを公開してもよいのか - しまたろさんの掃き溜め
                                            • Smoozユーザーデータの取り扱いに関する調査結果とお詫び – Smooz Blog

                                              当社開発のウェブブラウザ「Smooz」におけるユーザーデータの取り扱いについて、ご利用者の皆様、関係者の皆様に、多大なるご迷惑とご心配をお掛けしておりますことを深くお詫び申し上げます。当社では2020年12月23日に「Smoozのサービス終了」についてブログにてご案内させていただきました。その後Smoozにおけるユーザーデータの取り扱いに関して、外部専門家とともに調査を実施しましたので、その結果についてご報告申し上げます。 記 Smoozで取得していたユーザーデータについてユーザーデータの取扱いにおける問題点(1) ユーザーデータの容易照合性(2) 本文における個人情報の混入可能性(3) 第三者への行動履歴情報の提供(4) 適切な情報開示の不足本件の対応と再発防止策(1) サービスの終了とデータの削除(2) 外部専門家による監査 1.Smoozで取得していたユーザーデータについて Smoo

                                              • 【連載】世界一わかりみが深いコンテナ & Docker入門 〜 その6:Dockerのファイルシステムってどうなってるの? 〜 | SIOS Tech. Lab

                                                説明だけではわかりにくいと思いますし、私も最初この説明だけでは全くわかりませんでした。なので、実践してみたいと思います。以下のような構成をもとに、実際にOverlayFSを構築します。upperdirはここでは使いませんし、一旦その存在を忘れてもらってOKです。OverlayFSはややこしいので、順を追って説明していきます。 lowerdirに相当する2つのディレクトリ「lower01」「lower02」、upperdirに相当するディレクトリ「upper」、mergeddirに相当するディレクトリ「merged」 を作成します。 期待する動きとしては、lower01ディレクトリにあるhoge.txt(中身はhogeと書いてある)と、lower02ディレクトリにあるfuga.txt(中身はfugaと書いてある)の両方のファイルがmergedディレクトリに表示されるというものです。upper

                                                  【連載】世界一わかりみが深いコンテナ & Docker入門 〜 その6:Dockerのファイルシステムってどうなってるの? 〜 | SIOS Tech. Lab
                                                • 2024年のCSSの書き方、ワークフローとツールについて

                                                  CSSには大きく変わるタイミングが何度かありました。レスポンシブ対応、メディアクエリ、Flexbox、CSS Gridなどはその大きく変わったタイミングでしょう。 そして、2024年もこれらと同様に大きく変わりそうです。CSSのネスト、:has()疑似クラス、subgrid、コンテナクエリ、ビューポート単位などの新機能がすべてのブラウザにサポートされました。 2024年のCSSの書き方として、より保守しやすいCSS、ワークフロー、ツールについて紹介します。 How I'm Writing CSS in 2024 by Lee Robinson 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに デザインの制約 2024年のCSS お勧めのCSSツール 終わりに はじめに 2024年のCSSは、素晴らしいの一言に尽きます。

                                                    2024年のCSSの書き方、ワークフローとツールについて
                                                  • 値オブジェクト(Value Object)は3種類ある - パンダのプログラミングブログ

                                                    Value Object(値オブジェクト)は3種類あった Value Object(値オブジェクト) の意義と使い所がわからなかった。そこで調べてみたらなんと3種類あった。面白かったのでその調査過程を紹介する。 なお、現在では DDD の意味での Value Object がメインであること、またこれは自転車置き場の議論であり、DDD Quickly の Value Object の章を読む方が有意義であることを先に記しておく。 1. Data Transfer Object 1つ目は、Data Transfer Object(DTO)の意味だ。これは PoEAA に少しだけだけ出てくる。かつてのJava界隈の一部では(?)DTOのことを Value Object と呼んでいた。だが、現代では Value Object と DTO は別物として定着している。PoEAA は2000年代前半に

                                                      値オブジェクト(Value Object)は3種類ある - パンダのプログラミングブログ
                                                    • ウェブサイトのさまざまな「認証方式」をまとめて比較した結果がコレ

                                                      ユーザーごとに異なるデータを提供するため、ログイン機能を搭載しているウェブサイトは多数存在します。しかし、ユーザー側はウェブサイトに搭載されたログイン機能の「認証方式」まで気にすることはあまりないはず。そんなウェブサイトの認証方式について、代表的な6つの方式をエンジニアのAmal Shaji氏が解説しています。 Web Authentication Methods Compared | TestDriven.io https://testdriven.io/blog/web-authentication-methods/ ◆ベーシック認証 HTTPの中に組み込まれているベーシック認証は、最も基本的な認証方式です。ベーシック認証に暗号化機能はなく、Base64でエンコードされたユーザーIDとパスワードをクライアントからサーバーに送信するとのこと。 認証フローはこんな感じ。まずクライアントはサ

                                                        ウェブサイトのさまざまな「認証方式」をまとめて比較した結果がコレ
                                                      • 不正アクセスによるPeatixの情報流出についてまとめてみた - piyolog

                                                        2020年11月17日、Peatix Japanは米本社(Peatix.Inc)が提供するイベント管理サービス「Peatix」が不正アクセスを受け、登録されていた利用者情報が取得されたと発表しました。ここでは関連する情報をまとめます。 最大677万件のデータ流出 peatix.com 【Peatix不正アクセス事象】よくいただくご質問とその回答 [PDF] 弊社が運営する「Peatix」への不正アクセス事象に関するお詫びとお知らせ Peatix社が情報流出の可能性を把握したのは2020年11月9日頃。 外部企業による調査の結果、2020年10月16日~17日にかけて不正アクセスが同社サービスに行われていた。 登録されていた個人情報を含む利用者情報が最大約677万件不正に取得された事実が判明。 2020年11月17日発表時点で調査中。新事実等判明次第公表。 同社は今回の流出に関係する二次被害

                                                          不正アクセスによるPeatixの情報流出についてまとめてみた - piyolog
                                                        • 特定のページが更新されたら通知する仕組みを作ってみた - Qiita

                                                          はじめに RSS対応のサイトだと、更新情報追いやすいけど、RSS非対応のページも追いたいよね。って人向けの記事です。 RSS対応しているサイトなら、RSSリーダーを使った方が早いです また、Discordのチャンネルにも通知がしたかったので、メールとDiscord両方に通知を行っています。 Discord側にWebhook用のURLが必要ですが、本記事では紹介しません 参考サイトのZennの記事が細かく書かれていますので、そちらをご覧ください なお、この仕組みは更新を検知したいサイトに確認リクエストを送ります。 高頻度で設定してしまうと、サーバーに負荷がかかる為、 高頻度での設定はしないようにお願いします 参考サイト 構成図 コードについて(Lambda) コードについては、基本的に、クラスメソッドさんの記事を参考にしています Discordの通知部分については、AmazonBedrock

                                                            特定のページが更新されたら通知する仕組みを作ってみた - Qiita
                                                          • 【認証】JWTについての説明書

                                                            はじめに この記事を読んでいるあなたはJWTについて知っているだろうか?JWTは、認証されたユーザを識別するために最も一般的に使用される。JWTは認証サーバから発行されて、クライアント・サーバで消費される。 今回の記事では、Webアプリケーションの認証方法として最も利用されているJWT認証を簡潔に解説する。 本記事の読者の対象 JWT認証について知らない人 JWTのメリット・デメリット、仕組みについて詳しく知りたい人 アプリケーションの認証方法について詳しく知りたい人 JWTとは JSON Web Token(JWT)とは、クライアント・サーバの間で情報を共有するために使われる規格の1つである。JWTには、共有が必要な情報を持つJSONオブジェクトが含まれている。さらに、各JWTはJSONのcontentsがクライアントあるいは悪意のあるパーティによって改ざんされないように、暗号(ハッシュ

                                                              【認証】JWTについての説明書
                                                            • 開発者の日々の作業をサポートする様々なミニツールを集約したオープンソースのデスクトップアプリ・「DevToys」

                                                              DevToysは開発者の日々の作業をサポートする様々なミニツールを集約したオープンソースのデスクトップアプリです。Windowsエコシステムを採用するように設計されており、Windows 10のビルド1903以降で動作するそうで、Windows専用のアプリとなっています。 JSONのフォーマット、テキストdiff、RegExpのテスト、base64のエンコーダー/デコーダー、ハッシュ化ツール、 UUIDジェネレーター、loremipsumツール、JSON⇔Yaml変換、カラーシミュレーター、PNGとJPGのコンプレッサー、Markdownプレビュー、HTMLやURLのエンコーダー/デコーダーなどが1つのアプリにまとめられています。 また、クリップボードのデータを扱えるようになっており、作業を円滑に進める事が出来ます。勿論オフラインで動作しますし、OSSなのでアプリを加えたり日本語化も可能で

                                                                開発者の日々の作業をサポートする様々なミニツールを集約したオープンソースのデスクトップアプリ・「DevToys」
                                                              • EU主要機関の欧州議会、ビットコインの利用禁止へ | サステナビリティ×ブロックチェーン情報メディア【HEDGE GUIDE Web3】

                                                                ドイツの暗号資産メディアBTC-ECHOによると、欧州連合(EU)の立法府である欧州議会が2月23日、ビットコインをはじめとするProof of Work(PoW)型暗号資産の利用を禁止する方向で動いていることが明らかとなった。(編集部注釈:最新の状況については下記記事リンクをご覧ください。) EU議会、ビットコインの利用禁止を草案から削除 EUが提言する、暗号資産の規制をまとめた最終草案「Markets in Crypto-Assets(MiCA)」内には、環境的に持続不可能なコンセンサスアルゴリズムを利用する暗号資産を禁止する規定が明記されている。具体的には、ビットコインなどのPoW型暗号資産が該当する。 PoWとは、ブロックチェーンに取引記録などが保存された新たなブロックを追加する上で必要な作業のことを指す。ブロックチェーンの各ブロックをハッシュ化した際に、生成されるハッシュ値の先頭

                                                                  EU主要機関の欧州議会、ビットコインの利用禁止へ | サステナビリティ×ブロックチェーン情報メディア【HEDGE GUIDE Web3】
                                                                • 【Power Automateの新しいRPA機能】Power Automate Desktopで出来ること(全33機能の紹介) - Qiita

                                                                  【Power Automateの新しいRPA機能】Power Automate Desktopで出来ること(全33機能の紹介)RPAPowerAutomateDesktop はじめに Microsoft Igniteの発表でPower Automateの「per user with attended RPA plan」で「Power Automate Desktop」が使用できるようになりました。2020年9月26日時点でPreview機能です。 この記事ではPower Automate Desktopの自動化機能(アクションと言います)を紹介します。 この紹介を通じPower Automate Desktopがどのような自動化を行えるかの参考になれば幸いです。 2020年9月26日時点のアクションとなります。 トライアル開始手順もまとめてみましたので併せてご覧ください。 【Power A

                                                                    【Power Automateの新しいRPA機能】Power Automate Desktopで出来ること(全33機能の紹介) - Qiita
                                                                  • 未ログインでも叩けるAPIエンドポイントにレートリミットを導入する

                                                                    先日だれでもAIメーカーというWebサービスをリリースしました。このサービスは例によってOpenAI APIを使っており、トークンの使用量がランニングコストに大きく影響します。 また、気軽に使ってもらえるよう未ログインでも使用できる仕様にしているため、気をつけないと悪意のある人に大量にトークンを使用されてしまう可能性があります。 ノーガードだとどうなるか 例えば、POST /api/askという「リクエストbodyのpromptの値を取り出し、OpenAI APIのChat Completionsに投げる」という単純なエンドポイントを作ったとします。 「未ログインでも使ってもらいたいから」と認証を一切しなかった場合どうなるでしょうか? 悪意のある攻撃者に見つかれば、promptを上限ギリギリの長さの文章に設定したうえで、/api/askに対してDoS攻撃するかもしれません。 トークンを大量

                                                                      未ログインでも叩けるAPIエンドポイントにレートリミットを導入する
                                                                    • pixivに脆弱なパスワードで登録できないようにしました - pixiv inside

                                                                      図1: 脆弱なパスワードを入力した場合のエラー画面 こんにちは、pixiv開発支援チームのmipsparcです。 パスワード、もしかして使いまわしていますか? 複数のサービスで同じパスワードを利用していると、「パスワードリスト型攻撃」によって不正アクセスの被害を受けてしまうかもしれません。 パスワードリスト型攻撃の被害にあわないためには、ブラウザやパスワード管理ツールで自動生成された安全なパスワードを利用するのが好ましいです。 しかし、実際には多くの人が「使いまわしたパスワード」や「簡単なパスワード」(以下、脆弱なパスワード)を利用していますし、啓蒙活動にも限界があります。 pixivではサイバー攻撃への対策を複数とっていますが、根本的な対策のひとつとして、脆弱なパスワードを新しく設定できないようにしました。 脆弱なパスワードの判定方法 脆弱なパスワードの利用はどのように防ぐことができるで

                                                                        pixivに脆弱なパスワードで登録できないようにしました - pixiv inside
                                                                      • Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した

                                                                        症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント

                                                                          Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
                                                                        • postfixによる大量メール送信にまつわる問題と対処 - エムスリーテックブログ

                                                                          【SREチーム ブログリレー2回目】 お疲れ様です。エンジニアリンググループ、コアSREの山本です。 前回ブログリレー1回目の記事で大量メール送信のために基本設定について書かせていただきました。 www.m3tech.blog 今回はそれを受けて構築したサーバで実際に発生したいくつかの問題、その問題への対処といったものを書かせてください。 エムスリーのメール送信で発生した問題とその対策 特定のメールサーバからの突然のメール拒否 メールの翌日までの滞留 TLS問題 メールがどうしても迷惑メール扱いされるという苦情 postfixのメール処理とステータス メールログの監視 まとめ We are Hiring! エムスリーのメール送信で発生した問題とその対策 実際にここ一年あたりの間に発生した問題とその問題への対応を記述していきたいと思います。postfixを利用して送信していますので設定はpo

                                                                            postfixによる大量メール送信にまつわる問題と対処 - エムスリーテックブログ
                                                                          • ドメイン駆動設計(DDD)を整理

                                                                            またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆

                                                                              ドメイン駆動設計(DDD)を整理
                                                                            • サーバーセキュリティ構成の話 - Chienomi

                                                                              序 最近、安易に建てられた危険なサーバーが増えているため、サーバーセキュリティを鑑みた基本的な設定や構成はどういうものかという話をする。 本記事では具体的な設定や構築を説明するが、環境や前提、用途などもあるため、これを真似すれば安全ということではない。 セキュリティは銀の弾丸があるわけではなく、全ての要素を合わせて考えたア上での最適を導かねばならない。それがセキュリティの難しいところでもある。 本記事はセキュリティが未熟だと自認する人にとっては参考になる内容だと思うが、どちらかというと、本記事の内容が当たり前に「すでに理解できている内容」になっていない人は、サーバーを建てるべきではない(危険な未熟の段階である)ということが重要であり、各々が自身の技量を測る指標として使ってもらえればと思う。 宣誓の儀 「サーバーを破られるということは、すなわち犯罪に加担するということである」 この言葉をしっ

                                                                              • 外部向けAPIプラットフォームの設計について - NearMe Tech Blog

                                                                                はじめに NearMeでは最近、相乗り配車サービスのための外部向けAPIプラットフォームを構築しました。 これにより、他アプリからシームレスに注文したり、Lineミニアプリのような新しいチャネルのUIを独自に構築することを可能にしました。 その設計においては様々な考慮が必要でしたので、ここにまとめたいと思います。 提供方法 APIを利用するにはまず、外部連携先の"組織"を作成し、登録した"組織"で「〇〇 地域シャトル」「〇〇スクール送迎」などの"サービス"を作成します。これにより、ユーザー管理、車両管理、注文管理などが管理画面から利用できるようになります。マルチテナント方式なので専用の"サービス"が構築されます。 次に、API連携に関する基本情報を格納する"アプリケーション"という項目を作成します。 認証情報やWebhookのURLなどもここで設定します。 この"アプリケーション"のIDが

                                                                                  外部向けAPIプラットフォームの設計について - NearMe Tech Blog
                                                                                • ニコニコ「ダークウェブの情報をDL・拡散しないで」 ウイルス感染や違法の可能性

                                                                                  KADOKAWAグループがランサムウェアを含む大規模なサイバー攻撃を受け、ドワンゴの全従業員の個人情報や、一部の取引先情報などが漏えいした問題で、犯人グループがダークウェブに公開したとみられる漏えい情報を取得し、ネット上に公開するユーザーが現れている。 ドワンゴは6月28日、「興味本位でこれら(漏えい情報)をダウンロードする行為は、ウイルス感染などの危険があるだけなく、違法である可能性が高い」とニコニコの公式Xで指摘。ダウンロード・拡散を控え、ダウンロードした場合は削除するよう呼び掛けた。 また、「ニコニコアカウント」のパスワードについては、「システム内でハッシュ化されてから保存しているため、仮に流出していたとしてもすぐに悪用される可能性は低い」と説明。念のため、ニコニコアカウントと同じパスワードを他サービスでも利用している場合はあ、パスワードを変えるよう呼び掛けている。 関連記事 ニコニ

                                                                                    ニコニコ「ダークウェブの情報をDL・拡散しないで」 ウイルス感染や違法の可能性