at least x number of characters on password input requriement

Dear Expect,

after solving the SQL I issue ,

 now I have one more question on
password requirement for user to register on my site.

What is the "at least x number of character on password" I need to set.

For example, there is a-z , A-Z, 0-9, , ','','#'$'......etc... around 70 characters for one character of password input so  if  where x is 3, the combination is 70*70*70=343000, right ?

x is 3  that is safe enough for security issue, right ?  

LVL 13
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

It will depend on what kind of attack are you considering.

If you will allow unlimited tries without blocking the user for some time, it will be easily breackable. You will want to add some limits there, so the attacker will need more time than is feasible or reazonable for your scenario.

You should also consider server side protection, using salted hashes, to protect the password on the case someone gets into your server.

This article written by another expert is quite good on password security:

Please take a look on this thread where the server side and password transport scenarios were discussed too:
duncanb7Author Commented:
thanks Cristian Moecke, I will read it,but  I need  at least x, where x is one day  since there is a lot technical terms I need to understand it.

I recommend you read it, but a short version for you:

3 basic places to attack to worry on: login page, transport and storage

Login page, two basic attacks:
 - Brute force, that is someone using automated tools to guess the password. The time needed to guess a 3 (or more) password will depend on hom many sucess/fail answers your server can provide. You probably will want more than 3, as 3 will be easy to guess
 - Dictionary attacks: if the password is user provided (and not random generated) users will probably use easy passwords that can be guessed quicker than by brute force by using pre computed talbes of common passwords.
For both you may want to limit the number of attemps one can do in a fixed limit of time, ex, 10 tries per hour. But that can lead to someone intentionally locking the legitimate user out by using all his tries, and is not good too. So a common sollution is to use a CAPTCHA, but I personally do not like those too since they are annoying. Use a combination of those, after some unsuccesfull tries, ask for a captcha!

 - If you can not trust the internet service providers between you and your client, you should worry about them sniffing the data. You want to use SSL to solve that.

 - If someone breaks into the server, and gets the DB, if you store the passwords unencrypted the attacker will have all user passwords. And that should be considered. The common solution is to store not the password, bus a hash of them. Then when the user authenticates, you will calculate the hash again and compare the hashes, not the password (just as you wanted to do in the other question and I mentioned is good, but not for sqli). But do not use md5, that is breakable, use sha2 with some salt at least. The salt part is to avoid rainbow table attacks, more info on that on the links I provided.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Build an E-Commerce Site with Angular 5

Learn how to build an E-Commerce site with Angular 5, a JavaScript framework used by developers to build web, desktop, and mobile applications.

Ray PaseurCommented:
You're not the first to have this question.  Please read the entire article here.  It will tell you what you need to understand PHP client authentication.  In the instant case about the passwords, be sure to read the part (including the links) under An Afterword: About Storing Passwords
duncanb7Author Commented:
cristiantm and Ray, thanks for your reply.

it seems the answer to this question is  where at least x is as long as possible, Right ?

And if I try to increase the time for the user to complete the login process that will help
to improve to prevent the attack, Right ? since the attacker need more time or cost to do every  access guess, for example,  doing one time of login page access by adding idle time of 30  seconds in the login php page,  if so, 1-million guess needs 1-million*30 second =342 days.

I understand that is not prefect  and it will delay the user to login my site, but
at least it will be better  than login page with just 300ms completion time.

Please advise

duncanb7Author Commented:

this link might answer  my question , and it not allows user to use its page
10 times per hour and 80 times in one day

If my login php page will check the user 's number of time to do login access in one
hour or one day , for example,just allow them to run login.php only 80 time in one day ,
 that strategic will solve all computer auto access guess by brutal-attack completely , Right ?

Ray PaseurCommented:
The subject of Information Systems Security is a full time four year college major at the University of Maryland, and choosing the password scheme is about 1 day of that curriculum.  Did you read the ArsTechnica article?  It doesn't matter what you do!  Anyone who is determined to break your passwords is going to be able to do it (and that includes the NSA).  Anyone who wants to mount a brute-force attack will be able to do it.  And if you try to defend against attacks by locking up your server, all you will accomplish is a giant frustration for your legitimate clients.  Don't do that.

The password-checker at online-domain-tools looks like it might have been right in about 1996, but today most password-decipher algorithms are computationally trivial.  All that stuff about "2 million years" to break a password is just nonsense.  Don't believe it.

You've heard of the Target Stores breach, right?  110 million clients have had their credit card numbers exposed, along with their names, addresses, pin numbers, CVV codes, expiration dates and perhaps other information.  This did not happen by accident, and it did not occur because Target used a deficient password hash.  Security is a wide and deep subject, constantly changing.  Password-related algorithms are the least of your concerns.  Edward Snowden is the poster child for information systems security.  The greatest threat is not someone who is trying to hack your passwords.  It's someone you trust.  If you put your web application on a computer that can be administered by a single individual, your password scheme won't matter at all.  You'll fail the first question on the security audit!

Executive summary: use well-salted strings for password storage.  It doesn't matter whether you use md5() or sha() functions to encrypt because only the novice hackers will be stopped; the others will break the passwords, it's only a matter of time.  

You might think about using a CAPTCHA test at the time of registration because that's when most of the script-kiddie attacks occur, then once they are registered they post V1AGRA advertisements into your web site.  This article can help you understand and implement CAPTCHA.

Good luck with your project and don't waste too much time on this one little slice, ~Ray
duncanb7Author Commented:
After reading your post,   whether limit user to  access login.php in certain number of
time in day that will help on password or login security or not ?  Do I need to implement it
on my login.php page ?

Ray PaseurCommented:
It depends on what you're trying to protect and where the data is stored and who the attackers might be.  It also is important to create a solution that does not suck.  There is no one-size-fits-all answer for something like this.  It's a learning curve, and the threats are constantly changing.

This is required reading for any PHP developer:

This is old, but it explains a lot of the bad history of PHP security:

This is old, too, but it has been updated for modern times:

This blunder is still hanging around in some PHP installations, but most of them have already been destroyed by hackers:

This organization is worth joining:

And amazingly, there are still some developers who have not seen this:
duncanb7Author Commented:
thanks for all of your reply, Ray, I will read it and take your advise

have a nice day

Ray PaseurCommented:
Thanks for the points, and best of luck with your project!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.