[OWASP_PHPSEC] Second Library - Password Management
rahul300chaudhary400 at gmail.com
Wed May 29 05:25:08 UTC 2013
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.
> On ۸ خرداد ۱۳۹۲, at ۹:۴۰, rahul chaudhary <rahul300chaudhary400 at gmail.com>
> > 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.
Ph - 412-519-9634
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP_PHP_Security_Project