<?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: Simple Two Way Encryption for Ruby on Rails</title>
	<atom:link href="http://www.erichurst.com/simple-two-way-encryption-for-ruby-on-rails/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.erichurst.com/simple-two-way-encryption-for-ruby-on-rails/</link>
	<description>Ruby on Rails Developer</description>
	<lastBuildDate>Sat, 14 Nov 2009 20:00:05 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: sco</title>
		<link>http://www.erichurst.com/simple-two-way-encryption-for-ruby-on-rails/comment-page-1/#comment-5774</link>
		<dc:creator>sco</dc:creator>
		<pubDate>Sat, 14 Nov 2009 20:00:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.erichurst.com/?p=361#comment-5774</guid>
		<description>Very cool, nice that the gem supports that.

Another solution (sort of) is to use asymmetric (public key) encryption -- so that one key is used to encrypt stuff, but another key is require to decrypt it. E.g., if you&#039;re storing credit card numbers, you could set up a separate billing server with the private key, and keep it behind a very tight firewall. That way, you could give your attacker access to the whole database and application without revealing the secrets. Here&#039;s an old-but-good writeup on that approach: http://blog.leetsoft.com/2006/03/14/simple-encryption</description>
		<content:encoded><![CDATA[<p>Very cool, nice that the gem supports that.</p>
<p>Another solution (sort of) is to use asymmetric (public key) encryption &#8212; so that one key is used to encrypt stuff, but another key is require to decrypt it. E.g., if you&#8217;re storing credit card numbers, you could set up a separate billing server with the private key, and keep it behind a very tight firewall. That way, you could give your attacker access to the whole database and application without revealing the secrets. Here&#8217;s an old-but-good writeup on that approach: <a href="http://blog.leetsoft.com/2006/03/14/simple-encryption" rel="nofollow">http://blog.leetsoft.com/2006/03/14/simple-encryption</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric Hurst</title>
		<link>http://www.erichurst.com/simple-two-way-encryption-for-ruby-on-rails/comment-page-1/#comment-5773</link>
		<dc:creator>Eric Hurst</dc:creator>
		<pubDate>Sat, 14 Nov 2009 19:20:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.erichurst.com/?p=361#comment-5773</guid>
		<description>Sco,

You are quite right. Sean addresses this challenge here: &lt;a href=&quot;http://wiki.github.com/shuber/attr_encrypted/questionsandanswers&quot; rel=&quot;nofollow&quot;&gt;http://wiki.github.com/shuber/attr_encrypted/questionsandanswers&lt;/a&gt;. Basically, set the key as a proc, and require the user to enter a password anytime they wish to access any encrypted data.</description>
		<content:encoded><![CDATA[<p>Sco,</p>
<p>You are quite right. Sean addresses this challenge here: <a href="http://wiki.github.com/shuber/attr_encrypted/questionsandanswers" rel="nofollow">http://wiki.github.com/shuber/attr_encrypted/questionsandanswers</a>. Basically, set the key as a proc, and require the user to enter a password anytime they wish to access any encrypted data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sco</title>
		<link>http://www.erichurst.com/simple-two-way-encryption-for-ruby-on-rails/comment-page-1/#comment-5772</link>
		<dc:creator>sco</dc:creator>
		<pubDate>Sat, 14 Nov 2009 19:15:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.erichurst.com/?p=361#comment-5772</guid>
		<description>Nice article. I think it&#039;s worth mentioning, though, that the encrypted data is only as safe as the key. So if an attacker just got access to the database, the SSNs are safe. But if they got access to the app server (or your git repo, or whatever), then the secrets would be out.</description>
		<content:encoded><![CDATA[<p>Nice article. I think it&#8217;s worth mentioning, though, that the encrypted data is only as safe as the key. So if an attacker just got access to the database, the SSNs are safe. But if they got access to the app server (or your git repo, or whatever), then the secrets would be out.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
