[OWASP_PHPSEC] Second Library - Password Management

Abbas Naderi abiusx at owasp.org
Wed May 29 05:26:06 UTC 2013


Well that is the dynamic salt. We need to concatenate it with a long static salt and hash passwords. Static salt would better be a random long string, stored somewhere in code files, and should be unique per setup.
-Abbas
On ۸ خرداد ۱۳۹۲, at ۹:۵۵, rahul chaudhary <rahul300chaudhary400 at gmail.com> wrote:

> aaah...how can I ever miss the 5th point...I am so embarrassed. Anyways...so what if we just use the random salts for each passwords and store those random salts in the DB??
> 
> 
> On Wed, May 29, 2013 at 1:22 AM, Abbas Naderi <abiusx at owasp.org> wrote:
> Hi all,
> Unfortunately your solution is flawed.
> 1. You can not re-encrypt a hashed content. You will be needing a plaintext password for that.
> 2. If your passwords are leaked, someone has gained access to your database, and probably has access to your files (read-only) as well. So they just read the password from database.
> 3. You can not index (B-Tree, Hash) encrypted content in a database, and thus can not query them effectively.
> 4. A salted and hashed password is secure enough. Encryption does not add extra security.
> 5. We do not need to hash the password, then send it to server. If we do that, it means that the password is actually the hashed password, so a hacker obtaining the hashed password can send it to server instead of password. Hash challenges are a different story, but yet unnecessary. HTTPS will do it all.
> 
> -Abbas
> On ۸ خرداد ۱۳۹۲, at ۹:۴۰, rahul chaudhary <rahul300chaudhary400 at gmail.com> wrote:
> 
> > so can we do this??
> >
> > first user enters their passwords  in plaintext. their passwords gets simply hashed and reaches the server. We encrypt those hashes with a secret key of our own and store that encrypted string in DB (These strings as you pointed out, needs to be stored with extra security). Then we create a random salt and store this salt in DB......Then finally we hash the store encrypted string and the random salt and produce a final hash value stored in our DB...
> >
> >
> > PRO: If in case hashes gets stolen, they would anyways be encrypted with our secret key and so we can now do two things --- change the encryption key or change the encryption mechanism....so the user password will still be the same, but the underlying mechanism whole depends on the encryption key......As a side effect...it saves us from rainbow cracks also.
> >
> > CONS: It surely will take time because encryption can be bulky sometimes....but this is not much of a problem.
> >
> >
> > and for now we can just use SHA-512.
> 
> 
> 
> 
> -- 
> Regards,
> Rahul Chaudhary
> Ph - 412-519-9634

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130529/8d8ae303/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list