ログイン時のユーザーテーブルについて、氏名とパスワードが同一のユーザーが複数存在した場合の対応

Question

前提

以下のテーブル定義を基に質問させて頂きます。

なお、本質問は以下URLの質問内容が曖昧になってしまったため作り直した質問となります。
https://teratail.com/questions/376003

状態

スマホアプリを作成しており、ログインシステム実装のためユーザーテーブルを設計しています。

知りたいこと

この定義ではメールアドレスの情報からユーザー名やパスワードが同一でも、ログイン時に正しいユーザーでログインできると思います。

しかし、作ろうとしているスマホアプリではメールアドレスの情報はいらないため、できれば使いたくないと考えています。
また、ユーザー名やパスワードは一意制約などを設けずに、自由に設定したいと考えています。

メールアドレスをユーザーテーブルに含まずに、ユーザー名やパスワードが同一でもログインする時に正しいユーザーでログインする方法を知りたいです。

よろしくお願いいたします。

Comments

[hoshi-takanori]

スマホアプリの場合、ログインというか初回利用時に一意な ID (質問者さんのユーザーテーブルのユーザー ID とか) を割り当てれば (悪用防止のためにトークン的なものを付与することになりますが)、パスワードさえも不要にできないことはないです。ただし、機種変更などの対応が面倒くさくなりますが。

また、パスワードをユーザーを特定するための情報の一部として使うのは間違いです。そもそもパスワードは平文 (そのままの値) ではなく、ハッシュ化して保存する必要がありますが、その際に乱数 (ソルト) を加えるので同じパスワードでも DB 上は異なるデータになります。

[退会済みユーザー]

前のスレッド https://teratail.com/questions/376003 の仕切り直しですよね。その事を質問欄を編集して前のスレッドの url と共に書いてください。

[SZR0601]

hoshi-takanoriさん
ご回答いただき、ありがとうございます。
確かにパスワードはハッシュ化するからユーザー特定情報にはできませんね。

一意のIDは端末にファイルとして保存する認識であっていますか。
お手数ですが、ご回答いただければと存じます。

[SZR0601]

SurferOnWwwさん
前の質問ではお世話になりました。
上記内容について対応いたしました。

Answer 1

ユーザー名やパスワードは一意制約などを設けずに、自由に設定したい

前のスレッドと同じことを書きますが、そういうのは一般的ではない、と言うより認証システムとしてあり得ない思います。少なくともユーザー名は一意にしないと。

認証というのは「あなたは誰？」という問いかけに答えてもらって、誰だかを明確にするものです。

同じユーザー名同じパスワードの人が複数いては、認証システムが成り立ちません。

Comments

[SZR0601]

前の質問から引き続きご回答いただきありがとうございます。

基本的にはメールアドレスなどの一意になり得る情報を使ってユーザーテーブルを構成するという事ですね。

[退会済みユーザー]

いや、メールアドレスでなくユーザー名を一意にすれば良いと思いますが。そもそもメールアドレスは含めたくないのですよね？

Answer 2

ログインの処理で受け取る情報のなかに一意性のあるものが含まれないと、一意にユーザーを決定するのは不可能だと思います。

Comments

[SZR0601]

ご回答いただきありがとうございます。

やはりそうですよね。
データベースの情報でログインする方式で進める際は、メールアドレスを使うことを検討します。

Answer 3

スマホアプリを作成しており、ログインシステム実装のためユーザーテーブルを設計しています。

スマホアプリであれば、デバイスに一意の識別子を振ってしまえばよいです。
事実上、デバイスに振られた ID + パスワードの認証となり、端末変更時に一定の手順を踏む必要が出てきますが、まぁスマホであればそれほど違和感のない実装だと思います。

Comments

[SZR0601]

ご回答いただきありがとうございます。

デバイスに一意の識別子を振るという点で、2点質問させてください。
１.DBに端末IDカラム等を設けて、割り振った一意の識別子をそのカラムに登録していく認識であっていますか？
２.[一意の識別子をデバイスに割り振る]＝[デバイスに一意の識別子をファイルとして保存する]という認識であっていますか？

お手数ですが、ご回答いただければと存じます。

[退会済みユーザー]

１ はDB を前提とするなら PK として作り直すなり id を置き換えるなり、カラムを追加するなり好きなようにすると良いと思います。ただ、PK として使用するならそれなりの覚悟（と設計）が必要ですね。
2 はデバイス向けの開発ツールの機能に従うのが良いと思いますよ。

[SZR0601]

ご回答いただきありがとうございます。

上記の内容で進めてみようと思います。

Answer 4

ただ単に設計を間違えているだけです。
Googleアカウント認証を使えばいいと思います。

Comments

[qqfsdfsafd]

低評価したやつ頭大丈夫か？

[SZR0601]

ご回答いただきありがとうございます。

Googleアカウント認証について、勉強します。

[YT0014]

設計に問題があるとの指摘は理解できますが、"Googleアカウント認証"への移行を勧める必然性が理解できません。
ユニークなキー(メールアドレス)を持てば、現状のシステムの流用でログインができると読めますので、それを排するべき理由の記述が必要と思われます。