<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Angels of security &#187; transparency</title>
	<atom:link href="http://angelsofsecurity.com/blog/tag/transparency/feed/" rel="self" type="application/rss+xml" />
	<link>http://angelsofsecurity.com/blog</link>
	<description>Musings of an infosec renegade</description>
	<lastBuildDate>Tue, 02 Aug 2011 19:01:53 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>certificate names</title>
		<link>http://angelsofsecurity.com/blog/2010/07/20/certificate-names/</link>
		<comments>http://angelsofsecurity.com/blog/2010/07/20/certificate-names/#comments</comments>
		<pubDate>Tue, 20 Jul 2010 19:18:06 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[application security]]></category>
		<category><![CDATA[banks]]></category>
		<category><![CDATA[certificates]]></category>
		<category><![CDATA[disclosing]]></category>
		<category><![CDATA[end users]]></category>
		<category><![CDATA[transparency]]></category>

		<guid isPermaLink="false">http://angelsofsecurity.com/blog/?p=593</guid>
		<description><![CDATA[When it comes to preventing users from entering their data into fake websites, the main defense people always rely upon is user training. We&#8217;ve tried for years to train users to always look for the little lock icon that indicates the site is using SSL. Now we&#8217;re starting to train them to look for the [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://angelsofsecurity.com/blog/wp-content/uploads/2010/07/boa-cert.jpg"><img class="size-medium wp-image-595 alignright" title="boa cert error" src="http://angelsofsecurity.com/blog/wp-content/uploads/2010/07/boa-cert-300x284.jpg" alt="" width="187" height="176" /></a>When it comes to preventing users from entering their data into fake websites, the main defense people always rely upon is user training. We&#8217;ve tried for years to train users to always look for the little lock icon that indicates the site is using SSL. Now we&#8217;re starting to train them to look for the EV cert. Browser makers have gotten much better about making it more difficult for a user to bypass certificate errors. One of the biggest mistakes an entity can make is accidentally training their users for bad behavior, such as accepting certificate errors. Unfortunately, that is exactly what many people are doing. Many times someone will buy a certificate with their main www domain &#8211; for example <a href="http://www.bankofamerica.com">www.bankofamerica.com</a>, and forget about the domain bankofamerica.com. While the difference may seem trivial, any user that enters <a href="https://bankofamerica.com">https://bankofamerica.com</a> into their browser will be met with a certificate error, which they will ultimately have to accept if they want to continue. This is bad practice all around.</p>
<p>To prove my point, I decided to look at the <a href="http://www.onlinebankingreport.com/resources/100.html">10 largest banks in the US</a> and discovered that four of the ten exhibited this flaw. (Bank of NY Mellon does not seem to have a login on their main domain, and therefore don&#8217;t utilize SSL period). One would think that for a large financial institution like one of these, getting a multiple domain certificate would be a simple task, but apparently they never thought to do it. In the mean time, they&#8217;re training their users for poor security practices.</p>
<table>
<tbody>
<tr>
<td><a href="https://chase.com">JP Morgan Chase</a></td>
<td>good</td>
</tr>
<tr>
<td><strong><span style="color: #ff0000;"><a href="https://bankofamerica.com">Bank of America</a></span></strong></td>
<td><strong><span style="color: #ff0000;">Error</span></strong></td>
</tr>
<tr>
<td><a href="https://wellsfargo.com">Wells Fargo</a></td>
<td>good</td>
</tr>
<tr>
<td><strong><a href="https://citigroup.com">Citigroup</a></strong></td>
<td><strong><span style="color: #ff0000;">Error</span></strong></td>
</tr>
<tr>
<td><strong><a href="https://pncbank.com">PNC Bank</a></strong></td>
<td><strong><span style="color: #ff0000;">Error</span></strong></td>
</tr>
<tr>
<td><a href="https://us.hsbc.com">HSBC</a></td>
<td>Good</td>
</tr>
<tr>
<td>Bank of NY Mellon</td>
<td>N/A*</td>
</tr>
<tr>
<td><strong><a href="https://usbank.com">US Bankcorp</a><br />
</strong></td>
<td><strong><span style="color: #ff0000;">Error</span></strong></td>
</tr>
<tr>
<td><a href="https://suntrust.com">Suntrust Bank</a></td>
<td>good</td>
</tr>
<tr>
<td><a href="https://ssga.com">State Street Corp</a></td>
<td>good</td>
</tr>
</tbody>
</table>
]]></content:encoded>
			<wfw:commentRss>http://angelsofsecurity.com/blog/2010/07/20/certificate-names/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>more password studies</title>
		<link>http://angelsofsecurity.com/blog/2009/02/20/more-password-studies/</link>
		<comments>http://angelsofsecurity.com/blog/2009/02/20/more-password-studies/#comments</comments>
		<pubDate>Fri, 20 Feb 2009 21:04:26 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Access Control Systems & Methodology]]></category>
		<category><![CDATA[passwords]]></category>
		<category><![CDATA[phpbb]]></category>
		<category><![CDATA[transparency]]></category>

		<guid isPermaLink="false">http://angelsofsecurity.com/blog/2009/02/20/more-password-studies/</guid>
		<description><![CDATA[phpbb.com was broken into recently, and 20,000 passwords were revealed. There are two articles which attempt to draw conclusions from the data. One lists the 500 most common passwords, and the other does some analysis to try and get aggregate groupings. The bottom line: no matter how much training we do, even reasonably internet literate [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.phpbb.com/">phpbb.com</a> was broken into recently, and 20,000 passwords were revealed. There are two articles which attempt to draw conclusions from the data. One lists the <a href="http://www.whatsmypass.com/?p=415">500 most common passwords</a>, and the other does some analysis to try and get <a href="http://www.darkreading.com/blog/archives/2009/02/phpbb_password.html">aggregate groupings</a>.</p>
<p>The bottom line: no matter how much training we do, even reasonably internet literate people like the phpbb users, still pick crappy passwords. People don&#8217;t like remembering passwords, and therefore they find every conceivable measure to circumvent them. (See my previous post: <a href="/blog/2008/04/22/all-passwords-are-weak/">all passwords are weak</a>). If you&#8217;re developing a security system where the people who are supposed to be protected feel the need to circumvent the security, they will usually bring your security system down. Better to make a different system which is <a href="/blog/2008/04/06/security-and-transparency/">more transparent</a> to the people who you&#8217;re trying to protect.</p>
]]></content:encoded>
			<wfw:commentRss>http://angelsofsecurity.com/blog/2009/02/20/more-password-studies/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>All passwords are weak</title>
		<link>http://angelsofsecurity.com/blog/2008/04/22/all-passwords-are-weak/</link>
		<comments>http://angelsofsecurity.com/blog/2008/04/22/all-passwords-are-weak/#comments</comments>
		<pubDate>Tue, 22 Apr 2008 18:48:45 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Security Architecture and Design]]></category>
		<category><![CDATA[passwords]]></category>
		<category><![CDATA[transparency]]></category>

		<guid isPermaLink="false">http://angelsofsecurity.com/blog/2008/04/22/all-passwords-are-weak/</guid>
		<description><![CDATA[Far too much time is spent worrying whether passwords are strong or not. The main weakness passwords encounter though is not the string that defines them, but the human being that remembers them. In short, all passwords are weak, and it has nothing to do with string length, complexity, or password change rules. Recently I [...]]]></description>
			<content:encoded><![CDATA[<p>Far too much time is spent worrying whether passwords are strong or not. The main weakness passwords encounter though is not the string that defines them, but the human being that remembers them. In short, all passwords are weak, and it has nothing to do with string length, complexity, or password change rules.</p>
<p>Recently I got an email from someone I am close to which included his new password. It was not accidental or coerced &#8211; he simply mentioned it in his email (which went to about 5 or 6 people, myself included), as part of a funny anecdote. Now this person is not stupid. He is a practicing lawyer who works for the state government and has argued several times in front of his state supreme court. As a security professional I felt it my duty to inform him of the necessity of protecting passwords, but I know that it did no good. He reacted nonchalantly and simply did not seem to care. (It is also clear that he is <a href="http://blogs.wsj.com/biztech/2008/04/16/security-is-no-match-for-chocolate-and-good-looking-women/?mod=WSJBlog">not alone</a>).</p>
<p>IT folks have a tendency to blame the employee who gave out (or wrote down) their password, but the truth is the fault cannot ultimately lie with them. Competent clerks, secretaries, lawyers, doctors, and others who were born a generation prior to the explosion of the internet cannot be expected to be an expert in IT security, or even to understand anything about IT. The fault belongs to the people who architected the system and placed everyday users in the frontline position against attackers. I hate to harp on a single topic, but <a href="blog/2008/04/06/security-and-transparency/">security systems must be transparent to be effective</a>. The frontline defense against attacks should not be the users &#8211; it should be the trained security professionals. Making the least qualified people the first line of defense against attackers will always be a losing position.</p>
]]></content:encoded>
			<wfw:commentRss>http://angelsofsecurity.com/blog/2008/04/22/all-passwords-are-weak/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>security and transparency</title>
		<link>http://angelsofsecurity.com/blog/2008/04/06/security-and-transparency/</link>
		<comments>http://angelsofsecurity.com/blog/2008/04/06/security-and-transparency/#comments</comments>
		<pubDate>Mon, 07 Apr 2008 04:13:50 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Security Architecture and Design]]></category>
		<category><![CDATA[fundamentals]]></category>
		<category><![CDATA[transparency]]></category>

		<guid isPermaLink="false">http://angelsofsecurity.com/blog/2008/04/06/security-and-transparency/</guid>
		<description><![CDATA[People frequently wonder what makes a good security system. One of the frequently overlooked aspects is transparency. Simply put, the more transparent a system is, the less it will be noticed by the users. The reason for this is simple &#8211; users are frequently the most vulnerable link in the security chain. Worse than that, [...]]]></description>
			<content:encoded><![CDATA[<p>People frequently wonder what makes a good security system. One of the frequently overlooked aspects is transparency. Simply put, the more transparent a system is, the less it will be noticed by the users. The reason for this is simple &#8211; users are frequently the most vulnerable link in the security chain. Worse than that, if users perceive a security control to be an inconvenience, they will actively work to circumvent it.</p>
<p>I&#8217;ll take a simple example from my own life. The corporate laptop I use came with antivirus software installed. The software kept picking up a password cracking tool I was trying to use as a virus. (As a security analyst a password cracking tool is a legitimate part of my job). I tried to write an exception into the AV software, but I didn&#8217;t have the appropriate permissions. Eventually I had no choice but to simply disable the antivirus software entirely.  There are thousands of similar stories &#8211; employees propping doors open because there is no way to re-enter through a back door, sending sensitive information in the clear when a secure method of transmission can&#8217;t be located quickly, setting up rogue wireless access points, or a programmer writing a script which contains all of his or her login information to various internal systems. The bottom line is that security which is invisible is far less likely to be circumvented by frustrated users.</p>
]]></content:encoded>
			<wfw:commentRss>http://angelsofsecurity.com/blog/2008/04/06/security-and-transparency/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

