/    Sign up×
Community /Pin to ProfileBookmark

Password and site security

Copy linkTweet thisAlerts:
May 18.2012

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[/CODE]

  • 3.

    save each of these in the database, and then combine them when checking login.

    [CODE]if (password <> $part1+part2…)[/CODE]

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

    to post a comment
    PHP

    8 Comments(s) ↴

    Copy linkTweet thisAlerts:
    @codefishMay 18.2012 — 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?
    Copy linkTweet thisAlerts:
    @svidgenMay 18.2012 — 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 [I]p4ssw0rd[/I], 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.
    Copy linkTweet thisAlerts:
    @max2474authorMay 19.2012 — 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?
    Copy linkTweet thisAlerts:
    @NogDogMay 19.2012 — 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.
    Copy linkTweet thisAlerts:
    @max2474authorMay 20.2012 — 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)
    Copy linkTweet thisAlerts:
    @svidgenMay 21.2012 — 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)[/QUOTE]

    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 [B]do[/B] expect and hope that my banking sites will make me jump through hoops though.
    Copy linkTweet thisAlerts:
    @cnatrainingsMay 21.2012 — 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
    Copy linkTweet thisAlerts:
    @max2474authorMay 21.2012 — Good points from all of you. Think security will always be a tough one to crack, but lots to think about.

    Many thanks.
    ×

    Success!

    Help @max2474 spread the word by sharing this article on Twitter...

    Tweet This
    Sign in
    Forgot password?
    Sign in with TwitchSign in with GithubCreate Account
    about: ({
    version: 0.1.9 — BETA 5.6,
    whats_new: community page,
    up_next: more Davinci•003 tasks,
    coming_soon: events calendar,
    social: @webDeveloperHQ
    });

    legal: ({
    terms: of use,
    privacy: policy
    });
    changelog: (
    version: 0.1.9,
    notes: added community page

    version: 0.1.8,
    notes: added Davinci•003

    version: 0.1.7,
    notes: upvote answers to bounties

    version: 0.1.6,
    notes: article editor refresh
    )...
    recent_tips: (
    tipper: @Yussuf4331,
    tipped: article
    amount: 1000 SATS,

    tipper: @darkwebsites540,
    tipped: article
    amount: 10 SATS,

    tipper: @Samric24,
    tipped: article
    amount: 1000 SATS,
    )...