[sf-lug] Heartbleed TLS/SSL bug and also password managers

Rick Moen rick at linuxmafia.com
Thu Apr 10 17:28:51 PDT 2014


Quoting Michael Shiloh (michaelshiloh1010 at gmail.com):

> yes, rick, i'd love to hear your point of view.

Buy low, sell high.  Oh, wait, about password strategies?  Sure, glad
to.  Thanks for asking, seriously.

Buy low, sell high.  Oh, wait, about password strategies?

> i'm in the market for a password manager that works on both linux and
> android.

As is often the case in troubleshooting, the best place to start is to
first consider what problem you're trying to solve (and whether it's the
right problem).  In the case of a security problem, we often ask
(specifically) the related question 'What is the threat model?'

'To summarise the summary of the summary, people are a problem.' --
Douglas Adams, _The Restaurant at the End of the Universe_.  In
particular, humans' wetware is poorly engineered to remember complex
passwords well, especially many of them at once.  Bioengineering being
insufficiently far advanced, we aspire to lean on our silicon friends.

Forgetting passwords causes loss and downtime.  That is a threat model
of sorts (DoSing yourself).

Using ridiculously simple passwords (so you can remember them)
facilitates dictionary attacks, a second threat model.

Using the same moderately complex passwords in multiple scenarios
(because you can only remember a few) creates the risk that compromise
of credentials in one place will let intruders trivially masquerade as
you in other places they have figured out you likely use, a third threat
model.

Using a bunch of complex passwords that you write on PostIts addresses
pretty much all of those threats, while creating a limited exposure to
the threat of someone visiting your desk and writing them down, a fourth
threat model.  (Don't laugh at the PostIt person, though.  His or her
desk may be pretty difficult to break into, and, if he/she doesn't write
unambiguously on each PostIt what it's the password _for_, that may not
be much of a risk.)

So, some clever person thinks:  'I know!  I'll write a "password safe"
application that runs on my {workstation|smartphone}.'  So, the user
need remember only _one_ complex password, the one that unlocks all the
others.  Great, eh?

Anyone spot the problem?  Anyone?  Anyone?  Bueller?

Hint:  Has an workstation or smartphone ever suffered a security
problem?

Your homework:  Detail the threat model.



> yes, rick, i'd love to hear your point of view.

My personal electronics includes a laughably antique Palm TX PDA.  Yes,
a PDA!  In 2014!

Gosh, what's wrong with a PDA?  Well, it's detached from the Internet.
Because I'm utterly paranoid about what I am and am not willing to
install on it, it has only extremely simple, well-known software.

In security terms, the term for that first wrong thing is 'airgapped'.
In security terms, the term for that second wrong thing is 'very small
and very hard attack surface.'

My calling those somethings 'wrong' with my PDA is 98% sarcasm:  In the
security context, both are highly advantageous.

My PDA's very small collection of software includes an open-source
PalmOS application called Keyring.  http://gnukeyring.sourceforge.net/
Keyring is an _offline_ store for security data including but not
limited to passwords.

I back up its 3DES-encrypted datastore to my workstation.  I'd be glad
to give you a copy of my key database.  In security terms, that is
called 'making backups'.  ;->

No, I cannot copy/paste passwords onto my workstation.  Yes, that means
I must type them.  Yes, I do make sure people are not shoulder-surfing
my Palm TX's screen when I have Keyring open.  Yes, Keyring does timeout
any open display.

If I give up on PalmOS devices, yes, I'll have to find something else --
but I'm reluctant to have that be anything on a workstation or
smartphone, because of that thing you're going to detail in your
homework assignment.

Disclaimer:  Your Mileage May Differ.[tm]  And people's degree of
paranoia needs to be crafted to suit their indvidual needs.





More information about the sf-lug mailing list