[OWASP_PHPSEC] Second Library - Password Management

Abbas Naderi abiusx at owasp.org
Wed May 29 07:33:22 UTC 2013


Let me know where you're stuck. The jframework library password class has a good rough estimate of what we're hpoing to have.
-Abbas
On ۸ خرداد ۱۳۹۲, at ۱۱:۵۵, rahul chaudhary <rahul300chaudhary400 at gmail.com> wrote:

> Hello All Mentors,
> 
> I need to have some specifications and final talk before I start implementing it. Till now I have achieved a general idea of what the library would be like and what functions need to be there. We just need to finalize the process to get going.
> 
> 
> On Wed, May 29, 2013 at 1:29 AM, rahul chaudhary <rahul300chaudhary400 at gmail.com> wrote:
> 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
> 
> 
> 
> -- 
> 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/25832a43/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list