'Re: [Cryptography] password fatigue; was: Lastpass'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] password fatigue; was: Lastpass
From:       Chris Tonkinson <chris () tonkinson ! com>
Date:       2015-06-17 18:07:37
Message-ID: 5581B769.7020900 () tonkinson ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

SQRL[1] seems an early, if promising, mechanism that I would bet on over
FIDO.

No shared secrets, out of band, hard against spoofing, crypto looks like
it was done right, and it's something I could explain to <non technical
relative here>.

[1]: https://www.grc.com/sqrl/sqrl.htm

Chris Tonkinson
http://chris.tonkinson.com/
610.425.7807

  "Lead, follow, or get out of the way."
  -Thomas Paine

On 06/17/2015 01:49 PM, Hubert A. Le Van Gong wrote:
> 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@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@metzdowd.com
> > http://www.metzdowd.com/mailman/listinfo/cryptography
> 
> -- 
> email: hubert@levangong.org
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

[prev in list] [next in list] [prev in thread] [next in thread] 