base64_encodeの奇妙な動作

StackOverflow https://stackoverflow.com/questions/213683

  •  03-07-2019
  •  | 
  •  

質問

次のようなことをしています：

SELECT * FROM table WHERE user='$user';
$myrow = fetchRow() // previously I inserted a pass to the db using base64_encode ex: WRM2gt3R=

$somepass = base64_encode(
次のようなことをしています：


<*>


常にエラーが発生します。$ somepassと$ myrow [1]は同じですが、それでもエラーがエコーされます。私は何を間違えていますか？ありがとう
POST['password']);

if($myrow[1] != $somepass) echo 'error';
else echo 'welcome';

常にエラーが発生します。$ somepassと$ myrow [1]は同じですが、それでもエラーがエコーされます。私は何を間違えていますか？ありがとう

役に立ちましたか？

解決

エコーの代わりに var_dump を使用してみてください-そのうちの1つに開始/終了にスペースまたは改行が含まれている可能性があります。

編集：

CHAR（40）として保存する必要があります：保存時に指定された長さまで常にスペースで右詰めされる固定長文字列

VARCHARまたは trim（）

を使用

他のヒント

$ myrow [1]が実際にbase64-encodingの正しいパスワードである場合、エラーは表示されません。

最後にこのindを試してください：

echo "<br />$myrow[1] != $somepass";

何と言っていますか

ところで、パスワードをbase64でエンコードする理由は見当たりません。何を達成しようとしていますか？

どういうわけか、var_dump（）を実行すると次のようになります。

string（40）＆quot; YWRraM2 =＆quot; string（8）＆quot; YWRraM2 =＆quot;

コンソールを使用してデータベースにデータを挿入すると、パスフィールドに余分なスペースが追加されるように見えます。

myplacedk：実行すべきでない理由はありますか？セキュリティがさらに強化されると思いましたか？

このエンコードは2つのことを行います：

  1. コードを追加し、より複雑でエラーを起こしやすくします
  2. データベースを画面で表示し、誰かが肩越しに見ている場合、パスワードを覚えるのが少し難しいかもしれません。

いいえ、実際にはセキュリティは追加されません。これは単なるエンコードであり、簡単にデコードできます。

md5ハッシュなどと間違えているのかもしれません。

遊び回るのは素晴らしいことですが、セキュリティに関しては、理解できないものを使用しないことをお勧めします。長い目で見れば、それは良いよりも多くのダメージを与えるでしょう。

いくつかの問題：

  • 他の場所のコメントから、現在のコードの問題は、データベースフィールドがCHAR（40）であることだと思います。 CHARフィールドは常に固定サイズです。データベースフィールドタイプをCHARではなくVARCHARに変更してみてください。

  • データベースに保存する前にbase64_encodeを使用することは、安全ではありません。パスワードの片方向ハッシュのみをデータベースに保存することをお勧めします-通常はmd5または（より良い）sha1です。次に、ユーザーがログインするときに、指定されたパスワードで同じハッシュ関数を使用し、2つのハッシュを比較します。
    これには、40文字を超えるパスワードも使用できるという追加の利点があります。
    sha1またはmd5-hashは常に一定の容量を必要とするため、この方法を使用する場合、データベース列をVARCHARに切り替える必要はありません：

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top