<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body ><div>That's why I check all of the client certificates in a monthly checklist. Then I will know if another browser, or device has authenticated with a stolen yubikey. Also, I don't carry a yubikey with me AT ALL. I have them locked in a safe at home.</div><div><br></div><div><br></div><div><div style="font-size:8px;color:#575757">Sent from my Verizon Wireless 4G LTE smartphone</div></div><br><br><div>-------- Original message --------</div><div>From: Angelo McComis <angelo@mccomis.com> </div><div>Date:05/24/2014  12:21 PM  (GMT-05:00) </div><div>To: Central OH Linux User Group - 432xx <colug-432@colug.net> </div><div>Cc: Central OH Linux User Group - 432xx <colug-432@colug.net> </div><div>Subject: Re: [colug-432] password survey </div><div><br></div><br><br>&gt; On May 24, 2014, at 11:46 AM, Rob Funk &lt;rfunk@funknet.net&gt; wrote:<br>&gt; <br>&gt; The problem is that it doesn't solve the problem of existing protocols. SSH <br>&gt; is great, but that doesn't help with logging into Google or my bank or my <br>&gt; company's mail server, much less using my phone to do those things, nor <br>&gt; with getting random non-techies secure access to what they need.<br><br>Bingo. Unless said entity has their encrypted passwords ripped through some kind of internal-based exploit and those hashes can then be reverse engineered.&nbsp; By internal, I am inferring an inside job or a bad guy that has worked his way into the inside. <br><br>The best way on these is to change your password regularly and make them reasonably secure. For example, I use a combination of alpha numeric and symbols but originates from a purposely&nbsp; misspelled word. Thus that won't ever come up on a dictionary based 0/o, I/1, r/4, e/3 "leet substitution" combined attack.&nbsp; Also account lockout and other mitigating measures is smart to implement on the hosting side to slow down brute attempts. <br><br>Yubikey could be circumvented pretty easily. Borrow the device. Open vi, press the button. Watch it output the 44 chars, save that out or take a pic of it and now you have the secure string it uses. If it we're to use a "very long" string, that might be say 4096 chars, it would still be possible to compromise in the same manner but a bit more difficult to manage carrying a string of that length around in a way you could easily input it to open your lastpass vault. <br><br><br>_______________________________________________<br>colug-432 mailing list<br>colug-432@colug.net<br>http://lists.colug.net/mailman/listinfo/colug-432<br></body>