views:

70

answers:

6

Hi I was composing a regex for a password field of my site and had a concern:

Are there any characters I should block a user from entering? If so why?

Or is it enough just to escape dangerous characters like = and ' when processing data? It seems good for this topic to list the php functions for escaping those, if you would.

Thanks!

A: 

None of this should be a problem as long as you escape everything the user enters on the server side. You can see more information at http://stackoverflow.com/questions/2312051/where-to-use-mysql-real-escape-string-to-prevent-sql-injection.

TNi
+1  A: 

No restrictions should be placed passwords. Let the user decide.

As for escaping characters for database entry, no need; Just do some research on SQL Injection

The Pixel Developer
+4  A: 

I hash anything a user enters as a password, so I don't care what they enter, it never touches my database and can't cause any harm. md5($_POST['password'])

Other fields are a different story...

Fosco
+1 Hashing is also a good point.
TNi
thats good - didn't md5 and sha1 get cracked though?
audio.zoom
cracked?.. if someone gets in your database, they might be able to google up a couple decrypted passwords, but they would have to get in first right? Separate issue entirely... hashing it before SQL entry will eliminate any chance that the PASSWORD itself is being used for sql injection or harm to your site.
Fosco
Also, there's no realistic way they could get decrypted passwords from google if you use a unique salt to your application, not to mention a unique salt to each user (that's my preference)
Matthew
@frosco: that is a separate issue but as a quick off-topic, are there things i need to do besides having a good host to protect my database from being accessed? (by a hacker)
audio.zoom
+1  A: 

What specifically are you guarding against? If it's SQL injection, then you shouldn't rely on escaping the user-supplied parameters, you should be using parameterized queries.

http://us.php.net/manual/en/mysqli-stmt.bind-param.php

Mike Baranczak
everything, so i suppose if hashing is the only secure option then sql injections are of lesser concern now
audio.zoom
SQL injection is still a huge concern for anything other than passwords in this case. And when will you ever have a SQL query with a password alone by itself?
TNi
i agree - thanks. Thats lots of code to look though - is this the one page i have to familiarize myself with in order to guard against injections?
audio.zoom
@audio.zoom: if you read the first code snippet on that page, you should get the general idea. The specifics will be different depending on what language and library you're using, but this design pattern looks the same pretty much everywhere.
Mike Baranczak
+2  A: 

Like other people have already said, hashing the users password before saving it to the database will mean you don't have to worry about what the user enters.

Whilst we're on the subject of hashing, you might even want to consider adding a 'salt' to the password before it is hashed. A salt is a random string (for example, the user's email address) that will help to improve the uniqueness of the hash generated (different users that have the same password will generate the same hash without the salt).

For more information take a read of: http://phpsec.org/articles/2005/password-hashing.html

greenie
many good answers - thanks I was looking for a good salt tutorial
audio.zoom
A: 

I utilize MD5/Hash and BASE64 ENCODE Functions for passwords, so I haven't really a care what they enter as long as they meet minimum requirements...Strongly typed passwords are recommended.

function get_rnd_iv($iv_len)
    {
        $iv = '';
        while ($iv_len-- > 0) {
            $iv .= chr(mt_rand() & 0xff);
        }
        return $iv;
    }

    function md5_encrypt($string_value, $salt_key, $iv_len = 16)
    {
        $string_value .= "\x13";
        $n = strlen($string_value);
        if ($n % 16) $string_value .= str_repeat("\0", 16 - ($n % 16));
        $i = 0;
        $enc_text = get_rnd_iv($iv_len);
        $iv = substr($salt_key ^ $enc_text, 0, 512);
        while ($i < $n) {
            $block = substr($string_value, $i, 8) ^ pack('H*', md5($iv));
            $enc_text .= $block;
            $iv = substr($block . $iv, 0, 512) ^ $salt_key;
            $i += 16;
        }
        return urlencode(base64_encode($enc_text));
    }

    function md5_decrypt($enc_text, $salt_key, $iv_len = 16)
    {
        $enc_text = urldecode(base64_decode($enc_text));
        $n = strlen($enc_text);
        $i = $iv_len;
        $string_value = '';
        $iv = substr($salt_key ^ substr($enc_text, 0, $iv_len), 0, 512);
        while ($i < $n) {
            $block = substr($enc_text, $i, 8);
            $string_value .= $block ^ pack('H*', md5($iv));
            $iv = substr($block . $iv, 0, 512) ^ $salt_key;
            $i += 16;
        }
        return preg_replace('/\\x13\\x00*$/', '', $string_value);
    }
Joe Garrett
thanks - this will help on my salty quest ;)
audio.zoom
what's the purpose of all this code? why not just md5/sha1(pass.salt)?
Col. Shrapnel
This would be a reusable pattern that can be placed inside of a class or used as an include...in this method you can continually re-use the md5/sha1/base64_encode method...Dunno why you rate negative when it is a solid solution. You can also use it to validate/verify querystring data by appending the hashed data. You could also utilize a unix datetime to encode it further so that the encoded data is only valid for the date it was instantiated.:)
Joe Garrett