Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 10 of 10
  1. #1
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,048
    Thanks
    25
    Thanked 0 Times in 0 Posts

    Passwords and Illegal Characters

    Should I restrict any characters that a user can use for a Password?

    In my code I currently have this...
    PHP Code:
        // ****************************
        // Check Password Strength.        *
        // ****************************

        // 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?!

    Thoughts???

    Sincerely,


    Debbie

  • #2
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,987
    Thanks
    4
    Thanked 2,660 Times in 2,629 Posts
    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).
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 

  • #3
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,048
    Thanks
    25
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Fou-Lu View Post
    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?

    Thanks,


    Debbie

  • #4
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,987
    Thanks
    4
    Thanked 2,660 Times in 2,629 Posts
    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.
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 

  • #5
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,048
    Thanks
    25
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Fou-Lu View Post
    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.

    Correct?


    Debbie

  • #6
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by doubledee View Post
    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.

    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.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #7
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,987
    Thanks
    4
    Thanked 2,660 Times in 2,629 Posts
    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.
    Last edited by Fou-Lu; 01-21-2013 at 08:45 PM.
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 

  • #8
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,048
    Thanks
    25
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by felgall View Post
    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.
    This is what I use for my Password...
    PHP Code:
        $currHash hash_hmac('sha512'$currPass $saltVINEGAR); 


    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??


    As a minimum you should be using SHA 1 and a salt to hash the passwords.
    Yes, see above.


    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!!!


    Debbie

  • #9
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,589
    Thanks
    0
    Thanked 644 Times in 634 Posts
    Quote Originally Posted by doubledee View Post
    Why don't Hashes use special characters??
    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.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #10
    Regular Coder LearningCoder's Avatar
    Join Date
    Jan 2011
    Location
    The Pleiades
    Posts
    918
    Thanks
    76
    Thanked 29 Times in 29 Posts
    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.

    Check it out: http://www.openwall.com/phpass/

    When I first looked into PHPass I went by this very simple, easy to understand tutorial: http://sunnyis.me/blog/secure-passwords/

    Regards,

    LC.
    Last edited by LearningCoder; 01-21-2013 at 11:32 PM.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •