NYCPHP Meetup

[Edward Potter]

And it comes down to exactly what you are trying to protect. If someone
comes down and says, I'll chop off your head if you don't give me the key,
and it's the firms salary data, the odds are u just may give in. It's
probably on google anyway.

Remember Mata Hari was able to get top secret data (encryption keys, codes,
etc) as a spy in WW1. Just because. Well she was Mata Hari. :-)

>>>
The idea of an exotic dancer working as a lethal double agent, using her
powers of seduction to extract military secrets from her many lovers fired
the popular imagination, set the legend and made Mata Hari an enduring
archetype of the femme fatale <http://en.wikipedia.org/wiki/Femme_fatale>.

All the advice given is great. Use standard, industry approved methods, and
you'll be fine for 99.99% of what you'll need to accomplish.

Also try to make it to HOPE in July, the GIANT Hacker conf. It's in NYC,
it's pretty cool, even in the middle of July.

:-)



On Fri, May 7, 2010 at 12:12 PM, tedd <tedd.sperling at gmail.com> wrote:

> At 2:14 PM -0400 5/6/10, Nicholas Ilyin wrote:
>
>> Hi Anthony,
>>
>> In theory, no hashing function will ever be free from brute force attacks,
>> but this is a matter of how long one is willing to perform a brute force
>> attack to find the variable (a password) in a one-way hashing function. In
>> practice, some hashing functions have clear security flaws while others are
>> not yet known to have any.
>>
>> In your example it is best to stay away from MD5 as there are serious
>> security issues with it.
>>
>> SHA-1 is still a safe hashing function to use. You may find papers on the
>> internet that state that there was progress in finding collisions or
>> algorithmic strategies in significantly reducing the security of SHA-1, but
>> I am yet to see a solution that does not require astronomical computation to
>> render SHA-1 insecure.
>>
>> However, appending any plaintext to your password and hashing that, such
>> as SHA(username+password+username) is useless from a mathematical standpoint
>> as the username is actually known to a potential hacker. The way that hash
>> functions work would mean that adding any additional bits which are known
>> will not increase the security of your resulting hash.
>>
>> When you mention that "all are comprimisable by that simple manner" I have
>> to disagree. Although you are correct in saying that a brute force attack is
>> possible, a good encryption/hashing function will require so many
>> computations that even super computers would need to run for years to
>> actually break your encryption.
>>
>> Here are some recommendations that will increase the security of your
>> passwords:
>>
>> 1. Use a password strength checker which would not allow dictionary words
>> to be used for passwords. This eliminates a dictionary attack and requires
>> brute force.
>> 2. Require long passwords, such as over 10 characters. Each character is 8
>> bits of information which can significantly reduce the chance of a collision
>> with a brute force attack.
>> 3. Prevent automated attacks by locking down the account after 3 attempts
>> or so. Computation is on orders faster than a lockout time of 10 minutes
>> which will render any brute force attack completely useless in this case.
>> 4. Never allow an open connection on your DB server to the world, even if
>> you have 30 character passwords to access your SQL server. You should
>> tightly lockdown any and all access to your SQL server so that there is very
>> minimal access (such as from a web server).
>>
>> Hope this helps,
>>
>> Nick
>>
>
> Excellent advice. Saving a copy of it for my reference.
>
>
> Cheers,
>
> tedd
> --
> -------
> http://sperling.com  http://ancientstones.com  http://earthstones.com
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
IM/iChat: ejpusa
Links: http://del.icio.us/ejpusa
Follow me: http://www.twitter.com/ejpusa
Karma: http://www.coderswithconscience.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100508/4f15b82b/attachment.html>