Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 14 of 14
  1. #1
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts

    salting-md5'ing and then unsalting and unmd5'ing

    ok so I've seen so many threads about md5 (which I use regularly), sha and using salt methods to secure data; I've read countless tutorials about salt and I'm in a position where a portion of my portion really does need more than just simple md5 or sha and I have been completely unsuccessful in applying a salt method (mostly because I'm unable to understand how to do it)

    the next thing I need help with is if I was going to md5/salt data, how can I then retrieve that data? like how would I unsalt or unmd5 data? is it even possible? and how would I setup that field in that database? would that be text field or a defined # of chars?

    any help and patience is appreciated!
    Last edited by dnnhater; 11-16-2011 at 02:48 PM.

  • #2
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    You cannot. These are hashing techniques, not encrypting ones so you cannot reverse the provided value. You may attempt to brute them to find a possible combination that works (MD5 has been compromised quite a ways back, so there are effective brute techniques for it).
    You can salt wherever you want though. If you have unsalted MD5 values, you may now salt them and resave them. As long as the same process is followed for the comparison that was done for the storage, the results will be the same. If you use unique salts for each user, you need to store that salt with the user entry, and select the data first then compare it.

  • #3
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    thanks for that Fou-Lu

    ok and this is the part where I would normally get lost, but I think you've made a very clear point: there's a difference between encrypting and hashing which I don't think had registered with me previously - I'm almost embarrassed to say that I've used the 2 terms interchangably

    so now I've changed my googling a lil bit to look up encrypting data and I've come across mcrypt_encrypt() and mcrypt_decrypt() - would these be the functions, along with salt, that would suit me better?

  • #4
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    I don't recommend that any password be encrypted. There is no reason to need to retrieve the original; forgotten passwords can be performed without needing to use the original. You'd encrypt for something like a credit card number (a whole different can of worms which we won't get into), but hashing is perfectly fine with passwords. Upon a data compromise, its better that the only way to determine a password is via brute which cannot generally be performed (on using say sha256) in a reasonable amount of time.

  • #5
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    oh agreed - this is not for passwords

    it's for that whole other can of worms...

  • #6
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Quote Originally Posted by dnnhater View Post
    oh agreed - this is not for passwords

    it's for that whole other can of worms...
    Then you should hire a team for this. Dealing with credit cards or other secure data is not the task a novice developer should take on. There are serious legal issues that can arise from compromise caused by poor code. Developing full ecommerce costs thousands of dollars to do. I wouldn't even consider taking an ecommerce project without a full team to help identify any flaws (second sets of eyes is always a benefit).
    If possible, don't deal with this type of information at all. Deal with an intermediary such as paypal instead.

  • Users who have thanked Fou-Lu for this post:

    dnnhater (11-16-2011)

  • #7
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,479
    Thanks
    63
    Thanked 538 Times in 525 Posts
    I'll second what Fou just said.
    I can't really think of anything to write here now...

  • Users who have thanked tangoforce for this post:

    dnnhater (11-16-2011)

  • #8
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    I was sooooooooooo afraid you were going to say that - but thank you just the same for saying it

    this is not for a ecommerce site, rather it is an internal site, but alas it is still accessible from the outside

    I will have to get back with the rest of the team and see how they want to proceed

    thanks to you both!

  • #9
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Quote Originally Posted by dnnhater View Post
    I was sooooooooooo afraid you were going to say that - but thank you just the same for saying it

    this is not for a ecommerce site, rather it is an internal site, but alas it is still accessible from the outside

    I will have to get back with the rest of the team and see how they want to proceed

    thanks to you both!
    You bet, sorry its not what you want to hear, but its better to go this route than to suggest something that may put you in hot water with a simple oversight. My suggestion would be to put paypal in there since the communication between them and yourself is basic. Worst case scenario is a poor transmission from them resulting in a "lost" payment (which would be viewable from the paypal side so it can be corrected easily enough), or an (potentially outbound) modification of an order amount which is also correctable at a later time (and typically caught by a purchaser anyway if the number is too high). Most of the legal burden falls directly on them, so its win win for you (plus no merchant fees to worry about ). All that for a small fee from paypal is IMO a much better idea.

  • #10
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    well as I said - this isn't an ecommerce site so it has nothing to do with credit cards (and I already do use PayPal for any site that takes a payment), but there would be storage of ss#'s - so it's still the same problem

    what we've decided to do is to keep the master spreadsheet we're currently using and import parts to the website that do not contain sensitive data - we'll still be able to do the reporting we want (kinda like snapshots of weekly or monthly activity) and if a manager needs more detailed information (including the sensitive info), they can go to the person who is maintaining the master spreadsheet direct

    ultimately our goal was to get information to as many people as needed it without having to double enter everything and I think I'm going to be able to achieve both goals and still be able to protect personal info

    thanks again for the advice and cheers to me to think to ask before getting in over my head!

  • #11
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Quote Originally Posted by dnnhater View Post
    well as I said - this isn't an ecommerce site so it has nothing to do with credit cards (and I already do use PayPal for any site that takes a payment), but there would be storage of ss#'s - so it's still the same problem

    what we've decided to do is to keep the master spreadsheet we're currently using and import parts to the website that do not contain sensitive data - we'll still be able to do the reporting we want (kinda like snapshots of weekly or monthly activity) and if a manager needs more detailed information (including the sensitive info), they can go to the person who is maintaining the master spreadsheet direct

    ultimately our goal was to get information to as many people as needed it without having to double enter everything and I think I'm going to be able to achieve both goals and still be able to protect personal info

    thanks again for the advice and cheers to me to think to ask before getting in over my head!
    This sounds like a fair compromise. External access should never share the same database (and preferably database server) as an internal information database. Its a tremendous waste of space to essentially replicate data since these machines shouldn't be able to talk to each other, but well worth the expense.
    Its unfortunate, but no user should be considered trustworthy. Always program under the assumption that a user is out to exploit it.

  • #12
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    agreed

    ok so watch for my next post as I get lost trying to upload the csv, and read and insert those values...

  • #13
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Quote Originally Posted by dnnhater View Post
    agreed

    ok so watch for my next post as I get lost trying to upload the csv, and read and insert those values...
    PHP has csv capabilities. Look into using fgetcsv to parse it.

  • #14
    New Coder
    Join Date
    Jul 2011
    Location
    Sunshine State
    Posts
    80
    Thanks
    18
    Thanked 0 Times in 0 Posts
    yep way ahead of you on that one - have to work to restructure the spreadsheet a wee bit first


  •  

    Posting Permissions

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