Jump to content

risky password input examples


Recommended Posts

I have a security question.

Though I have gone through OWASP docs I still need to place specific things in the right perspective. It is actually quite brief regarding examples.


But regarding security, I have to admit that I dont know much about how hackers are operating.

What I know is that javascript can be included and mysql injection can be done if you don't escape well.


I have a piece of regex to allow as much characters as possible for password input. So also the <> the dot . and the semi-colon ; and the string.

After forcing the user to use the right characters the password is encrypted with blowfish.

Im actually not sure what happens, because if you encrypt malicious code, you can finally make it work again when you decrypt it.


Probably its naive to ask online for hacking examples, because then you inform hackers.

Maybe if you cant make up any risky situation, you can give a recommendation for which characters should be avoided for a password input.

All input is encryted with password_verify / Blowfish. Then prepared OOP queries store the variable in the database.





then the preg_replace does:

      if(preg_match_all($var,$pas_inp, $o)<2) {
	   echo '<br><br>input should contain at least 2 special chars , try again';
	   return FALSE;


How risky (in which possible situations) is the use of:

< > . ; $ &

regarding javascript, mysql injection and other possible hacks.

(sorry it is a very open question, but to avoid problems I have to start somewhere)


Link to comment
Share on other sites

You don't encrypt passwords, you hash them so that the information is irrecoverable. Since passwords are never printed anywhere, any character is valid because there is no risk of injection. 

Link to comment
Share on other sites

I don't see a technical reason to restrict the characters or the length of a password at all.  If someone wants to use the text of the Magna Carta as their password, fine.  Like Ingolme said, the password should be hashed anyway and that's going to result in a string of a specific length no matter how long the input text is.  If you want to enforce decent practices for passwords then that would be things like finding a list of the 1,000 most commonly used passwords and disallowing those, adding brute-force protection so an attacker can't keep trying passwords until they get it right, etc.

Link to comment
Share on other sites

Oh sorry I didnt mention I used bcrypt. If bcrypt only hashes that's okay.

reading more at OWASP I discovered that the max password length they recommend is 160 chars.

is there a way to calculate the size of the string stored after hashing it with bcrypt // password_hash // cost 11 ?


Link to comment
Share on other sites

You validate the length before hashing it. There's no reason to do anything with a password after it has been hashed outside of comparing it to another hashed string.

Link to comment
Share on other sites

oh wait.

I figure out that the length of the hashed value is always 60 when you use password_bcrypt.

I thought it would be doubling or exponential growing, but it is a fixed outcome, whether you choose a 5 letter password or a 160 chars long.

this solves the database storage problem for setting the size of the column.


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...