<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Secure PHP/JavaScript login without SSL</title>
	<atom:link href="http://www.lightcubesolutions.com/blog/?feed=rss2&#038;p=47" rel="self" type="application/rss+xml" />
	<link>http://www.lightcubesolutions.com/blog/?p=47</link>
	<description>Hints, experiences and insights from LightCube Solutions</description>
	<lastBuildDate>Sun, 15 Aug 2010 22:11:55 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: JH</title>
		<link>http://www.lightcubesolutions.com/blog/?p=47&#038;cpage=1#comment-79</link>
		<dc:creator>JH</dc:creator>
		<pubDate>Sun, 12 Jul 2009 17:53:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightcubesolutions.com/blog/?p=47#comment-79</guid>
		<description>(Replying to Alexander): You&#039;re right, there are still potential weaknesses with this method. However, the threat you pointed out could still exist when using SSL encrypted connections, depending on how the passwords are stored, as the admins could still sell passwords or password equivalents. As you say, defining the model becomes important. In this particular scenario, we assume that the admins can be trusted not to sell password equivalents, but the actual password remains a personal and privately known string.  For the stated purpose of sending private password strings over an unencrypted connection, this method does fill the need.

Even so, thanks for the pointer to SRP, it will be something I will look into more as I have time.</description>
		<content:encoded><![CDATA[<p>(Replying to Alexander): You&#8217;re right, there are still potential weaknesses with this method. However, the threat you pointed out could still exist when using SSL encrypted connections, depending on how the passwords are stored, as the admins could still sell passwords or password equivalents. As you say, defining the model becomes important. In this particular scenario, we assume that the admins can be trusted not to sell password equivalents, but the actual password remains a personal and privately known string.  For the stated purpose of sending private password strings over an unencrypted connection, this method does fill the need.</p>
<p>Even so, thanks for the pointer to SRP, it will be something I will look into more as I have time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander E. Patrakov</title>
		<link>http://www.lightcubesolutions.com/blog/?p=47&#038;cpage=1#comment-55</link>
		<dc:creator>Alexander E. Patrakov</dc:creator>
		<pubDate>Wed, 24 Dec 2008 06:24:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.lightcubesolutions.com/blog/?p=47#comment-55</guid>
		<description>The solution above has a &quot;plaintext password equivalent&quot; stored on the server. So, let&#039;s assume the following threat: someone steals the file with SHA1 sums of the passwords. The information in this file is sufficient to authenticate against the PHP script, using a modified JavaScript (it should be easy to rewrite using GreaseMonkey). So, if we assume this threat model, the first hash in &quot;both server and client append the password’s hash to the random string and perform a hash sum on the combined string&quot; is useless. Of course it does prevent the admins from looking at the passwords, but they can still sell SHA1 sums together with a GreaseMonkey thing. Thus, when discussing such security solutions, it is necessary to specify the threat model explicitly.

OTOH, there is an authentication protocol that neither has a plaintext password equivalent stored on the server, nor sends the unencrypted password over the wire: SRP (&lt;a href=&quot;http://www.ietf.org/rfc/rfc2945.txt&quot; rel=&quot;nofollow&quot;&gt;RFC 2945&lt;/a&gt;). And it can be &lt;a href=&quot;http://srp.stanford.edu/demo/demo.html&quot; rel=&quot;nofollow&quot;&gt;implemented with JavaScript and Java&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>The solution above has a &#8220;plaintext password equivalent&#8221; stored on the server. So, let&#8217;s assume the following threat: someone steals the file with SHA1 sums of the passwords. The information in this file is sufficient to authenticate against the PHP script, using a modified JavaScript (it should be easy to rewrite using GreaseMonkey). So, if we assume this threat model, the first hash in &#8220;both server and client append the password’s hash to the random string and perform a hash sum on the combined string&#8221; is useless. Of course it does prevent the admins from looking at the passwords, but they can still sell SHA1 sums together with a GreaseMonkey thing. Thus, when discussing such security solutions, it is necessary to specify the threat model explicitly.</p>
<p>OTOH, there is an authentication protocol that neither has a plaintext password equivalent stored on the server, nor sends the unencrypted password over the wire: SRP (<a href="http://www.ietf.org/rfc/rfc2945.txt" rel="nofollow">RFC 2945</a>). And it can be <a href="http://srp.stanford.edu/demo/demo.html" rel="nofollow">implemented with JavaScript and Java</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
