From reading numerous articles related to security, I'm planning to use SHA-256 and a salt for password and other security. Does anyone know of simple examples that walk through how this works and how to implement these?

Also, I understand that, in order to use SHA-256, MySQL has to have SSL enabled and I would need to have an SSL certificate. Is this correct? Does anyone know of background information to help in understanding this process (assuming it will be done on a hosted server)?

Thanks for any insight!

    From reading numerous articles related to security, I'm planning to use SHA-256 and a salt for password and other security. Does anyone know of simple examples that walk through how this works and how to implement these?

    If you want help on "other security", you should say exactly what it is. As for hashed password storage with a salt, this is just safety net security to protect careless users in the event that your database is compromised.

    Basically, you would have two columns in your relevant database table: one for the password hash, the other for the salt. The salt should be randomly generated for each user (e.g., using a hash of uniqid(mt_rand(), true) in PHP). To check if the password supplied by a user is valid, you would combine (e.g., concatenate) the password supplied with the salt, take the hash, and compare it with the hash stored in the database.

    Also, I understand that, in order to use SHA-256, MySQL has to have SSL enabled and I would need to have an SSL certificate. Is this correct? Does anyone know of background information to help in understanding this process (assuming it will be done on a hosted server)?

    I do not know if this is the case for MySQL (I associate SSL certificates with encrypted data transmission rather than backend password hashing), but you do not necessarily have to use a MySQL function for this. For example, the [man]hash[/man] extension in PHP that is enabled by default since PHP 5.1.2 includes support for SHA-256.

      Thanks for the insight. When I was wrote "other security", I was thinking about credit card numbers. If someone cracks into a database and steals credit card numbers and names, it would be nice to have the numbers scrambled. This implies, however, that the credit card numbers would need to be unscrambled to allow them to be validated periodically for charging purposes. That means that there would need to be some other method than one-way hashing. Does anyone have any thoughts/background with this issue?

        probably the absolute worst thing you could do is store the numbers even scrambled in the database unless you have a LOT of resources to throw at security and even then I don't think it would be on a list of priorities.

        As far as obscuring the passwords, you could take a page from osCommerce which will store the first so many digits, x's for the middle digits and then the last so many digits and then will email the digits that were replaced by x's to an email address for offline processing. Would make it more difficult to piece the data back together but if someone can comprise your system chances are they have access to your emails if they're browsing your database.

        The only other option that comes to mind would be to use something like the openSSL functions. Generate your own certificates, store then on your server and then use them to do forward and backward encryption of the cc numbers.

        Most online processors, from what i have seen, usually have api's that are designed so you post the raw processing data via SSL directly to the processor and then they (Authorize.net, paypal, etc. ) do live processing of the order and you then get certain data back as to whether it was successful or a failure etc.

          When I was wrote "other security", I was thinking about credit card numbers. If someone cracks into a database and steals credit card numbers and names, it would be nice to have the numbers scrambled. This implies, however, that the credit card numbers would need to be unscrambled to allow them to be validated periodically for charging purposes. That means that there would need to be some other method than one-way hashing. Does anyone have any thoughts/background with this issue?

          You can use strong encryption, but a possibly better way is not to store them at all: request them as needed (in which case you still need strong encryption for transmission), or use a reputable external payment processing service provider.

            thanks to you both for your insights.

              Write a Reply...