<?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: Let&#8217;s talk about password storage</title>
	<atom:link href="http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/</link>
	<description>Engineering the web</description>
	<lastBuildDate>Fri, 17 May 2013 21:43:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Peek Inside &#124; TechSNAP 63 &#124; Jupiter Broadcasting</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223664</link>
		<dc:creator>Peek Inside &#124; TechSNAP 63 &#124; Jupiter Broadcasting</dc:creator>
		<pubDate>Fri, 22 Jun 2012 00:01:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223664</guid>
		<description><![CDATA[[...] Let’s talk about secure password storage  [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Let’s talk about secure password storage  [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Amr</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223618</link>
		<dc:creator>Amr</dc:creator>
		<pubDate>Tue, 19 Jun 2012 21:41:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223618</guid>
		<description><![CDATA[The challenge is not to crack this method or not, the challenge is how to package this technique in a way that would make reusable by other websites. There should be some easy-to-use solution for how to store passwords that would make it very difficult for website to pick up quickly and use. This will make the Internet better, this is part of Mozilla&#039;s mission.]]></description>
		<content:encoded><![CDATA[<p>The challenge is not to crack this method or not, the challenge is how to package this technique in a way that would make reusable by other websites. There should be some easy-to-use solution for how to store passwords that would make it very difficult for website to pick up quickly and use. This will make the Internet better, this is part of Mozilla&#8217;s mission.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fred Wenzel</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223164</link>
		<dc:creator>Fred Wenzel</dc:creator>
		<pubDate>Mon, 11 Jun 2012 19:11:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223164</guid>
		<description><![CDATA[bcrypt&#039;s salt has a fixed length, which is why bcrypt ships with its own gen_salt function: https://github.com/fwenzel/python-bcrypt/blob/6a7fb96/bcrypt/bcrypt.py#L48]]></description>
		<content:encoded><![CDATA[<p>bcrypt&#8217;s salt has a fixed length, which is why bcrypt ships with its own gen_salt function: <a href="https://github.com/fwenzel/python-bcrypt/blob/6a7fb96/bcrypt/bcrypt.py#L48" rel="nofollow">https://github.com/fwenzel/python-bcrypt/blob/6a7fb96/bcrypt/bcrypt.py#L48</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223162</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Mon, 11 Jun 2012 18:44:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223162</guid>
		<description><![CDATA[Why is the HMAC-strengthened password necessary? Why not just bcrypt(password, user_salt + system_nonce)?]]></description>
		<content:encoded><![CDATA[<p>Why is the HMAC-strengthened password necessary? Why not just bcrypt(password, user_salt + system_nonce)?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicholas Nethercote</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223077</link>
		<dc:creator>Nicholas Nethercote</dc:creator>
		<pubDate>Sun, 10 Jun 2012 23:00:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223077</guid>
		<description><![CDATA[Dan, I also don&#039;t recall any of the BrowserID blog posts explaining things this nicely :)]]></description>
		<content:encoded><![CDATA[<p>Dan, I also don&#8217;t recall any of the BrowserID blog posts explaining things this nicely <img src='http://blog.mozilla.org/webdev/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Storage Organizers</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-223065</link>
		<dc:creator>Storage Organizers</dc:creator>
		<pubDate>Sun, 10 Jun 2012 21:25:32 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-223065</guid>
		<description><![CDATA[MD5 is pretty loose there are free programs out there to decrypt it]]></description>
		<content:encoded><![CDATA[<p>MD5 is pretty loose there are free programs out there to decrypt it</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anon</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-222908</link>
		<dc:creator>anon</dc:creator>
		<pubDate>Sat, 09 Jun 2012 02:00:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-222908</guid>
		<description><![CDATA[Oh wow. This single post FINALLY made me understand the concept behind Persona. Somehow all the posts on the BrowserID blog (and following the Planet Mozilla since like a year) didn&#039;t help.
Thx a lot, Dan!]]></description>
		<content:encoded><![CDATA[<p>Oh wow. This single post FINALLY made me understand the concept behind Persona. Somehow all the posts on the BrowserID blog (and following the Planet Mozilla since like a year) didn&#8217;t help.<br />
Thx a lot, Dan!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Callahan</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-222879</link>
		<dc:creator>Dan Callahan</dc:creator>
		<pubDate>Fri, 08 Jun 2012 21:53:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-222879</guid>
		<description><![CDATA[Hi Laurian,

I&#039;m Dan, and I work on Persona. Whether or not Persona is a single point of failure is a great question, and one that we&#039;re trying hard to address. Fundamentally, Persona is built atop a distributed protocol that doesn&#039;t rely on any central servers or authority.

Think of it like this: With Persona, you&#039;ll be able to sign in to any supporting website by signing in to your email provider and passing along proof that you were able to do that. It gives you the ability to say to a website &quot;Hi, I&#039;m dcallahan@mozilla.com, and here&#039;s the proof.&quot;

To do that transaction completely autonomously, you only need a browser that supports Persona and an email provider that speaks the BrowserID protocol. But here&#039;s where things get tricky: No browser understands Persona (though we&#039;re working on it for Firefox 17!), nor do most email providers understand the BrowserID protocol.

So, what do we do?

As a fallback, we have a javascript library at browserid.org that takes care of Persona support on browsers that can&#039;t do it themselves. If that site goes down, those users won&#039;t be able to even attempt to log in to sites using Persona. We also host a service at that same site that signs credentials for users whose email providers don&#039;t understand the BrowserID protocol. For example, until gmail.com speaks the BrowserID protocol, Gmail users will have their credentials validated by our fallback at browserid.org.

This second bit *is* a single point of failure in terms of security: if browserid.org gets compromised, then attackers will be able to masquerade as Persona users on other websites. All of our code is open source and subject to peer review at https://github.com/mozilla/browserid, and we can also mitigate the damage of a breach by closing the hole and invalidating the cryptographic keys that we&#039;re using at browserid.org.

But remember, everything at browserid.org (soon to be login.persona.org) is a fallback. If your email provider speaks the BrowserID protocol (or if you add support to your own domain), then you&#039;re no longer at risk by a potential compromise at browserid.org. You get to choose who you trust, and, if you want, to take direct control of the security around your identity. Awesome!

...But doesn&#039;t that make your email provider a single point of failure? Yes, but it *already is.* If someone compromises your email address, it&#039;s trivial to gain access to your accounts elsewhere through their &quot;forgot password&quot; links. The difference with Persona is that *those* sites are no longer storing any sensitive authentication information, so, say, a LinkedIn leak won&#039;t put you at risk elsewhere.

Lastly, as to your question about having the browser proactively help users select and use better passwords, that&#039;s an active focus of Paul Sawaya&#039;s Watchdog project. :)

If you have any questions, please let me know! You can find the Identity team on irc.mozilla.org in #identity, or on our mailing list at https://lists.mozilla.org/listinfo/dev-identity.]]></description>
		<content:encoded><![CDATA[<p>Hi Laurian,</p>
<p>I&#8217;m Dan, and I work on Persona. Whether or not Persona is a single point of failure is a great question, and one that we&#8217;re trying hard to address. Fundamentally, Persona is built atop a distributed protocol that doesn&#8217;t rely on any central servers or authority.</p>
<p>Think of it like this: With Persona, you&#8217;ll be able to sign in to any supporting website by signing in to your email provider and passing along proof that you were able to do that. It gives you the ability to say to a website &#8220;Hi, I&#8217;m <a href="mailto:dcallahan@mozilla.com">dcallahan@mozilla.com</a>, and here&#8217;s the proof.&#8221;</p>
<p>To do that transaction completely autonomously, you only need a browser that supports Persona and an email provider that speaks the BrowserID protocol. But here&#8217;s where things get tricky: No browser understands Persona (though we&#8217;re working on it for Firefox 17!), nor do most email providers understand the BrowserID protocol.</p>
<p>So, what do we do?</p>
<p>As a fallback, we have a javascript library at browserid.org that takes care of Persona support on browsers that can&#8217;t do it themselves. If that site goes down, those users won&#8217;t be able to even attempt to log in to sites using Persona. We also host a service at that same site that signs credentials for users whose email providers don&#8217;t understand the BrowserID protocol. For example, until gmail.com speaks the BrowserID protocol, Gmail users will have their credentials validated by our fallback at browserid.org.</p>
<p>This second bit *is* a single point of failure in terms of security: if browserid.org gets compromised, then attackers will be able to masquerade as Persona users on other websites. All of our code is open source and subject to peer review at <a href="https://github.com/mozilla/browserid" rel="nofollow">https://github.com/mozilla/browserid</a>, and we can also mitigate the damage of a breach by closing the hole and invalidating the cryptographic keys that we&#8217;re using at browserid.org.</p>
<p>But remember, everything at browserid.org (soon to be login.persona.org) is a fallback. If your email provider speaks the BrowserID protocol (or if you add support to your own domain), then you&#8217;re no longer at risk by a potential compromise at browserid.org. You get to choose who you trust, and, if you want, to take direct control of the security around your identity. Awesome!</p>
<p>&#8230;But doesn&#8217;t that make your email provider a single point of failure? Yes, but it *already is.* If someone compromises your email address, it&#8217;s trivial to gain access to your accounts elsewhere through their &#8220;forgot password&#8221; links. The difference with Persona is that *those* sites are no longer storing any sensitive authentication information, so, say, a LinkedIn leak won&#8217;t put you at risk elsewhere.</p>
<p>Lastly, as to your question about having the browser proactively help users select and use better passwords, that&#8217;s an active focus of Paul Sawaya&#8217;s Watchdog project. <img src='http://blog.mozilla.org/webdev/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>If you have any questions, please let me know! You can find the Identity team on irc.mozilla.org in #identity, or on our mailing list at <a href="https://lists.mozilla.org/listinfo/dev-identity" rel="nofollow">https://lists.mozilla.org/listinfo/dev-identity</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephanie Daugherty</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-222878</link>
		<dc:creator>Stephanie Daugherty</dc:creator>
		<pubDate>Fri, 08 Jun 2012 21:52:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-222878</guid>
		<description><![CDATA[@Laurian Gridinoc - There&#039;s something along these lines already available in the form of a couple Firefox addons. https://addons.mozilla.org/en-US/firefox/addon/password-hasher/ is one. The idea is that the name of the site you are giving the password to is used as a salt, inherently making the password unique between sites and expanding the search space for someone trying to brute force it. Not foolproof, but it does buy you some time if one site gets hacked.
Not really a security guru or cryptographer, but from casual inspection, it probably falls somewhere square in the middle of typical passwords and cryptographically derived random passwords as far as security and resistance to brute force.]]></description>
		<content:encoded><![CDATA[<p>@Laurian Gridinoc &#8211; There&#8217;s something along these lines already available in the form of a couple Firefox addons. <a href="https://addons.mozilla.org/en-US/firefox/addon/password-hasher/" rel="nofollow">https://addons.mozilla.org/en-US/firefox/addon/password-hasher/</a> is one. The idea is that the name of the site you are giving the password to is used as a salt, inherently making the password unique between sites and expanding the search space for someone trying to brute force it. Not foolproof, but it does buy you some time if one site gets hacked.<br />
Not really a security guru or cryptographer, but from casual inspection, it probably falls somewhere square in the middle of typical passwords and cryptographically derived random passwords as far as security and resistance to brute force.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laurian Gridinoc</title>
		<link>http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/comment-page-1/#comment-222874</link>
		<dc:creator>Laurian Gridinoc</dc:creator>
		<pubDate>Fri, 08 Jun 2012 21:17:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=2772#comment-222874</guid>
		<description><![CDATA[Isn&#039;t Mozilla Persona a single point of failure? (think security and also QoS)

Why not have the browser enforce unique passwords, if I signup on Twitter with the password 12345, the browser could salt/hash/etc it.
Also when signing up to Facebook later the browser should not allow me to use a password I&#039;ve already used on another domain.]]></description>
		<content:encoded><![CDATA[<p>Isn&#8217;t Mozilla Persona a single point of failure? (think security and also QoS)</p>
<p>Why not have the browser enforce unique passwords, if I signup on Twitter with the password 12345, the browser could salt/hash/etc it.<br />
Also when signing up to Facebook later the browser should not allow me to use a password I&#8217;ve already used on another domain.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
