php safety, typecast password to string

Question

Question: Is it not secure to typecast a submitted Password to a string? $b =(string)$a;

Comment: I dont want to know about more performant ways, i just want a safe way. Just for the following usecase:

Step 1 - Register Password (PW):

Getting the PW by Registration,
Casting it to String
String to Hash
Save Hash in MYSQL

Step 2 - Loginform, get PW:

Getting PW via Form
Casting it to String
Getting Hash from Database
comparing Both

I guess it is the most simple way, but one of the safest. I want to allow EVERY Character for PW,

< / { } * #

and why not asian symbols. I thought: This method should not bring trouble with escapingproblems, as whatever was code, is now a string and is only compared with a string. But i can have every character, without danger. An Mysql database should allow every char when set to UTF8, right? So please answer me: Is this Idea to simpleminded?

Thank you in advance Gerd

Saving the hash reduces the stored password to a set of ASCII characters, but still allows any/every UTF-8 character as input from your login form — Mark Baker, Jan 06 '15 at 15:41
However, casting to a string is irrelevant, as all input from an HTML form will be string data — Mark Baker, Jan 06 '15 at 15:42
Rather than worrying about that, worry about using the most secure algorithm for the "string to hash" part of your logic: use [password_hash()](http://www.php.net/manual/en/function.password-hash.php) which will also ensure that it is a salted hash that is generated — Mark Baker, Jan 06 '15 at 15:43
Thanks Mark, but i disagree with the idea, that all Input comes from HTML Forms. I do not know every detail about hacking, but i know it is possible to send Data without using the Forms made for that purpose. Anyway, you agree it is not risky to do it my way? Even if it is not performant or irrelevant? — GGolem, Jan 06 '15 at 15:47
Irrespective of where the input comes from (forms, command line arguments, URL, JSON-encoded, CURL request) it's a string in PHP until you do something to change it — Mark Baker, Jan 06 '15 at 15:51
Right, if i use it in a function it can't go wild all by itself. So i hash it, within registration AND login and compare that, and not a malicious code which can go crazy. You really helped me out of my confusion! — GGolem, Jan 06 '15 at 16:01
@GGolem keep in mind that since you are _not_ hashing the username field, malicious input typed in there can still run amok. My answer below should only be considered an answer to your specific question (namely, the first line) — Jeff Lambert, Jan 06 '15 at 16:20
I think about - as performance isn't my main concern, to hash not only PW's but username, and realnames. But i will keep it in mind and search for a solution. I think for usernames i just use pregmatch() and allow only alphanumeric characters. Thank you both very much! — GGolem, Jan 06 '15 at 18:41

score 1 · Accepted Answer · answered Jan 06 '15 at 15:47

I don't believe casting the password to a string is going to affect the overall security of your application, either way. In that sense I think the question is a bit misguided.

As an example of why casting to a string doesn't really help you or hurt you, consider one of the most common vectors of attack against a database: SQL Injection. Set up a form on a web page that takes user input, POSTs it to a server side script that constructs queries with that user input and all of a sudden you're vulnerable. Since all SQL queries are strings, it won't matter much here if you cast to a string or not.

But what if you know that you need a string from a form (any form), and someone types an integer? Try this out..

Make a page with these contents:

<!DOCTYPE html>
<html>
    <head><title></title></head>
    <body>
        <form method="POST" action="/test.php">
            <input type="text" name="testInput">
            <input type="submit">
        </form>
    </body>
</html>

In test.php, just dump out $_POST:

<?php 
    var_dump($_POST);

Then type an integer into the form field and see what type PHP spits out for it. This is the output I get:

array (size=1)
  'testInput' => string '5.25' (length=4)

Since it's impossible to actually construct a POST that contains PHP Objects (JSON itself is nothing more than a string until it's decoded), we're really only worried about the native datatypes here. As you can see above, even non-string input will be converted to be string data when PHP receives it.

This isn't so much about where the data is coming from, whether it's from a form or a script, it's how PHP receives it in and makes it available to you. I can construct that same 'form' in the manner of a script that executes a cURL request and receive the same output.

Ok, guess i agree with it, as i did it with GET earlier. Maybe i got wrong thoughts, next try: Whatever comes in will be hashed without problems - and i compare only two hashes right? I thought it may happen that i make my hast to string again and compare that to malicious code and everything goes boom. Yeah, i get confused because there is so much written and so many danger. Thank you everyone! — GGolem, Jan 06 '15 at 16:00
Even if someone submits malicious code in the password field, you will be hashing it which will irrevocably change the contents of that string (hopefully, that is after all the purpose of a good hash function). Once it's hashed with your [favorite algorithm](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords), yes just compare the hash with the hash stored in the DB. If they are equal, the user typed the correct password. — Jeff Lambert, Jan 06 '15 at 16:02

php safety, typecast password to string

1 Answers1