[conspire] Simplicity and security (was: Password managers and such)

[Rick Moen]

This is (obviously) going to be an afterthought to my password-safe
applications post.

Security expert Bruce Schneier has a saying he's famous for:  'Security
is a process, not a product.'  Part of what he's getting at is that
improving security by layering on more _stuff_, e.g., buying more
appliances and/or programs, is an unpromising approach and usually takes
you backwards rather than ahead.

> PalmOS is so simple and dumb, especially if you don't use its
> Bluetooth or wireless networking, that it's extremely challenging to
> attack.

This is a specific instance of a more-general truth:  Simplicity tends
to help security.  Sometimes, that help comes in the form of a reduced
attack surface and/or greater modularity; sometimes in the form of much
greater ease of understanding the details and the big picture; sometimes
both.

Baroque complexity in technological systems (hardware and software) 
makes them difficult to fundamentally understand, and also provides
greater opportunities for attackers to induce mischief, and for bugs to
shoot you in the foot.

So:  Be very skeptical when someone recommends you fix a complex
security problem _not_ by better understanding and greater simplicity
but rather by layering on yet another program (especially a proprietary
one that implicitly requires you to trust some new and additional bunch
of strangers with your key personal interests and data).  Consider the
possibility that maybe learning and maybe paring down complexity _might_ 
be more fruitful.

In particular, it's _very_ common for proprietary software alternatives
to either start out overfeatured or become so over time, because in the
target markets value is commonly assessed by comparing number of
tickmarks on a feature list, with the assumption that more = better --
but, in security-sensitive places (in reality), more = worse.  By
contrast, most open source codebases try to do a very limited set of
features well.  Compare, e.g., PDF reader programs:  Adobe Acrobat Reader 
(abysmal security history, proprietary) vs. muPDF (excellent history,
open source).


In this use-case, studying the problem carefully does confirm that
password-safe programs _do_ address an intractible real problem, the
human-memory one.  Tricks to limp by using only unaided brain cells
really don't work well (unless you're three-sigma excellent in memory
function), and many have been attempted.  So, you need a place external
to your head to hold security-sensitive information, for your use.  The
only question is where.

I personally think (as I said) that running password-safe programs on 
devices that are (1) Internet-facing and (2) of dodgy security anyway
(e.g., desktop OSes generally, and very definitely all smartphones) 
is a wretched idea, whose only redeeming feature is being better than
relying on human memory alone.

The alternative is some sort of strong-crypto-based password-safe device
living normally in your pocket -- something more modern than a 1990s
PalmPilot.  There has been a modest cottage industry in designing these
-- but you're advised to read skeptically:

o  Sometimes, one looks good, but then you find the 'strong crypto' 
   requirement isn't met.  

https://www.amazon.com/John-N-Hansen-595-Password/dp/B00FDZVBYG
https://www.amazon.com/Logio-Secure-Password-Organizer-Lanyard/dp/B001MS79YE
https://www.hammacher.com/product/offline-password-vault

o  Sometimes (rarely), you see what looks like a promising airgapped
   and strong-crypto password store appliance, but you see some other
   odd problems, like passwordsFast:
   https://www.amazon.com/passwordsFAST-Stand-Electronic-Password-Keeper/
   https://www.passwordsfast.com/

AES-256 symmetric crypto for storing passwords, strictly local
('standalone') ability to enter and display passwords is obviously good.
OTOH, unreliable key action, bad.  Total inability to back up the device
in any way, very bad.  Limit of 125 records, WTF?  Why not thousands?
Sheesh.  It's not like flash storage is expensive.  

So close, but so far.  All they had to do was spend another $20/unit to
prevent it from sucking.  {sigh}  But maybe the Mooltipass.  (Yes, that 
is indeed a Fifth Element / Luc Besson reference.  Clever of you to notice.)

There may be a good one.  I've not yet run across it.  (What would be a
good design & feature set is obviously debatable, a matter I'll return
to, below.)

o  Something different but similar (and usually with overlapping
   functionality is the category of two-factor[1] authentication (2FA) token,
   such as FST-01, U2F Zero, Nitrokey, YubiKey, and  Mooltipass.[2]  See:
   https://anarc.at/blog/2017-10-26-comparison-cryptographic-keycards/
   https://www.themooltipass.com/
   http://www.hackmod.de/Mooltipass-Passwort-Manager
   http://nistur.com/mooltipass/

I'm not saying those are bad.  They're worth looking at -- but, again,
the key thing is to _understand_ the big picture and see their role
in security in context.  If you don't yet, then that's the first problem
to solve.


Which gets us back the question I keep pondering:  What features should
such a pocket gadget include?  The market seems to overwhelmingly want
a device that can entire security tokens directly to software on your
computer, either by emulating a USB keyboard, talking to a Web-browser
plugin, or sending input data over Bluetooth.  For me, the more limited
the pocket device's communication with Internet-facing & similar
computers, the better -- so that security compromise of the computer
cannot seize contents of the pocket device.  IMO, it should be possible
to fully use the pocket device while doing only the bare minimal 
communication with any computer necessary to back it up or restore it.
Like, that might involve the pocket device using a microSD chip for
storage that can be optionally removed to back up / restore its
encrypted files.  Implicitly, this means the pocket device must include
its own display screen and input method.

The Mooltipass appears to be able to do that, if barely, if I'm
understanding correctly references to its 'touch interface' usable 
for local-only input.  (The newer and smaller Mooltipas Mini has
more-limited input abilities.)  The device is _intended_ to type
credentials for the user via USB, but appears to be able to do
standalone-only operations, too, if awkwardly.  (But if you want it to
be an attached two-factor authentication device, it's designed
specifically for that.)


[1] To use the field's jargon, authentication can involve one or more of
these three classes of factors:  a thing you know (e.g., a password), a 
thing you are (biometrics), a thing you have (e.g., a security dongle 
such as an RSA SecureID gadget producing pseudorandom one-time tokens 
or one of the token examples listed.

[2] 'Passwords are bad, so everyone should use $THING instead' is a
separate discussion.  In the world as it is, we must manage passwords
irrespective of what the world ought to prefer.