4 ポイント 投稿者 GN⁺ 2024-01-01 | 1件のコメント | WhatsAppで共有

メールアドレスはアカウントの「永続的」識別子として適していない

  • メールアドレスをアカウントの永続的な内部識別子として使うのは問題がある。人のメールアドレスは、組織内であっても変わることがあり、これは名前やログイン情報が変わるさまざまな理由と同様である。
  • 組織が人に割り当てたメールアドレスを変更したり再設定したりしないことは、法的に持続可能ではない可能性がある。
  • メールアドレスが再利用されたり、特定の人物に再割り当てされたりする可能性があり、これはセキュリティ上の問題を引き起こしうる。

内部識別子は意味を持たせるべきではない

  • アカウント復旧のためにメールアドレスを覚えておく必要があるとしても、内部アカウント識別子は意味のないものであるべきだ。これは長期的にシステム管理を簡素化する。
  • OIDC のような認証システムでは、メールアドレスの代わりに一意で永続的な内部 ID を使うべきである。
  • メールアドレスに過剰な意味を持たせることは、セキュリティ上の問題を招く可能性がある。

GN⁺の見解

  • この記事で最も重要なのは、メールアドレスを永続的なアカウント識別子として使うことが、さまざまな問題を引き起こしうる点である。
  • この話題が興味深い理由は、多くのシステムがユーザー認証のためにメールアドレスを使っている一方で、この記事がそうした慣行には潜在的なセキュリティリスクや運用上の問題があることを指摘しているためである。
  • この記事は、ソフトウェアエンジニアが内部システムを設計する際に考慮すべき重要なセキュリティ面および運用管理面への認識を高める助けになる。

1件のコメント

 
GN⁺ 2024-01-01
Hacker Newsの意見
  • メールアドレスとユーザー名の限界

    • メールアドレスは変更される可能性があり、以前のメールへのアクセスを失うこともある。
    • ユーザー名への不満もあり、人々は固有でない名前を選びたがる。たとえば user53267 のような名前ではなく。
    • デバイスを紛失することもあり、Cookieに保存された秘密のUUIDやデバイスのパスキーだけでは十分ではない。
    • メールアドレスやユーザー名が安定している人もいるが、同じ主要デバイスを何年も使い続ける人はほとんどいない。
    • 業務用メールアカウント(first.last@company.com)や、ベンダーソフトウェアが「Googleでログイン」を使う方式では問題が頻繁に発生する。
    • 人は結婚し、離婚し、性別移行をし、文化を移り、新しい名前を選ぶ。名前とメールアドレスは変わる。
    • OIDCのようなものには、ユーザー名とメールアドレスを変更できる標準APIが必要かもしれない。
  • 個人的な対処法

    • GmailはAIアルゴリズムによって恣意的にロックされる可能性があり、問題が起きても救済を受けにくい。
    • Yahooは古いメールでの認証を要求し、アクセスを失うことがある。
    • Yahoo/AOL/Tutanota/Protonmailなどは、頻繁にログインしないとアカウントを自動削除することがある。
    • セルフホスティングには最初のメールが必要で、それを失うとホスティングアカウントへのアクセスも失う可能性がある。
    • Duo pushは、電話機が故障したときに問題になりうる。
    • SMS認証は、電話機の故障、プランへのアクセス喪失、従業員のセキュリティ問題などにより危険になりうる。
    • 大学のGmailアドレスを使うのが、今のところ最善の方法に見える。問題が起きたときに大学のサポートセンターへ助けを求められるからだ。
  • メールアドレスと電話番号の問題点

    • メールは永続的な識別子として適しておらず、識別の一部として電話番号を使うのはさらに悪い。
    • 自分のドメインを通じてほぼ20年間同じメールを使ってきたが、同じ期間に電話番号はほぼ12個も変わった。
    • 海外在住中も米国番号を維持するために、AT&Tへ毎月約150ドルを支払っている。
  • 公開鍵メールアドレスの提案

    • 公開鍵メールアドレス(<pk-12345@gmail.com>)をサポートするアイデアの提案。
    • GoogleやHotmailがサービスを終了しても、別のサービスで秘密鍵により認証して同じアカウントへアクセスできる。
    • メールクライアントがこうしたアドレスをマッピングしたり、公開鍵で追跡できるようにする。
    • このアイデアには大規模な対応が必要だが、考えてみる価値はある。
  • UUIDの使用

    • ランダムなUUIDが最善だという意見。
    • ユーザーの最初のメールをハッシュ化する方法は、ソルトだけでは十分でないかもしれない。
  • 複数メールアドレスの連携

    • アカウントに複数のメールアドレスを紐付けられるよう、メールシステムを変更中である。
    • 学生割引を提供するには教育用メールを確認するのが最も簡単だが、ほとんどの人はそのメールで登録したがらない。
    • 複数メールを許可することで、両方の長所を得られる。
  • メールアドレスと物理的住所の結び付きの問題

    • 1つのメールアドレスを複数の物理的住所で使えないようにしている電力会社の例。
    • オンラインアカウントを設定するときに同じメールアドレスを使えず、問題が発生する。
  • クライアント側ソリューション

    • ドメイン料金を支払うことで、メールエイリアスを100%制御できる。
    • 現在のプロバイダー(Google)に問題が起きても、自前サーバーでメールをホストしてアカウントを検索し、エイリアスの所有権を維持できる。
  • 識別と認証の問題

    • 識別と認証を混同して議論している問題がある。
    • 識別の問題は、名前、メール、身分証明書など、人間に結び付いた固有の文字列や数字によって事実上解決される。
    • 認証の問題は、実際にその人が誰であるかを確認することであり、現代技術が直面する最大の問題の1つである。
    • パスワード、地理的位置、IPアドレス、メール、電話番号、セキュリティトークン、証明書の組み合わせを使うが、これらのシステムは定期的に侵害され、セキュリティを強化すると正当なユーザーに悪影響が及ぶ。
  • バックエンドの問題

    • ユーザーにとってはメールがIDだが、システムデータ内ではメールを主キーとして使うべきではない。
    • これはデータベース設計の基本的な問題で、メールのような識別子を使わず、一意なID(UUIDまたはシーケンスからの自動増分)にマッピングするルックアップテーブルを持つべきである。
    • 記事はこの区別を明確にしておらず、ユーザーがこの抽象化を認識すべきだというふうにも読めてしまう。