<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Thu, 20 Jun 2013 01:13:39 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Sherif Ramadan: Password Hashing And Why People Do It Wrong]]></title>
      <guid>http://www.phpdeveloper.org/news/19663</guid>
      <link>http://www.phpdeveloper.org/news/19663</link>
      <description><![CDATA[<p>
In a recent post to his site <i>Sherif Ramadan</i> looks at the topic of password hashing and why most developers are (still) doing it wrong. He notes that "fixing the people" and their mindset about hashing/salting is much harder than just fixing the code.
</p>
<blockquote>
Beyond just writing code I also have to solve some very tough problems on a regular basis. Some of which don't stem from code at all, but from the people behind the code. Fixing code is easy for me (computers just do what I tell them to do), but fixing people proves to be a lot more challenging. Unfortunately some people are of the mindset that they aren't wrong simply because they've never been proven wrong before. To some people being proven wrong goes beyond just words. Some of us are a lot more stubborn than others and so explaining something may not be enough. This is called the wisdom of humility.
</blockquote>
<p>
He points out that even those that immediately think "rainbow tables" when they think about md5 hashing are behind the times. Most processing methods, including the use of <a href="http://en.wikipedia.org/wiki/Graphics_processing_unit">a GPU</a>, can be used much more effectively and don't require the overhead of the large tables. He illustrates with a "random" md5 generator that outputs around 916 million variations. With a GPU running 4k million per second, this kind of cracking won't take long. He also talks about salts and how they can help the situation - but not just append it, hash with it.
</p>
<blockquote>
 It's usually the result of several underlying factors that people end up making poor choices about security. Some times it's due to incompetence. Other time it's due to politics. Whatever the reasons are they are never excusable, because there are better alternatives out there and it's not as though they are more difficult or less available than others. So there really are no good reasons [not to do it] here.
</blockquote>
Link: https://sheriframadan.com/2013/05/password-hashing]]></description>
      <pubDate>Mon, 03 Jun 2013 12:18:26 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Joshua Thijssen's Blog: Password hashing and salting]]></title>
      <guid>http://www.phpdeveloper.org/news/15853</guid>
      <link>http://www.phpdeveloper.org/news/15853</link>
      <description><![CDATA[<p>
<i>Joshua Thijssen</i> has a new post to his blog looking at <a href="http://www.adayinthelifeof.nl/2011/02/02/password-hashing-and-salting/">password hashing and salting</a> - something that, really, should always be done to help protect your site's user information.
</p>
<blockquote>
Even though it is true in effect that using a salt increases the overall security of your hashes BUT it's not only because your passwords are longer. There is a another (maybe even more important) factor that comes into play, namely the fact they are more secure against rainbow table attacks, but that depends on HOW you season your hashes. Season it incorrectly, and you gain nothing in security even though you think you did...
</blockquote>
<p>
He gets into some of the details about hashing your information, how you can break that hash easily and how salting your information can help reduce that risk. He also points out things like rainbow tables and brute force that could still break these salted passwords.He recommends using a different method than a single salt - a different one for each user with a part stored in plain-text along with the user record.
</p>]]></description>
      <pubDate>Thu, 03 Feb 2011 12:16:31 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[DevShed: User Authentication and PHP Security]]></title>
      <guid>http://www.phpdeveloper.org/news/7329</guid>
      <link>http://www.phpdeveloper.org/news/7329</link>
      <description><![CDATA[<p>
DevShed is continuing their series on PHP security with <a href="http://www.devshed.com/c/a/Security/User-Authentication-and-PHP-Security/">this new tutorial</a> focusing on the security surrounding user authentication.
</p>
<blockquote>
So far we have covered security vulnerabilities that involve form data, databases and file systems. In this article we are going to look at authentication and the security issues around it. We will also look at some of the most common attacks in this field.
</blockquote>
<p>
They start things off by describing two of the usual authentication methods - via a login form and through HTTP authentication. They start poking a few holes by looking at some of the common attacks for these approaches including two popular ones - brute force attacks and password sniffing.
</p>]]></description>
      <pubDate>Thu, 22 Feb 2007 10:51:00 -0600</pubDate>
    </item>
  </channel>
</rss>
