<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 16, 2015 at 8:11 PM John Denker <<a href="mailto:jsd@av8n.com">jsd@av8n.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/16/2015 04:19 PM, Randy Bush wrote:<br>
<br>
> do not store critical secrets on others' systems. period. then, learn<br>
> how to secure your own system(s); this is seriousy hard.<br>
<br>
There are several ideas there. My comments:<br>
<br>
1) You have to secure your own system FIRST. To say<br>
the same thing the other way: If you enter your<br>
password via a platform that has been pwned, then ....<br>
-- It doesn't matter how good your master pw is.<br>
-- Also it doesn't matter whether or not you use<br>
lastpass or anything like that, and it doesn't<br>
matter whether you consider lastpass to be better<br>
than nothing or worse than nothing.<br>
-- Also it doesn't matter whether you use zero-<br>
knowledge authentication or anything like that.<br></blockquote><div><br></div><div>You lost me at "You have to secure..." This is obviously relevant to the people on this list, but it's not going to fly for the world at large. People like us need to start building secure systems for people to use, where security doesn't rely on being a security expert. (I see from #3 that we seem to agree on this).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Password fatigue is a problem. We need to focus<br>
on this. Lastpass gets "some" brownie points for<br>
attempting to solve the problem, even if you think<br>
their attempt is less than 100% elegant and/or<br>
less than 100% successful.<br></blockquote><div><br></div><div>YES. Passwords are fundamentally broken. We need two factor authentication at the very least. But I think for most of the world, the second factor will need to live in secure storage on their phone, combined with some sort of proof-of-presence. It can still probably be MitMed on the phone itself, but the only real solution to that is to have a reasonably secure mobile OS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3a) Snickering at lastpass does not solve the problem,<br>
not even a little bit.<br></blockquote><div><br></div><div>indeed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3b) Telling users to solve the problem on their own<br>
does not solve the problem.<br></blockquote><div><br></div><div>Ok well obviously we agree on this part. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3c) The only way I can see to solve the password fatigue<br>
problem is to get web services to stop asking for a<br>
per-site password and instead use some sort of zero-<br>
knowledge authentication. Schemes for doing this have<br>
been known for a long time.<br>
<a href="https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol</a></blockquote><div><br></div><div>SRP still starts with a password, and passwords can be phished. An RSA key in an HSM with a PIN would be better than something like SRP. Still zero knowledge between the client and server, but much harder to phish or MITM.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3d) If anybody knows of a better solution, please let<br>
us know.<br></blockquote><div><br></div><div>Not one that doesn't involve a hardware token of some kind. But if you're willing to accept a token, U2F seems pretty close to ideal. (Disclaimer: I started working at Google recently, so I could be considered biased on this. However, nobody has been able to MITM U2F yet.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Yes, securing your system is seriously hard. Of<br>
course that includes securing the subsystem that<br>
handles your zero-knowledge authentication.<br></blockquote><div><br></div><div>That's an advantage of having dedicated hardware to do it. Smaller attack surface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5) This supports my contention that the NSA is not very<br>
good at their job. Note that Information Assurance is<br>
part of their mission, if you believe their own website:<br>
<a href="https://www.nsa.gov/ia/" rel="noreferrer" target="_blank">https://www.nsa.gov/ia/</a><br>
If they had any sense, they would roll out some sort<br>
of zero-knowledge authentication scheme and require<br>
government sites to use it, e.g. when accessing the<br>
security-clearance background info database, just to<br>
pick a random example.<br></blockquote><div><br></div><div>That would be cool. You're right, there's no excuse whatsoever for not issuing everyone involved a hardware token or something. Of course, any time you buy hardware, you're going through the government contracting process, which is probably no-bid/cost-plus. Or they just pick RSA and use tokens that can be easily MITMed.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
6) Similar words apply to google. If they had any sense,<br>
they would embed some sort of zero-knowledge thing into<br>
android and chrome, and use it when connecting to<br>
*.<a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>.<br></blockquote><div><br></div><div>Why do you think Google doesn't do this already?<a href="http://www.itnews.com.au/News/367057,googles-plan-to-kill-the-corporate-network.aspx">http://www.itnews.com.au/News/367057,googles-plan-to-kill-the-corporate-network.aspx</a> and <a href="https://sites.google.com/site/oauthgoog/gnubby">https://sites.google.com/site/oauthgoog/gnubby</a></div><div><br></div><div>Neither of these avoids tunneling passwords over SSL, but the password need only be one layer. But if you're stuck with that, there's stuff like the Password Alert extension, which while it's specific to your Google account, could easily be extended to watch for other important (and non-reused) passwords.</div><div><br></div><div>I do like the idea of having a special field type or dialog that can't be spoofed and does something like SRP, though you'd have to teach users to only type their passwords into that field/dialog, and that's a hard problem if every site doesn't support it.</div></div></div>