[OWASP_PHPSEC] Second Library - Password Management

rahul chaudhary rahul300chaudhary400 at gmail.com
Wed May 29 05:29:00 UTC 2013


so you mean to say that we will have passwords concatenated with static
salt and top of that we will also have random salts??


On Wed, May 29, 2013 at 1:26 AM, Abbas Naderi <abiusx at owasp.org> wrote:

> 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
>
>
>


-- 
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/4bf1228f/attachment.html>


More information about the OWASP_PHP_Security_Project mailing list