<?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>exploring software and hardware security &#187; browser security</title>
	<atom:link href="http://securityblog.astida.com/category/browser-security/feed/" rel="self" type="application/rss+xml" />
	<link>http://securityblog.astida.com</link>
	<description>articles about secure systems, secure protocols, tamperproofing, obfuscation, authentication, attack vectors...</description>
	<lastBuildDate>Tue, 10 Nov 2009 20:44:57 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Conventional website authentication model, its weaknesses and alternatives</title>
		<link>http://securityblog.astida.com/2009/09/27/conventional-website-authentication-model-and-its-weaknesses/</link>
		<comments>http://securityblog.astida.com/2009/09/27/conventional-website-authentication-model-and-its-weaknesses/#comments</comments>
		<pubDate>Sun, 27 Sep 2009 08:04:44 +0000</pubDate>
		<dc:creator>davitb</dc:creator>
				<category><![CDATA[authentication]]></category>
		<category><![CDATA[browser security]]></category>
		<category><![CDATA[HTTPS]]></category>
		<category><![CDATA[man-in-the-middle]]></category>
		<category><![CDATA[passwords]]></category>
		<category><![CDATA[pharming]]></category>
		<category><![CDATA[phishing]]></category>
		<category><![CDATA[SSL]]></category>

		<guid isPermaLink="false">http://securebox.wordpress.com/?p=77</guid>
		<description><![CDATA[The current article discusses the problems of authentication schemes that are used by websites and browsers while the user logs in to a website.
The following topics will be covered:

Conventional user and website authentication model
Weak points of password based authentication
Weak points of website authentication
Alternative ways for user authentication in websites

Note that by the term “conventional” we [...]]]></description>
			<content:encoded><![CDATA[<p>The current article discusses the problems of authentication schemes that are used by websites and browsers while the user logs in to a website.</p>
<p>The following topics will be covered:</p>
<ul>
<li>Conventional user and website authentication model</li>
<li>Weak points of password based authentication</li>
<li>Weak points of website authentication</li>
<li>Alternative ways for user authentication in websites</li>
</ul>
<p>Note that by the term “conventional” we mean the most popularly used authentication scheme – username/password.</p>
<p><span id="more-77"></span></p>
<h3><strong>Conventional user authentication model</strong></h3>
<p>Conventional authentication scheme for websites and users is based on two steps:</p>
<ul>
<li>User’s internet browser authenticates the website with PKI (through SSL)</li>
<li>Website authenticates the user with username and password</li>
</ul>
<p>Currently most websites require only username and password for user authentication although it’s obvious that the data they are storing on web servers and their services require much stronger security than the passwords can provide.</p>
<h3><strong>Weak points of password based authentication</strong></h3>
<p>Passwords are prone to many attacks, such as:</p>
<ul>
<li>Weak passwords
<ul>
<li>Although there are many recommendations for constructing more secure pass phrases – these recommendations don’t provide the desired effect as the users usually give higher priority to the factor of remembering the password rather than making it secure</li>
</ul>
</li>
</ul>
<ul>
<li>Social Engineering based attacks
<ul>
<li>Passwords are usually designed around personal characteristics of the user (names, birthdays), their friends or relatives</li>
<li>This makes easy to retrieve a password by doing basic social engineering</li>
<li>Users tend to write their passwords on a paper and keep it somewhere close to the computer</li>
</ul>
</li>
</ul>
<ul>
<li>Phishing attacks
<ul>
<li>User’s credentials (username and password) can be obtained by conducting phishing attacks. Those will be discussed in details later in this article.</li>
</ul>
</li>
</ul>
<ul>
<li>Pharming attacks
<ul>
<li>The concept is very similar to phishing attack. The following link provides thorough explanation of this type of attack:<br />
<a href="http://en.wikipedia.org/wiki/Pharming">http://en.wikipedia.org/wiki/Pharming</a></li>
</ul>
</li>
</ul>
<ul>
<li>Malware steals the password
<ul>
<li>Man in the browser malware can easily obtain user’s password after it is submitted to the HTML form</li>
<li>Keyloggers can easily obtain user’s password while it is being entered in a password field</li>
<li>Man in the middle malwares can easily obtain these passwords (this is true if SSL is not used for website authentication)</li>
</ul>
</li>
</ul>
<p>It’s also important to mention that passwords provide only “something you know” authentication factor and if this knowledge is stolen – the attacker can have access to any data and operation that the user has access to.</p>
<p>Having all these said it’s obvious that password based authentication cannot remain the primary scheme for websites which keep sensitive information about users or provide valuable services (like financial or privacy related).</p>
<p><strong> </strong></p>
<h3><strong>Weak points of website authentication</strong></h3>
<p>Although PKI based SSL authentication provides a very strong trust, while visiting websites, there is still one issue which remains unresolved for internet users and websites. This is the problem of phishing. The user, who enters a website, doesn’t pay enough attention to the website’s name and thus can be prone to obvious attacks.</p>
<p>The browser developers didn’t yet invent a proper way to notify the user about website identity (identity can be the website name, something else describing it uniquely… can you think a better way to identify a website than the URL?) she is entering to. For example if you see a link with name “pEypal.com” you may probably not notice it, treat it as “paypal.com” ad just trust it. This is actually what phishing attacks are based on.</p>
<p>In my opinion this problem has two major points. The first is in the browser and the second – in website’s identity.</p>
<ul>
<li>Browser developers must convince the user to always pay attention to the website’s identity (currently URL) they are visiting to</li>
<li>Websites (or Web) must invent a new approach for website identity</li>
</ul>
<p>So the fact is that although website authentication is based on the strongest cryptographic algorithms and protocols – it is still not perfect. Let’s discuss here how phishing attacks work.</p>
<ul>
<li>Attacker creates a website with a similar name that the original one (like for paypal.com it would be smth like peypal.com)</li>
<li>Attacker sends some message (email) to the user from Paypal’s name and asks the user to enter <a href="http://www.peypal.com/">www.peypal.com</a> for more information.</li>
<li>P<span style="text-decoration: underline;">e</span>ypal.com has a very similar user interface as paypal.com and the user likely won’t notice that this is not the real paypal.com</li>
<li>The user provides her username and password, peypal.com first stores this info internally and then redirects this information to the original paypal.com</li>
<li>User is logged in paypal.com and has no doubt that his credentials have been stolen</li>
<li>Refer to the following resource for more information about these popular attacks:<a href="http://en.wikipedia.org/wiki/Phishing"><br />
http://en.wikipedia.org/wiki/Phishing</a></li>
</ul>
<p><strong> </strong></p>
<h3><strong>Alternative ways of user authentication by websites</strong></h3>
<p>In spite of the weaknesses we have mentioned for password based authentication it’s still the most popular authentication scheme used by everyone in the Web – financial institutions, social websites, emails, etc. Of course the reason behind this is not that website developers are not aware of these problems. The problem is that secure alternative approaches require a specialized hardware or software which the users are not willing to buy and install.</p>
<p>The security of user authentication model could be significantly strengthen by integrating specialized hardware such as OTP (One time password) tokens, PKCS#11 tokens, biometric devices (although these still have privacy related problems), corresponding software components. However these hardware tokens cost money and the users, as a rule, are not willing to pay for them – even if it doesn’t cost much. Users also don’t want to download and install software components (applications, browser plugins) for this purpose, because they don’t trust these applications. So how this problem can be solved?</p>
<p>I think the only way to solve it is to use the power that ODMs have. ODMs have a full control of the hardware and software that is being installed <span style="text-decoration: underline;">by default</span> on laptops or PCs. If they decide to integrate a hardware token (and accompanying software) on laptops by default – the abovementioned problem would be solved automatically. Users would obtain a much higher level of security with such systems.</p>
<p>A good example of such hardware token is a fingerprint device which is already in its way to become a mainstream for laptop market.</p>
<p>Let’s summarize the list of alternative ways that hardware tokens or software components can provide for better user authentication:</p>
<ul>
<li>Hardware tokens with OTP support
<ul>
<li>RSA SecureID, Vasco, Yubico, etc</li>
</ul>
</li>
</ul>
<ul>
<li>Cryptographic tokens which support PKCS#11
<ul>
<li>The website could completely support PKI and provide each user with a certificate</li>
<li>The private key of user would be embedded in a PKCS#11 enabled hardware token</li>
<li>In this case two side SSL would be established between the user’s machine and website when the hardware token is connected to the system</li>
<li>Additional factor would be added to authentication scheme if this hardware token generated RSA signature only when, for example, the user provides pre-enrolled biometrics (such as swipes a valid finger)</li>
</ul>
</li>
</ul>
<ul>
<li>Special software could be installed on the user’s machine and provide a better authentication for users
<ul>
<li>As it was mentioned before the problem with this solution is that users usually don’t want to download and install unknown software from web</li>
</ul>
</li>
</ul>
<a class="a2a_dd addtoany_share_save" href="http://www.addtoany.com/share_save?linkurl=http%3A%2F%2Fsecurityblog.astida.com%2F2009%2F09%2F27%2Fconventional-website-authentication-model-and-its-weaknesses%2F&amp;linkname=Conventional%20website%20authentication%20model%2C%20its%20weaknesses%20and%20alternatives"><img src="http://securityblog.astida.com/wp-content/plugins/add-to-any/share_save_171_16.png" width="171" height="16" alt="Share/Bookmark"/></a>]]></content:encoded>
			<wfw:commentRss>http://securityblog.astida.com/2009/09/27/conventional-website-authentication-model-and-its-weaknesses/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

