SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 31
  1. #1
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Criteria for Passwords

    This seems to be a very complicated topic...

    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

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Here is a good article on determining password strength.

    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.

  4. #4
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:


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

    Store only a hashed or encrypted password.

  5. #5
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kennard View Post
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  6. #6
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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

  7. #7
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,266
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    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.
    "First make it work. Then make it better."

  8. #8
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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...

    PHP Code:
                $newHash hash_hmac('sha512'$newPass $newSaltVINEGAR); 

    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

  9. #9
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,653
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    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
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  10. #10
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,266
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    PHP Code:
                $newHash hash_hmac('sha512'$newPass $newSaltVINEGAR); 
    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.

    Quote Originally Posted by DoubleDee View Post
    And I *always* use Prepared Statements!!


    Quote Originally Posted by DoubleDee View Post
    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.
    "First make it work. Then make it better."

  11. #11
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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.

  12. #12
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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

  13. #13
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,266
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    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.
    "First make it work. Then make it better."

  14. #14
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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

  15. #15
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  16. #16
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,014
    Mentioned
    103 Post(s)
    Tagged
    0 Thread(s)
    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.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  17. #17
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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

  18. #18
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    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?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  19. #19
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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

  20. #20
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  21. #21
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    How do I make sure that user123 can only ever access user123's info?
    Depends on where the info is. Options include creating user roles in the database and/or assigning assigning access levels to each user and then check if the user has the required access rights before letting them query/see data from the database.

  22. #22
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    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.
    We are talking about two different things...

    Of course I test my code.

    And of course I step through every path to make sure my code does what it should do.

    And, yes, most stuff on my website requires a Member is logged in since most things a Account-driven.

    But I was talking about Access-Control from a backend database standpoint.

    I thought there were ways to make sure a MySQL User has restricted access (e.g. can only perform actions on own records, can only Read, cannot perform DCL, cannot Delete, etc)

    I thought that was what you originally meant.

    I haven't done anything with my Database Connection or backend MySQL to prevent an Anonymous User or logic_earth from running the gamut on database operations...


    Debbie

  23. #23
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,653
    Mentioned
    19 Post(s)
    Tagged
    3 Thread(s)
    DD,

    As stated by someone else way above, I do that with PHP which pulls the "permissions" from the database.

    Regards,

    DK
    David K. Lynn - Data Koncepts is a long-time WebHostingBuzz (US/UK)
    Client and (unpaid) WHB Ambassador
    mod_rewrite Tutorial Article (setup, config, test & write
    mod_rewrite regex w/sample code) and Code Generator

  24. #24
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,764
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dklynn View Post
    DD,

    As stated by someone else way above, I do that with PHP which pulls the "permissions" from the database.

    Regards,

    DK
    Sorry, I don't know what you are referring to...

    Can you please explain here?

    Thanks,


    Debbie

  25. #25
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,156
    Mentioned
    190 Post(s)
    Tagged
    2 Thread(s)
    Unless you can GRANT privileges, which is highly unlikely if you're on a shared host (you need to be the "super admin"), I don't think there's a way to set privileges per user in MySQL.

    The common way is to have a "privileges" table eg.

    Userr_Id ... Role
    123 .......... 1
    234 .......... 1
    432 .......... 2
    etc.

    Then you do a SELECT and if the user has an adequate role level you continue else no go.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •