In the past, experts said you should force users to make Complex Passwords like this...

8 to 15 Characters

At least 1 Upper-Case Letter

At least 1 Lower-Case Letter

At least 1 Number

At least 1 Special Character

From what I have read in modern times, experts say that it is safer to force users to create "Pass-Phrases" versus Complex-Passwords, because Password-Length is a larger deciding factor as to whether a Password can get guessed (e.g. "Rainbow Tables")

Of course, if a person's chose, "I like green eggs and ham" that wouldn't be very secure?!

As I prepare for my website to go live, I am still debating what to require for Passwords... :-/

Originally I had the first example above, but this week someone corrected me and said NOT to have a Password-Length Maximum.

What do you think??

Debbie

logic_earth
—
2012-07-05T07:19:18Z —
#2

If passwords are being properly handled, length and the contents of the password would not be an issue. As an example, "SELECT SQL_INJECTION FROM VulruableTable" would be perfectly suitable. If you handle passwords correctly. By that I mean you throw it into a hashing function, after the it is a fixed sized with fixed set of characters (HEX in most cases.) So you should not have any limits upon passwords, how long they are or what they contain.

As for requiring a user implement complex passwords I am in the camp, forget about it. If a user wants to use a weak password oh well I don't care. As long as the passwords are stored securely on my end that is the limit of my responsibility. I make it simple I set a minimum length and that is all I do.

I set a minimum password length (no max. length) and have a black-list of characters that are not allowed as part of my defence against sql injection.

I then salt the password, hash it and sanitise it before passing it to an sql query. Salting the password is a must do.

If you like, you can display to the user a bar graph or something similar to indicate to the user whether their password is strong or not, but at the end of the day they can choose whatever password they like that meets the min. length and characters criteria.

My responsibility is to store the password securely. It's not to force the user to use a strong password.

system
—
2012-07-05T11:52:51Z —
#4

[ot]also, make sure you don't store the actual password.

Store only a hashed or encrypted password.[/ot]

logic_earth
—
2012-07-05T11:57:26Z —
#5

kennard said:

a black-list of characters that are not allowed as part of my defence against sql injection.

Remove the black list, you don't need it. Running it though the hashing functions removes that threat. Nor do you need to sanitize it. I recommend when it comes to passwords, you don't alter or change the password the user submits other then throwing it into a hashing function. The moment you do that anything contained within it is neutralizer. No threat of SQL injection from it or anything else nasty.

system
—
2012-07-05T21:15:46Z —
#6

logic_earth said:

Remove the black list, you don't need it...Nor do you need to sanitize it. I recommend when it comes to passwords, you don't alter or change the password the user submits other then throwing it into a hashing function.....

Thank you for your opinion but I will leave the black-list and sanitise user inputs before passing them to an sql query and I will continue to salt passwords as there is much info on the Internet on why it is a good idea to do so.

If you think that's over-kill, that's fine

Jeff_Mott
—
2012-07-05T21:45:05Z —
#7

I suppose I'll add my opinion that I think logic_earth is right. Blacklisting characters is completely unnecessary. And as a user, it frustrates me when a site tells me I can't use this or that character in my password, because there's no good justification for that. If you're escaping or using placeholders, then you've already removed the threat of SQL injection, no matter what characters are in the data.

logic_earth is also right that, in this very specific situation, even escaping or using placeholders is also unnecessary, because you'll always be dealing with a hashed hexadecimal string. Though, personally, I would still use placeholders just to keep up the habit and to not rely on assumptions about the data.

DoubleDee
—
2012-07-05T23:05:01Z —
#8

logic_earth said:

If passwords are being properly handled, length and the contents of the password would not be an issue. As an example, "SELECT SQL_INJECTION FROM VulruableTable" would be perfectly suitable. If you handle passwords correctly. By that I mean you throw it into a hashing function, after the it is a fixed sized with fixed set of characters (HEX in most cases.) So you should not have any limits upon passwords, how long they are or what they contain.

Well, I take the entered Password and concatenate it with a random Salt, and then I create a Hash like this...

$newHash = hash_hmac('sha512', $newPass . $newSalt, VINEGAR);

And I always use Prepared Statements!!

As for requiring a user implement complex passwords I am in the camp, forget about it. If a user wants to use a weak password oh well I don't care. As long as the passwords are stored securely on my end that is the limit of my responsibility. I make it simple I set a minimum length and that is all I do.

Except that when a User chooses a stupid password and their account gets hacked, guess who pays the ultimate price? ME!!!!

I don't care about stupid Users.

I do care about a Hacker compromising one account and then somehow using that as an Attack Vector to attack my entire site or other Users...

Debbie

dklynn
—
2012-07-05T23:22:44Z —
#9

Kennard is correct (a point of view of a CEH). Length, too, is important and should be kept secret (don't post *'s to show how many characters must be guessed).

Lately, the MD5 has been cracked so SHA1 or SHA2 (preferred) should be used for the hash (as DD has shown).

Of course, if you're merely using passwords to annoy visitors, use short ones without restriction, otherwise, what you've started with (DD) is good.

Regards,

DK

Jeff_Mott
—
2012-07-05T23:24:42Z —
#10

DoubleDee said:

$newHash = hash_hmac('sha512', $newPass . $newSalt, VINEGAR);

You could actually do this:

$newHash = hash_hmac('sha512', $newPass, $newSalt);

I assume VINEGAR is a constant for another random value, which means you're actually salting twice. Salting twice doesn't do any harm... but it doesn't do any good either.

DoubleDee said:

And I always use Prepared Statements!!

:tup:

DoubleDee said:

Except that when a User chooses a stupid password and their account gets hacked, guess who pays the ultimate price? ME!!!!

I don't care about stupid Users.

I do care about a Hacker compromising one account and then somehow using that as an Attack Vector to attack my entire site or other Users...

Assuming the user who gets hacked isn't an admin or something, then you shouldn't need to worry about the rest of your system being compromised. For admin users on your site, it may be worthwhile to enforce strong passwords, but for regular users, I'd recommend merely issuing a warning along with a disclaimer that your business is not liable. You don't want to give your users any reason to abandon the registration process.

system
—
2012-07-05T23:29:55Z —
#11

Jeff_Mott said:

Blacklisting characters is completely unnecessary.

That may or may not be the case, but in any case I like to have that extra layer of defence. If a user tries to insist on using any of the handful of chars I blacklist, then I don't want them as a registered member.

DoubleDee
—
2012-07-05T23:36:38Z —
#12

Jeff_Mott said:

You could actually do this:

$newHash = hash_hmac('sha512', $newPass, $newSalt);

I assume VINEGAR is a constant for another random value, which means you're actually salting twice. Salting twice doesn't do any harm... but it doesn't do any good either.

Not from I have read (but since forgotten).

Assuming the user who gets hacked isn't an admin or something, then you shouldn't need to worry about the rest of your system being compromised. For admin users on your site, it may be worthwhile to enforce strong passwords, but for regular users, I'd recommend merely issuing a warning along with a disclaimer that your business is not liable. You don't want to give your users any reason to abandon the registration process.

I hear this a lot, but am skeptical...

If a burglar breaks into your house, I find it hard to believe that just because they broke into the living room, that your 5-year old daughter is "safe" because she is in her locked bedroom...

Debbie

Jeff_Mott
—
2012-07-05T23:44:16Z —
#13

DoubleDee said:

If a burglar breaks into your house...

Let's say the burglar got into the house by finding a key under the mat (analogy for guessing the password), that doesn't mean the burglar has also compromised every house on the block.

DoubleDee
—
2012-07-06T00:18:08Z —
#14

Jeff_Mott said:

Let's say the burglar got into the house by finding a key under the mat (analogy for guessing the password), that doesn't mean the burglar has also compromised every house on the block.

Well, I see hacking into a User's account as more analogous to breaking into a House (i.e. Database).

Once you are in the House (Database), it is probably pretty easy to navigate and entered into every other Room (Records), and to also take over the Entire House (i.e. Database).

At any rate, my 1st priority is on My Database and My Website and all of My Customers. Not on just one dumb one?!

Debbie

logic_earth
—
2012-07-06T05:49:15Z —
#15

DoubleDee said:

Well, I see hacking into a User's account as more analogous to breaking into a House (i.e. Database).

Once you are in the House (Database), it is probably pretty easy to navigate and entered into every other Room (Records), and to also take over the Entire House (i.e. Database).

The only way they (hacker) could take over your entire database is if you have a vulnerability in handling user rights. A user should only be allowed to access what their rights allow not beyond that. If you a user can access things they should have access to even without being comprised, your security has failed. You should be focusing on that aspect of security controlling user rights, not whether they are using secure passwords. If a user account is compromised the attack only has access to what the user has access to and nothing more.

To put it another way, a burglar would only have access to the one house, the user's house no one other house would be accessible.

SpacePhoenix
—
2012-07-06T06:16:25Z —
#16

You may want to consider having a seperate password for the admin areas (either each admin has their own "admin password" or they share an "admin password") then if an admin's account does get hacked, provided the hacker has not gotten hold of the admin password then it should prevent them from doing any damage.

DoubleDee
—
2012-07-06T16:50:58Z —
#17

logic_earth said:

The only way they (hacker) could take over your entire database is if you have a vulnerability in handling user rights. A user should only be allowed to access what their rights allow not beyond that. If you a user can access things they should have access to even without being comprised, your security has failed. You should be focusing on that aspect of security controlling user rights, not whether they are using secure passwords. If a user account is compromised the attack only has access to what the user has access to and nothing more.

To put it another way, a burglar would only have access to the one house, the user's house no one other house would be accessible.

So, not to go too far off topic, but how then do I proper manage Access Rights?

My website should be pretty simple to properly set-up, because there are only 2 States...

1.) Debbie as the supreme ruler of the website (who doesn't even have an account and just manages things on the backend)

2.) Low-level Users - said lovingly - who shouldn't be allowed to do anything other than Log In, Log Out, Update their Profile, Post Comments, and Read Articles.

So how does that tie into what you are talking about?

Debbie

logic_earth
—
2012-07-06T18:54:26Z —
#18

DoubleDee said:

2.) Low-level Users - said lovingly - who shouldn't be allowed to do anything other than Log In, Log Out, Update their Profile, Post Comments, and Read Articles.

So how does that tie into what you are talking about?

You make sure that is all they can do. Log in, out update profile, comment, read articles. Pretty simple, yes?

DoubleDee
—
2012-07-06T21:25:39Z —
#19

logic_earth said:

You make sure that is all they can do. Log in, out update profile, comment, read articles. Pretty simple, yes?

That makes no sense.

How do I do it in MySQL?

The can do CURD, so that seems like everything and a contradiction.

How do I make sure that user123 can only ever access user123's info?

Debbie

logic_earth
—
2012-07-07T04:35:11Z —
#20

By testing it. Security is not just theory you need to test. I cannot tell you to do specific things because I don't have your source code to look over. Oh and you do not do this in MySQL but rather PHP, you handle access control in PHP. Basically, you check the user's credentials when conducting operations.