<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That's not scalable, and it's insecure on untrusted systems.</blockquote>
<div>Good to know :) Also; fantastic link. I'll have to move my systems over.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It really sucks having to type your token in every single time you want to log into any instance.</blockquote><div>Yep -- unfortunately no one has come up with a good method of making security convenient :D</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">OATH isn't any more secure than properly using ssh keys, anyway, since it's two-factor when a passphrase is used on the key.</blockquote>
<div>Sort of; theoretically I look at a keyed SSH key as only a 'something you have' measure -- once it's resident in memory it becomes single factor auth to the remote system -- hence entering the risks with agent-forwarding or having a malicious process on your machine then taking advantage of the in-memory key. Only if you are always required to enter a 'something you know' in addition to providing the 'something you have' then do I believe you have true two factor auth. We of course trade off the inconvenience with an assessment of the risk.</div>
<div><br></div><div>What's interesting to me from this theoretical point of view is that by removing password based auth from a remote agent and moving it to a local agent (IE: moving from remote passwords to local passphrases on a key) you of course multiply the entropy required to authenticate remotely, but simultaneously remove the ability for the remote party to rate limit the 'something you know' transaction. You could steal one of my passphrase encrypted keys and fairly quickly (when compared to a rate limited transaction) crack the key -- recall that it is locally determinate when an SSH key has been properly unlocked, a remote transaction is not required.</div>
<div> </div><div>~Matt Walker<br><div><div>Wikimedia Foundation</div><div>Fundraising Technology Team</div></div></div>
<br>