{モバイル向けURLにも埋め込み記法を適用してほしい}{👍}{埋め込みツイート}{Twitter}=}(4)
{【解決済み】最近レイアウト崩れが発生するようになった輪郭がある}{👍}=}(2)
{マイもしかして}{fetch()が返すもの}{＜ ﾃﾞｭﾌﾌ}{Promiss}{Promise}{👍}=}(6)
{フィールドの更新}{Update field}{マイもしかして}{〈btrfs〉}{👍}{＜ ほんまや}=}(6)

{もしかして: Update field K#D657/6B67}

余計なお世話だし口出しする必要ないかと思ったけど、将来の知名検索で困りそうだったから。

私もbtrfsで経験あり。brtfsにしてて知名検索を活用できなかった。

=}
{『t_wの輪郭』}{Google AdSense}{👍}{リリース}{Amazonアソシエイト}=}(5)
{トグルのわかりにくさ}{👍}{坂村 健『トロンヒューマンインタフェース 標準ハンドブック』}=}(3)
{抜け漏れ}{サービス運営}{パスワード漏洩時に利用者へ連絡}{パスワード漏洩}{メールアドレスはパスワード変更を促す通知手段としても使われる}{メールアドレスのハッシュ化にメールアドレスを用いれば、メールアドレスをキーとして扱えるかもしれない}{メールアドレスのハッシュ化に乱数のSALTを用いると、メールアドレスをキーとして扱えない}{メールアドレスもハッシュ化}{👍}=}(9)

{たしかに!! K#EDD2/20DF}

　パスワード漏洩時に利用者へ連絡する必要があるというのは、考えから抜けていました。確かにそういった場合もありますし、サービス運営を進めるうえで利用者へ連絡が必要な場面がほかにもあるだろうことを考えると、メールアドレスは平文で持っていたほうが良いと思えました。

　一人で考えていますと抜け漏れがありますので、意見を頂けるのは大変助かります。ありがとうございます！

=}
{O(1)}{O(N)}{ハッシュ化したメールアドレスをキーにするのも現実的ではない？}{あれ}{計算コスト}{メールアドレスもハッシュ化}{👍}=}(7)

{メールアドレスのハッシュ化に乱数のSALTを用いると、メールアドレスをキーとして扱えない K#EDD2/8CF4}

　私も当初よりハッシュ化したメールアドレスをキーにする方法を考えていたのですが、結論から言うと難しいです。おっしゃる通り、ハッシュ化したメールアドレスをキーにすれば一見問題ないように思えたのですが、以下の理由から低い計算コストで実現するのは難しいと判断しました。

  • メールアドレスをハッシュ化するSALTは値が毎回変わる
  • 「ハッシュ化したメールアドレス」と「メールアドレスをハッシュ化するSALT」のペアは利用者の数だけ存在する
  • そのため、「利用者認証時に入力されたメールアドレス」をハッシュ化する適切なSALTを、O(1)で見つける方法が存在しない
    • 以下の手順を用いれば計算コストO(N)で「利用者認証時に入力されたメールアドレス」をハッシュ化する適切なSALTを見つけることができる
      1. DBから全ての「ハッシュ化したメールアドレス」と「メールアドレスをハッシュ化するSALT」を取り出す
      2. 取り出した全ての「メールアドレスをハッシュ化するSALT」で、入力されたメールアドレスをハッシュ化する
      3. 「DBから取り出したSALTでハッシュ化したメールアドレス」と、「DBから取り出したハッシュ化したメールアドレス」を全て突合する
  • また、利用者登録時にもメールアドレスの重複を検査する必要があるため、『「利用者認証時に入力されたメールアドレス」をハッシュ化する適切なSALTを、O(1)で見つける方法が存在しない』という問題になる

処理の流れ

メールアドレスとパスワードを入力し、利用者を登録する（メールアドレス・パスワードをハッシュ化してDBに保存する）

  1. メールアドレス用のSALTを作成する
    • 作成するたびに値が変わる
    • mailaddress_salt_dbとする
  2. メールアドレスをハッシュ化する
    • mailaddress_hashed_dbとする
  3. パスワード用のSALTを作成する
    • 作成するたびに値が変わる
    • password_salt_dbとする
  4. パスワードをハッシュ化する
    • password_hashed_dbとする
  5. 利用者情報（mailaddress_hashed_db(主キー)、mailaddress_salt_db、password_hashed_db、password_hashed_db）をDBに保存する

メールアドレスとパスワードを入力し、利用者を認証する（メールアドレスでDBに保存したハッシュ化したパスワードを取り出し、入力されたパスワードと照合する）

  1. メールアドレス用のSALTを取得する
    • mailaddress_saltとする
    • ここで不都合が生じる。SALTは生成する度に値が異なる かつ 利用者情報のレコードが複数存在する 場合、DBに保存した際のメールアドレス用のSALTを計算コストO(1)で取得することができない。
  2. メールアドレスをハッシュ化する
  3. ハッシュ化したメールアドレスで利用者情報（ハッシュ化したメールアドレス、メールアドレス用のSALT、ハッシュ化したパスワード(password_hashed_dbとする)、パスワード用のSALT）を取得する
  4. 入力されたパスワードをDBのパスワード用のSALT でハッシュ化する(password_hashedとする)
  5. password_hashed_dbとpassword_hashedが一致していれば認証成功とし、一致していなければ認証失敗とする

=}(2){たしかに!!}{メールアドレスのハッシュ化にメールアドレスを用いれば、メールアドレスをキーとして扱えるかもしれない}
{画像の範囲を表わすURI要素}{サザエさんのEDを想起させるロゴ}{〈「サザエさん」〉}{〈GNU Health〉}{👍}{似ている}=}(6)
{< 受信側に残る通知ログについて教えてください}{私が絵文字を誤送信した時の応急処置}{Microsoft Teamsの絵文字リアクションを押すのが怖い}{👍}=}(4)
{👍}

{}