Hey there! Sign in to join this conversationNew here? Join for free
    • Thread Starter
    Offline

    2
    ReputationRep:
    I'm re coding some of my personal user system I have been developing over the years and come to the point where I want to change the security on my project.

    Previously, I just hashed into MD5 since at the time I implemented the code It didn't need much more to keep secure.

    This time, I was thinking something along the lines of bCrypt whereby I use the users registration time as a salt and storing that in the database.

    can anyone recommend me any other methods?
    Offline

    1
    ReputationRep:
    I'm not going to comment on the hashing algorithm but something with a salt can help improve security. You will find changing from one system to another can be a challenge depending on the number of users. You'll potentially need to support two hashing algorithms for a while.

    Another way to improve security of your stored password hashes is to not have them directly available to the front end code. This means that if your web code (assuming it's a website) was compromised the attacker can't download a set of password hashes. If you're using an SQL database one way you might be able to do this is having a stored procedure that you feed the userid and password hash into. That procedure could then return an indication of whether the password is valid. An alternative would be to feed the userid and password hash to an external program (that's only accessibly locally) that can perform the lookup function for you - you might need to add some suitable authentication between the front end and password checking processes so that you know you're talking to the authorised password checking routine.
    • Thread Starter
    Offline

    2
    ReputationRep:
    (Original post by mfaxford)
    I'm not going to comment on the hashing algorithm but something with a salt can help improve security. You will find changing from one system to another can be a challenge depending on the number of users. You'll potentially need to support two hashing algorithms for a while.

    Another way to improve security of your stored password hashes is to not have them directly available to the front end code. This means that if your web code (assuming it's a website) was compromised the attacker can't download a set of password hashes. If you're using an SQL database one way you might be able to do this is having a stored procedure that you feed the userid and password hash into. That procedure could then return an indication of whether the password is valid. An alternative would be to feed the userid and password hash to an external program (that's only accessibly locally) that can perform the lookup function for you - you might need to add some suitable authentication between the front end and password checking processes so that you know you're talking to the authorised password checking routine.
    I have thought about the external program idea, which I may actually implement eventually. Alot of games actually use this method of authentication. The only way that the passwords would get compromised is if the actual server that the website was running on managed to get hacked into, since XSS and Injecting is near enough locked down on my system (obviously anything can still be hacked, that's rule of thumb really..)
    Offline

    19
    ReputationRep:
    I only really skimmed over the OP, but perhaps you're looking for SHA-1? It's currently (I believe) the most common algorithm for every day use.
    • Thread Starter
    Offline

    2
    ReputationRep:
    (Original post by CJKay)
    I only really skimmed over the OP, but perhaps you're looking for SHA-1? It's currently (I believe) the most common algorithm for every day use.
    SHA-1 is common and therefore can be put into a rainbow table easily.

    I was going to do something like this:
    http://www.gregboggs.com/php-blowfis...ted-passwords/

    But instead of storing salts on a server I was going to it with something like X amount of letters/numbers from their password or something since you are able to then find out the salt while its being entered. Then again, It might be worth storing the salts since storing salts alone isn't really an issue.

    SHA-1 is used for general purpose not passwords so i don't really want to use it.
    Offline

    19
    ReputationRep:
    (Original post by Swinkid)
    SHA-1 is common and therefore can be put into a rainbow table easily.

    I was going to do something like this:
    http://www.gregboggs.com/php-blowfis...ted-passwords/

    But instead of storing salts on a server I was going to it with something like X amount of letters/numbers from their password or something since you are able to then find out the salt while its being entered. Then again, It might be worth storing the salts since storing salts alone isn't really an issue.

    SHA-1 is used for general purpose not passwords so i don't really want to use it.
    I think you're overthinking it somewhat. SHA-1 is plenty secure for passwords and incredibly difficult to rainbow-table when salted. If you really must, use SHA-256. Also, yes, storing the salt with the password is not usually a problem and most CMSs do it nowadays.
    • Thread Starter
    Offline

    2
    ReputationRep:
    (Original post by CJKay)
    I think you're overthinking it somewhat. SHA-1 is plenty secure for passwords and incredibly difficult to rainbow-table when salted. If you really must, use SHA-256. Also, yes, storing the salt with the password is not usually a problem and most CMSs do it nowadays.
    I also saw this website a while ago and just dug it back up, another reason I wish to use bCrypt:

    http://codahale.com/how-to-safely-store-a-password/

    Just thought i'd share.

    I would yes, like to use MD5 or SHA, but I really would like to be as secure as possible. Thanks for your help though!
    Offline

    0
    ReputationRep:
    ^ Good link - worth reading.

    May I suggest listening to the Security Now podcast (from TWIT). Plenty of episodes on passwords/hashing (and examples of poor implementation).
    • Thread Starter
    Offline

    2
    ReputationRep:
    (Original post by avsmithy)
    ^ Good link - worth reading.

    May I suggest listening to the Security Now podcast (from TWIT). Plenty of episodes on passwords/hashing (and examples of poor implementation).
    Will deffo take a look, thanks!
 
 
 
Reply
Submit reply
TSR Support Team

We have a brilliant team of more than 60 Support Team members looking after discussions on The Student Room, helping to make it a fun, safe and useful place to hang out.

Updated: April 22, 2013
  • See more of what you like on The Student Room

    You can personalise what you see on TSR. Tell us a little about yourself to get started.

  • Poll
    Is cheesecake a cake?
    Useful resources
  • See more of what you like on The Student Room

    You can personalise what you see on TSR. Tell us a little about yourself to get started.

  • The Student Room, Get Revising and Marked by Teachers are trading names of The Student Room Group Ltd.

    Register Number: 04666380 (England and Wales), VAT No. 806 8067 22 Registered Office: International House, Queens Road, Brighton, BN1 3XE

    Write a reply...
    Reply
    Hide
    Reputation gems: You get these gems as you gain rep from other members for making good contributions and giving helpful advice.