www.webdeveloper.com
Results 1 to 9 of 9

Thread: Password and site security

  1. #1
    Join Date
    Feb 2010
    Location
    Grantham, UK
    Posts
    103

    Password and site security

    I have been reading up a lot on hashing and site security recently.

    I have always had a few doubts about hashing though most likely just due to lack of understanding...

    1. If a database is stolen, then surely all of a users information (except the password) is readily available for an attacker to view..they wouldn't need a password in the first place....?

    2. If an attack is performed on the site itself, then no matter how much hashing is done, 1 guess of the right password using rainbow tables will allow access.

    That said, here are my thoughts for the security of the site I am currently developing.

    1. Take the chosen users password and split it - probably in half. If you know there is a minimum of 6 letters in the password, split it 6 times (the 6th time being the remainder of the password)

    E.G. "pass" +"word", or even "p", "a", "s", "s","w","o","r","d".

    2. Use different hashes and salts with each part.
    Code:
    $part1=sha1(userid+"p");
    $part2=md5(datejoined+"a");
    $part3=whirlpool(mysitehash+"s");
    etc
    etc
    3. save each of these in the database, and then combine them when checking login.
    Code:
    if (password <> $part1+part2...)
    I do understand that this is potentially overkill and could slow down login, but my belief is that you cant be too secure.

    I am also considering making members to have a number code as well (like banks often do) as this essentially means that an attacker has two passwords to crack. (my site does need to be extra secure )

    Finally, to address my first point, am thinking of encrypting all data stored in the database too.

    Would appreciate your thoughts!

  2. #2
    Join Date
    Apr 2012
    Posts
    22
    Many people use a common password everywhere and if it is readable, someone can try it on Paypal or some other important sites.

    Why don't you just encrypt the passwords with salt - http://php.net/manual/en/function.crypt.php instead of making your own algorithm?

  3. #3
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Hashing individual parts of a password shouldn't be necessary. Enforce a minimum length for passwords with at least one number and/or one special character. Use a long, unique salt for each password. And hash with SHA2.

    If your salt is long enough (even 8 to 16 characters adds a great deal of complexity) and you've enforced reasonably complex passwords, the compute time required to produce a collision against a stolen database should keep a hacker with or without a rainbow table busy for years. The weakest point in a salted, securely hashed password is the end-user's choice of password.

    If any of your users have used p4ssw0rd, for instance, they'll likely be cracked. In those cases, adding some unique steps into to your hashing algorithm may help, but can also introduce weak points.

    And yes, if the information in the database is highly sensitive, encrypting it is a good step, so long as the fields you're encrypting don't need to be searched.
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  4. #4
    Join Date
    Feb 2010
    Location
    Grantham, UK
    Posts
    103
    Thanks for the feedback!
    codefish - was typing quickly, i meant to use my own salt, not hash..

    With regard to encrypting and searching fields, couldnt you use the same encryption key and search for that?

  5. #5
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,176
    For exact, case-sensitive matches you could encrypt the search input then compare it to what's in the DB, and the only performance hit would be the time it took to do that single encryption; but what you would want to avoid is having to decrypt each relevant field in each row of a table to see if it matches -- which is likely what you would have to do for case-insensitive searches or partial matches (e.g. "LIKE '&#37;text%'"), and using something like MySQL full text index searches probably would be a problem.
    "Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
    ~ Terry Pratchett in Nation

    eBookworm.us

  6. #6
    Join Date
    Feb 2010
    Location
    Grantham, UK
    Posts
    103
    It would seems that there is very little you can do to make truly secure websites and that the onus is ultimately on the end user.

    If I understand correctly, I guess that enforcing longer/complex passwords and using a number (with salts), seems to be all we can do. (with a little encryption of course)

  7. #7
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Quote Originally Posted by max2474 View Post
    It would seems that there is very little you can do to make truly secure websites and that the onus is ultimately on the end user.

    If I understand correctly, I guess that enforcing longer/complex passwords and using a number (with salts), seems to be all we can do. (with a little encryption of course)
    Well no, there's a lot you can do. Point is, you don't need to take steps that are either unorthodox or out of proportion with the sensitivity of the data.

    Strictly in terms of password security, you protect a user's password as best you can. You enforce some rules to keep it reasonably complex. But, if the user is going to use "password" as their password, they're likely using "password" for every account they have. There's often no need to jump through hoops to protect this sort of user.

    And again, if you're dealing with highly sensitive information, you can enforce stronger passwords. 8 characters, including one special character or number and one capital character provides a good amount of additional complexity. but, you can certainly get more restrictive than that if you like. But remember to enforce this too in proportion to the sensitivity level of the data/account.

    For instance, I won't bother to come up with a complex, unique password for an account on a website that knows me primarily by a screenname and knows my favorite books or whatever. I do expect and hope that my banking sites will make me jump through hoops though.
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  8. #8
    Join Date
    May 2012
    Posts
    5
    If any of your users have used p4ssw0rd, for instance, they'll likely be cracked. In those cases, adding some unique steps into to your hashing algorithm may help, but can also introduce weak points.

    Venkat

    CNA training Online and CNA Certification

  9. #9
    Join Date
    Feb 2010
    Location
    Grantham, UK
    Posts
    103
    Good points from all of you. Think security will always be a tough one to crack, but lots to think about.

    Many thanks.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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



Recent Articles