Jump to content
Sign in to follow this  
Balderick

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.

regex:

 

      $var='/[!@#$%^&*()\-_=+{};:,<.>]/'; 

 

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)

 

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post
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 ?

 

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...