Balderick Posted May 19, 2017 Share Posted May 19, 2017 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) Link to comment Share on other sites More sharing options...
Ingolme Posted May 19, 2017 Share Posted May 19, 2017 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 More sharing options...
justsomeguy Posted May 19, 2017 Share Posted May 19, 2017 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 More sharing options...
Balderick Posted May 20, 2017 Author Share Posted May 20, 2017 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 More sharing options...
Ingolme Posted May 20, 2017 Share Posted May 20, 2017 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 More sharing options...
Balderick Posted May 21, 2017 Author Share Posted May 21, 2017 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now