hi all, is it a good or bad idea to hash (SHA2) a password (with a salt) and then to encrypt the database with AES, in this scenario (assuming ssl for transporting the password from the client to the server for hashing before comparison) the hacker would need to decrypt the database THEN also crack the hash?
i’ve read a bit about hashing etc, i’ve heard not to hash twice etc, but not to hash and also encrypt that hash by encrypting the database
any advice?
thanks
Are you going to store credit card numbers? Or something that could lead you to prison? 
Using a salt with MD5 is just almost unhackable, if not at all.
no lol, i just want to re-assure customers that they could if they wanted to they could not only hide certain identiable info, but also encrypt it, i’m going by the fact that if i want to develop any kind of social networking site, security should be paramount since it’s application is so important in light of recent news.
i may eventually need to store credit card numbers yes, but if that can be done on the merchant (i.e paypal then) i don’t need to store them (minimising responsibility).
so is it a good idea?.. to: presalt : hash : previoussessionid(as post salt) -> encryption
p.s i’m not a chubby kiwi 
Https was invented for that purpose.
So, no. 
I wouldn’t add so much hashing.
MD5 is irreversible.
Salting MD5 makes ultra irreversible…
Keep in mind that it adds extra complexity and time. And when things do not work you will have a good time trying to see why.
What year are you living in? 1998?
Grandmothers can hack MD5 if the password is less then 10 characters… Always use Crypt() with blowfish encryption.
See: http://www.yiiframework.com/wiki/283/secure-password-hash-storage-and-a-yii-helper-extension/
I’m thinking SHA2 for the hashing with a blowfish salt… and AES for the encryption.
So back to the question, is it a good or bad idea (or is it pointless/redundant) to salt then hash then encrypt that salty hash?
(basically needing a key to decrypt a salted hash)
as well as https for the logged in session (as the compared password needs to be transported securely to the server to be hashed for comparison to the hashed password (which would need decrypting).
in structured english it would be like this:
set password aesencrypt( sha2crypt( password, blowfishsalt() ) )
(not sure how i’d break appart the salt from the hash, I assume the salt would be written to the database for that user record (again encrypted), I could even have the salt be regenerated everytime he logs in based on the session id.
overkill?
If you want extra security, why not use OTP (One Time Password)?
I use http://www.phpgangsta.de/ as the basis for my implementation which again uses Google Authenticator (Android) and/or JAuth (for the desktop) to generate the one time password that is required when the user logs in (in addition to the usual username/password combo).
This is my component:
<?php
require_once( dirname(__FILE__).'/PHPGangsta/GoogleAuthenticator.php' );
class YiiOTP extends CApplicationComponent
{
public $secretkey; // er, should this really be public? <img src='http://www.yiiframework.com/forum/public/style_emoticons/default/tongue.gif' class='bbc_emoticon' alt=':P' />
private $_ga;
private function getGangsta() {
if ($this->_ga===null)
$this->_ga = new PHPGangsta_GoogleAuthenticator();
return $this->_ga;
}
public function verify($currentcode) {
return $this->getGangsta()->verifyCode($this->secretkey, $currentcode, 0); // 2 = 2*30sec clock tolerance;
}
public function printBarCode() {
print sprintf('<img src="%s"/>', $this->getGangsta()->getQRCodeGoogleUrl('Blog', $this->secretkey));
}
public function getToken() {
return $this->getGangsta()->getCode($this->secretkey);
}
public function generateSecretkey($randomkey) {
return $this->getGangsta()->createSecret();
}
}
And, this is how I use it:
Model rules:
public function rules()
{
return array(
// username and password are required
array('username, password, token', 'required'),
// rememberMe needs to be a boolean
array('rememberMe', 'boolean'),
// password needs to be authenticated
array('password', 'authenticate'),
// token needs to be verified
array('token', 'verifytoken')
);
}
And the validator:
public function verifytoken($attribute, $params)
{
if( !Yii::app()->authenticator->verify($this->token) )
$this->addError('token', 'Invalid token: ' . $this->token);
}
To handle the password generation, you can use this: https://github.com/phpnode/YiiPassword
I mean, in addition to the OTP. For the password field in the User model.
It uses a salt and a hashing algorithm, just like has been talked about earlier in this topic.
Of course, the authenticator component needs to know the secret key:
'authenticator' => require(dirname(__FILE__) . '/key.php'),
//'authenticator' => array(
// 'class' => 'application.components.yiiOTP.YiiOTP',
// 'secretkey' => 'SECRET_KEY',
//),
I chose to load the from a file called ‘key.php’ which is not added to source control - for obvious reasons. ;p
Well that is certainly a novel way of going about the security, I do like the idea, and I appreciate the time and effort you have given me jacmoe. As long as it can be implemented in such a way that the log-in process is a task that is not too weird.
Again, would it be also weird for me to hide all the security in the way I initially proposed? I know it may take server resources, but my site will only have at most a few thousand members and maybe only a few hundred logged in at any one time.
Of course, there maybe be a lot more guests at any one time.
Hmm yes it could be by a brute force attack on plain MD5, but I don’t think that one salted could be, because the attacker wouldn’t know the salt.
Also, you would need to let the attacker try to login that many times to your site.
Things would be different if the attacker has your files.
Maybe having some sort of one way password set in some encryption mechanism.