// Check for Illegal-Characters.
if (empty($errors)){
if (preg_match("#[\,\"\']+#", $newPass1)){
$errors['newPass'] = 'Password may not use Comma, Single or Double Quotes.';
}
}
I don't remember the reason for this code, but apparently someone told me in the past to not allow these characters?!
Maybe as a weak prevention for injection? You should be looking into prepared statements at this point in time, or at least using the mysql_real_escape_string if your still using the old mysql library.
In any case, the characters themselves are legal so there is really no reason to forbid them. The only character I may be concerned of is the null byte, but I don't think there's anyway to retrieve that from input in PHP (escaping also deals with the null byte anyway).
__________________
As of PHP 5.5, the MySQL library has been officially deprecated. It is recommended to move to either MySQLi or PDO libraries for your mysql connectivity. See here for help choosing which interface you prefer: http://php.net/manual/en/mysqlinfo.api.choosing.php
Maybe as a weak prevention for injection? You should be looking into prepared statements at this point in time, or at least using the mysql_real_escape_string if your still using the old mysql library.
In any case, the characters themselves are legal so there is really no reason to forbid them. The only character I may be concerned of is the null byte, but I don't think there's anyway to retrieve that from input in PHP (escaping also deals with the null byte anyway).
I have always used Regular Expressions in PHP. (It's actually the only way I know how to query MySQL?!)
Can you explain a little more why things like single and double quotes and a forward or back slash might cause problems?
And why wouldn't that logic apply to Prepared Statements?
Prepared statements are compiled separate from the data. The data is provided to it after its already constructed so you cannot issue a break in the structure of a SQL statement.
PHP Code:
$sInput = "1'; DROP TABLE mytable;--"; $sQry = "SELECT * FROM mytable WHERE column = '$sInput' ORDER BY acolumn ASC"; // end result: // SELECT * FROM mytable WHERE column = '1'; DROP TABLE mytable;--' ORDER BY acolumn ASC
PHP should actually reject the above statement; last I tested the mysql library with this regard, I determined that you can only issue several LIKE DMS statements in a single query passed by PHP. So a select and drop I don't believe were compatible. Same logic above can be applied to an UPDATE and INSERT though, so that would obviously be a much bigger problem.
This is why you have to either escape input or bind it. Quotes and commas are a problem since they can be used for structural change. Backslashes are only a problem if the data is not escaped and can really malform the data. I question if the backslash belongs in the above since they precede every character within the class I think the intent was to use it as an escape but its only necessary for the double quotes and carries no meaning to the comma or single quote.
__________________
As of PHP 5.5, the MySQL library has been officially deprecated. It is recommended to move to either MySQLi or PDO libraries for your mysql connectivity. See here for help choosing which interface you prefer: http://php.net/manual/en/mysqlinfo.api.choosing.php
Prepared statements are compiled separate from the data. The data is provided to it after its already constructed so you cannot issue a break in the structure of a SQL statement.
PHP Code:
$sInput = "1'; DROP TABLE mytable;--";
$sQry = "SELECT * FROM mytable WHERE column = '$sInput' ORDER BY acolumn ASC";
// end result:
// SELECT * FROM mytable WHERE column = '1'; DROP TABLE mytable;--' ORDER BY acolumn ASC
PHP should actually reject the above statement; last I tested the mysql library with this regard, I determined that you can only issue several LIKE DMS statements in a single query passed by PHP. So a select and drop I don't believe were compatible. Same logic above can be applied to an UPDATE and INSERT though, so that would obviously be a much bigger problem.
This is why you have to either escape input or bind it. Quotes and commas are a problem since they can be used for structural change. Backslashes are only a problem if the data is not escaped and can really malform the data. I question if the backslash belongs in the above since they precede every character within the class I think the intent was to use it as an escape but its only necessary for the double quotes and carries no meaning to the comma or single quote.
So, back to my OP...
It sounds like you are saying that as long as I am using Prepared Statements, then there is no need to have a list of "Illegal Characters" which users are prohibited from using in their Passwords.
It sounds like you are saying that as long as I am using Prepared Statements, then there is no need to have a list of "Illegal Characters" which users are prohibited from using in their Passwords.
Correct?
Debbie
The other thing that you should be doing with passwords before storing them in the database is to hash them so that the plain text version of the password cannot be retrieved from the database. Once you do that any character at all can be valid in the password without it having even a remote possibility of getting anywhere near the database as the hashed password is the one that gets stored and that will only contain letters and numbers even if 1'; DROP TABLE mytable;-- is entered as the password.
As a minimum you should be using SHA 1 and a salt to hash the passwords.
When testing if the password entered is correct or not you process it through the same hashing step and compare that to what is stored in the database.
If you store the passwords in plain text and someone is stupid enough to use the same password for your site as for their internet banking then someone gaining access to the password field in your database will have the password needed to go into that user's internet banking account and spend that person's money. Storing passwords in plain text IS a serious security issue.
More or less yep. Even escaping is sufficient.
Unless you have business rules otherwise, you needn't block a user from inputting special characters. The more special characters they have, the less chance it will be brute forced. It would be easier to break "Password", than it would be to break: "'P@$s,w0rD'".
Felgall bring up a good point. You should hash the passwords instead of putting it in plain text. I would recommend using hash library with nothing less than sha256 though.
__________________
As of PHP 5.5, the MySQL library has been officially deprecated. It is recommended to move to either MySQLi or PDO libraries for your mysql connectivity. See here for help choosing which interface you prefer: http://php.net/manual/en/mysqlinfo.api.choosing.php
The other thing that you should be doing with passwords before storing them in the database is to hash them so that the plain text version of the password cannot be retrieved from the database.
Once you do that any character at all can be valid in the password without it having even a remote possibility of getting anywhere near the database as the hashed password is the one that gets stored and that will only contain letters and numbers even if 1'; DROP TABLE mytable;-- is entered as the password.
Why don't Hashes use special characters??
Quote:
As a minimum you should be using SHA 1 and a salt to hash the passwords.
Yes, see above.
Quote:
When testing if the password entered is correct or not you process it through the same hashing step and compare that to what is stored in the database.
If you store the passwords in plain text and someone is stupid enough to use the same password for your site as for their internet banking then someone gaining access to the password field in your database will have the password needed to go into that user's internet banking account and spend that person's money. Storing passwords in plain text IS a serious security issue.
Yes, I already knew that, but that is a good reminder for everyone here anyways!!!
The hashed value only ever uses letters and numbers - no matter what characters are included in the original. The hashed value also has a fixed length regardless of whether the original value is a single character or a billion characters long.
Take a look into PHPass for hashing passwords. I've started using that rather than manually hashing as even php.net discourages use of md5() and sha1() I believe. They tell you to use hash() or crypt() but I received advice elsewhere to just use PHPass.
It's really easy to install and you just create an object passing in the original value what the user entered. It then returns a hashed string.
Before you post, read our: 
