<?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: Google Adds 2-Factor Security to Gmail, Apps</title>
	<atom:link href="http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/feed/" rel="self" type="application/rss+xml" />
	<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/</link>
	<description>In-depth security news and investigation</description>
	<lastBuildDate>Thu, 20 Jun 2013 12:10:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Dave</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-19830</link>
		<dc:creator>Dave</dc:creator>
		<pubDate>Tue, 22 Mar 2011 16:16:11 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-19830</guid>
		<description><![CDATA[Saints - 

I was actually pleasantly surprised to find that Google has somewhat of a control to address this.  Services like POP/IMAP that do not support the 2-factor authentication cannot be used with your regular password.  They allow you to setup an &quot;application password&quot; that is a nice long, strong, password, that you use only with that one service.  Obviously it could still be compromised, but it is less likely to be compromised if you never type it in (safe from keyloggers) and you use it only for one service (less likely to escalate a compromise across services).  Google lets you have as many of these as you want.

-Dave]]></description>
		<content:encoded><![CDATA[<p>Saints &#8211; </p>
<p>I was actually pleasantly surprised to find that Google has somewhat of a control to address this.  Services like POP/IMAP that do not support the 2-factor authentication cannot be used with your regular password.  They allow you to setup an &#8220;application password&#8221; that is a nice long, strong, password, that you use only with that one service.  Obviously it could still be compromised, but it is less likely to be compromised if you never type it in (safe from keyloggers) and you use it only for one service (less likely to escalate a compromise across services).  Google lets you have as many of these as you want.</p>
<p>-Dave</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ross</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-18203</link>
		<dc:creator>Ross</dc:creator>
		<pubDate>Sun, 13 Feb 2011 14:08:53 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-18203</guid>
		<description><![CDATA[AD 

You are right to be circumspect to be dubious about such claims. However ours are not made lightly. 

If you take a bit of time to investigate the solution ( lots of information on the website )  - you will find that : 

It&#039;s not just the device, it&#039;s the session/user context for that factor, and we support third party factors as well - creating our &quot;N-Factor&quot; synthesis ( as opposed to a sequential exchange of credentials over the browser - used by most solutions today )  which generates a one time signature at the device and at our stack - which are then compared over a separate communication path ( not the browser).  

So yes -  it is not just the device and no a device on its own is not multi-factor authentication.  

Please test it for yourself.  Download the code / mash it up and use it on your own site.  You will be surprised.  It has been through pen tests with some of the biggest names in the industry.]]></description>
		<content:encoded><![CDATA[<p>AD </p>
<p>You are right to be circumspect to be dubious about such claims. However ours are not made lightly. </p>
<p>If you take a bit of time to investigate the solution ( lots of information on the website )  &#8211; you will find that : </p>
<p>It&#8217;s not just the device, it&#8217;s the session/user context for that factor, and we support third party factors as well &#8211; creating our &#8220;N-Factor&#8221; synthesis ( as opposed to a sequential exchange of credentials over the browser &#8211; used by most solutions today )  which generates a one time signature at the device and at our stack &#8211; which are then compared over a separate communication path ( not the browser).  </p>
<p>So yes &#8211;  it is not just the device and no a device on its own is not multi-factor authentication.  </p>
<p>Please test it for yourself.  Download the code / mash it up and use it on your own site.  You will be surprised.  It has been through pen tests with some of the biggest names in the industry.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AD</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-17980</link>
		<dc:creator>AD</dc:creator>
		<pubDate>Thu, 10 Feb 2011 23:18:52 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-17980</guid>
		<description><![CDATA[Re: Ross Macdonald - CEO of Liveensure

Device Fingerprinting is not multi factor authentication, no matter how much vendors like yourselves want to call it that.  It is generally considered a part of any authentication solution, usually as a mechanism for profiling a user&#039;s session to identify when it is necessary to request a higher level of authentication.  To claim that it is &quot;orders of magnitude&quot; stronger than a proper 2 factor system is laughable.]]></description>
		<content:encoded><![CDATA[<p>Re: Ross Macdonald &#8211; CEO of Liveensure</p>
<p>Device Fingerprinting is not multi factor authentication, no matter how much vendors like yourselves want to call it that.  It is generally considered a part of any authentication solution, usually as a mechanism for profiling a user&#8217;s session to identify when it is necessary to request a higher level of authentication.  To claim that it is &#8220;orders of magnitude&#8221; stronger than a proper 2 factor system is laughable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ross Macdonald</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10667</link>
		<dc:creator>Ross Macdonald</dc:creator>
		<pubDate>Sun, 26 Sep 2010 18:04:58 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10667</guid>
		<description><![CDATA[it is laudable that the big boys like Google have finally woken up to the fragility of the user name / password paradigm.  However there a few problems with the mobile phone route : 

1.  Cost - who carries the cost of the text messages ( especially cross border ) 
2.  Reliability - SMS is a store and forward protocol.  Fire and forget.  There are a number of reasons why it may not be delivered.  a)  Network congestion;  b) Bad network coverage ( in building )  c) Good old security - who is monitoring those text messages to make sure that no one from the network isn&#039;t actually &#039;skimming&#039; them? 

All is not lost. There is a solution that addresses all of the above. Check out www.liveensure.com.  This is a multi-factor authentication solution that is orders of magnitude stronger than this proposed solution.]]></description>
		<content:encoded><![CDATA[<p>it is laudable that the big boys like Google have finally woken up to the fragility of the user name / password paradigm.  However there a few problems with the mobile phone route : </p>
<p>1.  Cost &#8211; who carries the cost of the text messages ( especially cross border )<br />
2.  Reliability &#8211; SMS is a store and forward protocol.  Fire and forget.  There are a number of reasons why it may not be delivered.  a)  Network congestion;  b) Bad network coverage ( in building )  c) Good old security &#8211; who is monitoring those text messages to make sure that no one from the network isn&#8217;t actually &#8216;skimming&#8217; them? </p>
<p>All is not lost. There is a solution that addresses all of the above. Check out <a href="http://www.liveensure.com" rel="nofollow">http://www.liveensure.com</a>.  This is a multi-factor authentication solution that is orders of magnitude stronger than this proposed solution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JCitizen</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10641</link>
		<dc:creator>JCitizen</dc:creator>
		<pubDate>Fri, 24 Sep 2010 22:57:34 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10641</guid>
		<description><![CDATA[I don&#039;t really know - phones are getting pwned now too; but at least this should work on dumb cell phones, which is at least some protection. On a smart phone the malware could record the voice snippet and keylog the rest of it. I&#039;m not sure their are very many phones now, that are totally invulnerable to malware. Especially since people always want to connect them to the PC anyway - Oops! There goes the PC bank session too!

I was sure I read of a second factor phone jacking session on web security somewhere recently. However this is definitely better than 99.9999% of what most banks are doing, which is nearly nothing! Add a third factor, and you got a pretty tight system. Cell cameras should be a good source for something along this line!]]></description>
		<content:encoded><![CDATA[<p>I don&#8217;t really know &#8211; phones are getting pwned now too; but at least this should work on dumb cell phones, which is at least some protection. On a smart phone the malware could record the voice snippet and keylog the rest of it. I&#8217;m not sure their are very many phones now, that are totally invulnerable to malware. Especially since people always want to connect them to the PC anyway &#8211; Oops! There goes the PC bank session too!</p>
<p>I was sure I read of a second factor phone jacking session on web security somewhere recently. However this is definitely better than 99.9999% of what most banks are doing, which is nearly nothing! Add a third factor, and you got a pretty tight system. Cell cameras should be a good source for something along this line!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Hendricks</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10610</link>
		<dc:creator>Steve Hendricks</dc:creator>
		<pubDate>Fri, 24 Sep 2010 10:57:50 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10610</guid>
		<description><![CDATA[Brian-
My continuing struggle to get my local, small Town government to adopt a dedicated Linux OS for these delicate, high value data exchanges has brought me to a web service that seems to fill a void for those 2 groups (banks and clients) who can&#039;t  get institution offered, dual bandwidth transaction verification.
Called &quot;PhoneFactor&quot;,  it appears to have many security elements and features much needed by average home users who likewise insist on using Windows to bank.
It&#039;s worth looking at for those who aren&#039;t security experts, and it&#039;s free for some users.
http://www.phonefactor.com/how-it-works/overview]]></description>
		<content:encoded><![CDATA[<p>Brian-<br />
My continuing struggle to get my local, small Town government to adopt a dedicated Linux OS for these delicate, high value data exchanges has brought me to a web service that seems to fill a void for those 2 groups (banks and clients) who can&#8217;t  get institution offered, dual bandwidth transaction verification.<br />
Called &#8220;PhoneFactor&#8221;,  it appears to have many security elements and features much needed by average home users who likewise insist on using Windows to bank.<br />
It&#8217;s worth looking at for those who aren&#8217;t security experts, and it&#8217;s free for some users.<br />
<a href="http://www.phonefactor.com/how-it-works/overview" rel="nofollow">http://www.phonefactor.com/how-it-works/overview</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10564</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Thu, 23 Sep 2010 14:29:00 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10564</guid>
		<description><![CDATA[From a practical standpoint, there&#039;s a fairly great hurdle for a single bad guy to gain access to both a particular consumer&#039;s compromised phone and computer. So if a bank requires both of those, and you&#039;re not high-profile enough to actually be worth spending effort targeting, you&#039;re safe enough. (Now, if you do your banking from your phone, and the phone is the second factor, you&#039;re in a much riskier place.)]]></description>
		<content:encoded><![CDATA[<p>From a practical standpoint, there&#8217;s a fairly great hurdle for a single bad guy to gain access to both a particular consumer&#8217;s compromised phone and computer. So if a bank requires both of those, and you&#8217;re not high-profile enough to actually be worth spending effort targeting, you&#8217;re safe enough. (Now, if you do your banking from your phone, and the phone is the second factor, you&#8217;re in a much riskier place.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10563</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Thu, 23 Sep 2010 14:23:54 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10563</guid>
		<description><![CDATA[The concept is that you don&#039;t enter your password unless you see the picture showing you that you&#039;re on the right site. The picture is associated with a cookie on your machine, and if you go to a new machine you need to answer extra questions before you get the picture. So a man in the middle attack spoofing the bank&#039;s web server in theory can&#039;t show you the right picture, and you should get suspicious. If the bad guy prompts for the answers to the questions, though, most people will just answer without seeing that as a red flag. So in practice there&#039;s not that much difference between a password and a password plus answers to questions. (It&#039;s multiple single factors, not a 2-factor mechanism.) And if there&#039;s a zeus trojan controlling your computer, the bad guy can just log in from there and ignore the whole secret question issue (because your browser already has the cookie and won&#039;t be prompted to answer the questions). So the whole sitekey solution addresses only a small part of the problem, and does it in a way that requires an exceptionally alert customer to know when a sometimes-normal transaction is actually a red flag -- it&#039;s just window dressing to make it look like the institution cares about security. If they really cared about security they&#039;d implement an out-of-band transaction authentication which depends on something physical (not stored on the computer).]]></description>
		<content:encoded><![CDATA[<p>The concept is that you don&#8217;t enter your password unless you see the picture showing you that you&#8217;re on the right site. The picture is associated with a cookie on your machine, and if you go to a new machine you need to answer extra questions before you get the picture. So a man in the middle attack spoofing the bank&#8217;s web server in theory can&#8217;t show you the right picture, and you should get suspicious. If the bad guy prompts for the answers to the questions, though, most people will just answer without seeing that as a red flag. So in practice there&#8217;s not that much difference between a password and a password plus answers to questions. (It&#8217;s multiple single factors, not a 2-factor mechanism.) And if there&#8217;s a zeus trojan controlling your computer, the bad guy can just log in from there and ignore the whole secret question issue (because your browser already has the cookie and won&#8217;t be prompted to answer the questions). So the whole sitekey solution addresses only a small part of the problem, and does it in a way that requires an exceptionally alert customer to know when a sometimes-normal transaction is actually a red flag &#8212; it&#8217;s just window dressing to make it look like the institution cares about security. If they really cared about security they&#8217;d implement an out-of-band transaction authentication which depends on something physical (not stored on the computer).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JCitizen</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10482</link>
		<dc:creator>JCitizen</dc:creator>
		<pubDate>Tue, 21 Sep 2010 23:23:46 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10482</guid>
		<description><![CDATA[Although xAdmin has the best advice on smart practices, my clients refuse to comply. Therefor I felt forced to find what I though had the best idea for password management. 

Bear in mind I have no axe to grind and there may be better free managers out there. I picked LastPass because it was free, open source, stored all passwords and sensitive information in the cloud, came highly recommended by the IT community, communicated over SSL (of course) and stored no information on the client side hard drive. You only need one password to gain access to the console, so that one should be authored like xAdmin&#039;s guidelines. Changing it every three months or earlier isn&#039;t a bad idea either.

I read an article by Michael Kassner on TechRepublic where he worked with the developers at LastPass; and he did a remote session into his account and couldn&#039;t see any of the information himself without using his console! LastPass claims even local technicians have no access to the data. I must admit I don&#039;t understand their special host intrusion system, so I defer making comments on it.

All cautions about keyloggers and screen capture apply here, using a utility that works at the kernel level while you are infected is the best practice in preventing such attacks.]]></description>
		<content:encoded><![CDATA[<p>Although xAdmin has the best advice on smart practices, my clients refuse to comply. Therefor I felt forced to find what I though had the best idea for password management. </p>
<p>Bear in mind I have no axe to grind and there may be better free managers out there. I picked LastPass because it was free, open source, stored all passwords and sensitive information in the cloud, came highly recommended by the IT community, communicated over SSL (of course) and stored no information on the client side hard drive. You only need one password to gain access to the console, so that one should be authored like xAdmin&#8217;s guidelines. Changing it every three months or earlier isn&#8217;t a bad idea either.</p>
<p>I read an article by Michael Kassner on TechRepublic where he worked with the developers at LastPass; and he did a remote session into his account and couldn&#8217;t see any of the information himself without using his console! LastPass claims even local technicians have no access to the data. I must admit I don&#8217;t understand their special host intrusion system, so I defer making comments on it.</p>
<p>All cautions about keyloggers and screen capture apply here, using a utility that works at the kernel level while you are infected is the best practice in preventing such attacks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: xAdmin</title>
		<link>http://krebsonsecurity.com/2010/09/google-adds-2-factor-security-to-gmail-apps/comment-page-1/#comment-10470</link>
		<dc:creator>xAdmin</dc:creator>
		<pubDate>Tue, 21 Sep 2010 18:03:46 +0000</pubDate>
		<guid isPermaLink="false">http://krebsonsecurity.com/?p=5141#comment-10470</guid>
		<description><![CDATA[The best password manager is the human brain! Seriously.

While password managers use some type of encryption, the information is a: stored on the computer and b: is software that can be hacked on that computer. If your computer is compromised or stolen, that password information is included with it for the bad guys to hack into and use at will. That&#039;s also why I always turn off the browsers built-in autocomplete function that stores usernames and passwords and don&#039;t like password managers.

I know it&#039;s difficult to remember multiple passwords, but it is easier if you use passphrases of something you&#039;ll easily remember, but at the same time are complex enough to be difficult to hack. I use a few different ones and will use them randomly across a few non-critical accounts while anything critical such as online banking gets its own unique one for maximum security.

Besides, using your brain this way gives it exercise and helps your memory retention. :)]]></description>
		<content:encoded><![CDATA[<p>The best password manager is the human brain! Seriously.</p>
<p>While password managers use some type of encryption, the information is a: stored on the computer and b: is software that can be hacked on that computer. If your computer is compromised or stolen, that password information is included with it for the bad guys to hack into and use at will. That&#8217;s also why I always turn off the browsers built-in autocomplete function that stores usernames and passwords and don&#8217;t like password managers.</p>
<p>I know it&#8217;s difficult to remember multiple passwords, but it is easier if you use passphrases of something you&#8217;ll easily remember, but at the same time are complex enough to be difficult to hack. I use a few different ones and will use them randomly across a few non-critical accounts while anything critical such as online banking gets its own unique one for maximum security.</p>
<p>Besides, using your brain this way gives it exercise and helps your memory retention. <img src='http://krebsonsecurity.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached (User agent is rejected)
Database Caching 3/26 queries in 0.006 seconds using memcached
Object Caching 379/403 objects using memcached

 Served from: krebsonsecurity.com @ 2013-06-20 08:36:34 by W3 Total Cache -->