[Cryptography] password fatigue; was: Lastpass

Wed Jun 17 14:07:37 EDT 2015

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 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
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150617/466a856d/attachment.sig>