[Cryptography] password fatigue; was: Lastpass

Wed Jun 17 13:49:21 EDT 2015

Could not agree more with you on passwords' brokenness.
My (current) bet is on FIDO (https://fidoalliance.org/) which, in its
UAF form, provides 2 factor-based authN. The mobile approach you
described being one of its primary use case.

Hubert

On 17/06/2015 09:31, Sean Lynch wrote:
> On Tue, Jun 16, 2015 at 8:11 PM John Denker <jsd at av8n.com> wrote:
> 
>> On 06/16/2015 04:19 PM, Randy Bush wrote:
>> 
>>> do not store critical secrets on others' systems. period. then,
>> learn
>>> how to secure your own system(s); this is seriousy hard.
>> 
>> There are several ideas there. My comments:
>> 
>> 1) You have to secure your own system FIRST. To say
>> the same thing the other way: If you enter your
>> password via a platform that has been pwned, then ....
>> -- It doesn't matter how good your master pw is.
>> -- Also it doesn't matter whether or not you use
>> lastpass or anything like that, and it doesn't
>> matter whether you consider lastpass to be better
>> than nothing or worse than nothing.
>> -- Also it doesn't matter whether you use zero-
>> knowledge authentication or anything like that.
> 
> 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).
> 
>> 2) Password fatigue is a problem. We need to focus
>> on this. Lastpass gets "some" brownie points for
>> attempting to solve the problem, even if you think
>> their attempt is less than 100% elegant and/or
>> less than 100% successful.
> 
> 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.
> 
>> 3a) Snickering at lastpass does not solve the problem,
>> not even a little bit.
> 
> indeed.
> 
>> 3b) Telling users to solve the problem on their own
>> does not solve the problem.
> 
> Ok well obviously we agree on this part.
> 
>> 3c) The only way I can see to solve the password fatigue
>> problem is to get web services to stop asking for a
>> per-site password and instead use some sort of zero-
>> knowledge authentication. Schemes for doing this have
>> been known for a long time.
>> https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
>> [1]
> 
> 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.
> 
>> 3d) If anybody knows of a better solution, please let
>> us know.
> 
> 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.)
> 
>> 4) Yes, securing your system is seriously hard. Of
>> course that includes securing the subsystem that
>> handles your zero-knowledge authentication.
> 
> That's an advantage of having dedicated hardware to do it. Smaller
> attack surface.
> 
>> 5) This supports my contention that the NSA is not very
>> good at their job. Note that Information Assurance is
>> part of their mission, if you believe their own website:
>> https://www.nsa.gov/ia/ [2]
>> If they had any sense, they would roll out some sort
>> of zero-knowledge authentication scheme and require
>> government sites to use it, e.g. when accessing the
>> security-clearance background info database, just to
>> pick a random example.
> 
> 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.
> 
>> 6) Similar words apply to google. If they had any sense,
>> they would embed some sort of zero-knowledge thing into
>> android and chrome, and use it when connecting to
>> *.google.com [3].
> 
> Why do you think Google doesn't do this
> already?http://www.itnews.com.au/News/367057,googles-plan-to-kill-the-corporate-network.aspx
> [4] and https://sites.google.com/site/oauthgoog/gnubby [5]
> 
> 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.
> 
> 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.
> 
> Links:
> ------
> [1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
> [2] https://www.nsa.gov/ia/
> [3] http://google.com
> [4]
> http://www.itnews.com.au/News/367057,googles-plan-to-kill-the-corporate-network.aspx
> [5] https://sites.google.com/site/oauthgoog/gnubby
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-- 
email: hubert at levangong.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150617/67b76a9b/attachment.html>