2016-03-30 1 views
1

原因:私はテーブルを持っており、列はすべて適切にCollated MySQLの大文字と小文字の区別(またはそれ以外の場合は、MySQLのでパスワードを正しく保存する方法)

utf8mb4_unicode_ciとして
CREATE TABLE IF NOT EXISTS `users` (
    `user_id` int(8) NOT NULL AUTO_INCREMENT, 
    `username` varchar(100) NOT NULL, 
    `pass_word` varchar(512) NOT NULL , 
    ...etc etc... 
    PRIMARY KEY (`user_id`), 
    UNIQUE KEY `email_addr` (`email_addr`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=989 ; 

ある

... $2y$14$tFpExwd2TXm43Bd20P4nkMbL1XKxwF.VCpL.FXeVRaUO3FFxGJ4Diのようなパスワードハッシュ(password_hashから生成)を格納する列を含む。

しかし、私は$2y$14$tFpExwd2tXm43Bd20P4NKmbL1XKxwF.VCpL.FxEVRaUO3FFxGJ4DIのハッシュは、まだアクセスを可能にすること、により列の場合鈍感にそれを見つけます。

これは、大文字と小文字を区別しないでデータを格納することによって可能性のある数百の衝突が発生する可能性があることを意味します。良くない。


ISSUE:

は今、比較を行う際に、大文字と小文字を区別列としてpass_word列を処理するためにMySQLを強制する方法はあります。私はPHP/SQLのクエリのすべての出現を編集することを避けたいだけでなく、大文字と小文字を区別して比較するデータベーステーブルの列を設定するだけですデフォルトではです。

文字セットでは_csのオプションが表示されず、_ci以外のオプションはutf8mb4_binと表示されます。

だから、簡単な質問:

  • UTF8mb4_bin文字が敏感に標準比較ケースを扱うMySQLの上&照合を設定していますか? [yes]
  • 私がやりたいことをUTF8mb4_binに書いてください。別のセットを使うべきですか?あれば、なぜですか?
  • password_hashの出力をMySQL utf8mb4_bin列に格納する際に問題はありますか?
  • このアプローチは、各ログインクエリのクエリSQLを編集する必要性を回避するのに便利ですか?列のタイプを変更して次に進むことはできますか?

EDIT

nj_で詳述されているように、これはログイン時にpass_wordの値を直接編集されることはありませんので、全く問題ではありません愚かな問題である。 ...それはです長い一日だった。

+0

私はこの "コラム"ビジネスで非常に混乱しています。 "私は列でいっぱいのテーブルを持っています。" - それはテーブルの定義ですが、これ以外に何を意味していますか? 「パスワードハッシュを格納している列を含める」 - これが何であるか、なぜそれをやっているのかを明確にすることができますか? –

+0

私は私の開幕を明確にしました。 'pass_word'カラムはハッシュデータを大文字と小文字を区別しない文字列として格納しています@DigitalChris – Martin

+0

' SELECT * FROM users WHERE username = "" AND password = "" 'は' password_hash() 'の出力です。そうであれば、それはうまくいかないでしょう。あなたは 'password'ハッシュをつかんで[password_verify()](https://secure.php.net/manual/en/function.password-verify.php)を呼び出す必要があります –

答えて

1

あなたが本当にあなたの62^55のアドレス空間の潜在的な2^55の衝突について、その心配している場合、あなたは単に、常に大文字と小文字が区別され、BLOBに列タイプを変更することができます。

CREATE TABLE IF NOT EXISTS `users` (
    `user_id` int(8) NOT NULL AUTO_INCREMENT, 
    `username` varchar(100) NOT NULL, 
    `pass_word` BLOB NOT NULL , 
    ...etc etc... 
    PRIMARY KEY (`user_id`), 
    UNIQUE KEY `email_addr` (`email_addr`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=989 ; 

例:

INSERT INTO `users` (..., `pass_word`) VALUES (..., 'AbC');

SELECT * FROM `users` WHERE `pass_word` = 'AbC' LIMIT 0,1000; - > 1ヒット

SELECT * FROM `users` WHERE `pass_word` = 'abc' LIMIT 0,1000; - あなたが確認できないため> 0ヒット

+0

ああ、私は 'ブロブ'を考えていませんでした。私は、BLOB列型に変更すると、パスワード値をチェックするSQLの更新を必要としないと思いますか? – Martin

+0

あなたの編集は私のコメントに答えました。乾杯、 – Martin

+0

うん、コードを変更する必要はありません。 :-) –

1

大文字と小文字の区別は、この場合には問題はありませんとにかくSQLと直接パスワード。正しく塩漬けされたパスワードハッシュをデータベースで検索することはできません。ユーザ名で検索のみ、データベースから保存されたハッシュ値を抽出します。

$sql= 'SELECT * FROM users WHERE username = ?'; 
$db->prepare($sql); 
$db->bind_param('s', $_POST['username']); 

その後あなたが行からハッシュを抽出し、password_verify()関数で見つかったハッシュに対して入力されたパスワードを確認することができます。

// Check if the hash of the entered login password, matches the stored hash. 
// The salt and the cost factor will be extracted from $existingHashFromDb. 
$isPasswordCorrect = password_verify($password, $existingHashFromDb); 
+0

ええ、これはnj_のコメントの後に分かりました。要件に関係なく、ストレージが大文字と小文字を区別しないことを確認するビジョン。ありがとう。私は私の質問の一番下に編集を加えました。 – Martin

+0

@マーティン - ああ、本当に明白かどうかはわかりませんでした。おそらく答えを削除するでしょう。 – martinstoeckli

+0

あなたの答えを忘れないでください。私は本当に質問を削除する必要がありますが、それは答えを持っているとして私に反対して動作します。 – Martin

関連する問題