SitePoint Sponsor

User Tag List

Results 1 to 25 of 31

Hybrid View

  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
    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

  4. #4
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,259
    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."

  5. #5
    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

  6. #6
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,259
    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."

  7. #7
    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.

  8. #8
    . 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.


  9. #9
    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

  10. #10
    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.

  11. #11
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,259
    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."

  12. #12
    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.

  13. #13
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,650
    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

  14. #14
    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

  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)
    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.


  16. #16
    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

  17. #17
    Certified Ethical Hacker silver trophybronze trophy dklynn's Avatar
    Join Date
    Feb 2002
    Location
    Auckland
    Posts
    14,650
    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

  18. #18
    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

  19. #19
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,140
    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.

  20. #20
    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 Mittineague View Post
    Unless you can GRANT privileges, which is highly unlikely if you're on a shared host (you need to be the "super admin"),
    Who is using a Shared Host????

    I have a VPS with Root access.


    I don't think there's a way to set privileges per user in MySQL.
    I believe there IS a way to grant User Privileges in MySQL, and that is what I have been asking about. (I know that my PHP properly handles Logging In/Out and prohibiting Users unless they are accessing their own Account, but I believe there is an additional layer of security here on the backend.)


    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.
    This thread has morphed and I'm a bit lost.

    Guess this part would be better suited in the MySQL Forum. Oh well.


    Debbie

  21. #21
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,140
    Mentioned
    190 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    .....
    I believe there IS a way to grant User Privileges in MySQL
    .....
    Guess this part would be better suited in the MySQL Forum.
    .....
    There most certainly is a way - if you are the "super admin" - http://dev.mysql.com/doc/refman/5.1/...ing-users.html
    And yes, it is more secure. If your db connection allows you to do things like create users and DROP, you shouldn't be using that for code others will use. Much safer to limit their capabilities.

    And yes, this has strayed from passwords. Although this topic is security related, I too think a thread in the database forum would probably get better results.

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

    You're quite correct. I created a website for a local org in which I allowed different "officers" to modify pages under their control (but no others). All that takes is a field in the user's record and a check in the PHP script which is used to modify records. Mitt's suggested that you might allow others to modify the database which we all agree is not what you want to do.

    IMHO, this is not a db question but one for the PHP board. Okay, it could go either way but allowing others to manipulate your database is not advisable.

    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

  23. #23
    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,
    IMHO, this is not a db question but one for the PHP board. Okay, it could go either way but allowing others to manipulate your database is not advisable.

    Regards,

    DK
    That is the point of this tangent, though...

    From my understanding, you want to set up your database connection in PHP so that Visitors and Members are logging in with restricted rights.

    Right now on my laptop, I am logging in as root to the database.

    I would think that I will want to create MySQL Database Roles and create one called something like "member" which prohibits said role from: Deleting Users, Dropping Tables, Changing Rights, etc and basically restricts things - at a database level - to where anyone accessing my site can only do basic CRUD on their own records and account.

    But I am rusty on this and no expert.

    Nonetheless, I think there is a large "database dimension" here that I need to address.


    Debbie

  24. #24
    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)
    The way I personally plan on doing it for an app that I'm writing:
    1. I create a new user to use when directly accessing MySQL (in my case via PHPMyAdmin), this acts as a "super-administrator" and the old root user gets deleted.
    2. Each app has it's own database and user which it uses to access MySQL, that user is only given access-rights to the database belong to that app and it's denied any access whatsoever to any other apps (also it's not allowed drop or truncate at all)
    3. The app will have tables:


    • User: Essential user information only
    • User Info: "Optional" fields like instant messaging contacts, avatars etc
    • Rights: Each possible action is given it's own row
    • Group Rights: Records what rights each group has
    • Group Membership: Records what groups a user is a member of
    • Groups: Names of groups and things like PM limits
    • Session: User sessions are stored in the database


    You've probably got similar tables in your app's database.

    The user groups/permissions bit is not complete but when a user logs into the site

    1. the credentials they provide are checked against the users table and there should be a single match, if there's more then 1 match then there's a problem.
    2. They will then get checked (eventually) against a list of banned users and if they are banned then they get shown a "unable to login you're banned" message.
    3. Their right to view the page they are on is checked (via their group memberships), if they are allowed they view the page, if they aren't they get sent back through the hierarchy of pages until they reach one they have permission to view.


    Like has already been said you should:

    • use sha1 at the minumum for hasing passwords use a salt with each one (I've got to look into the use of using a different salt for each user)
    • Use prepared statements to protect against sql injection.
    • Have a read of this wikipedia article about password strength
    • You might want to consider adding a password strength indicator on you site's signup page.
    • IANAL but you might want to add to your site's T&Cs something about a user being responsible for all actions attempted by their account and that it's their responsibility to keep their login details safe and also something about their registration address to always be a valid address


    Any web app in whatever language using whatever database server should not be verifying users directly against the database server's user table, they should verify a user against the user's table stored in that apps database. That app should use a single MySQL user to interact with it's database only.

    I hope that helps a bit Debbie, if I had a diagram which could visually show it I would add it.
    Community Team Advisor
    Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
    Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator

  25. #25
    Non-Member
    Join Date
    Jun 2012
    Posts
    88
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SpacePhoenix View Post


    • use sha1 at the minumum for hasing passwords use a salt with each one (I've got to look into the use of using a different salt for each user)
    This really good info might help with the red bit.


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
  •