[conspire] CABAL meeting tomorrow (also, webmail security discussed here)

Rick Moen rick at linuxmafia.com
Fri Sep 11 15:28:07 PDT 2009


Quoting Rich Bodo (richbodo at gmail.com):

> I use a password database (password gorilla)....

Seems like a promising solution, for those who like to get access to
their password stores _on_ general-purpose computing machines.

http://www.fpx.de/fp/Software/Gorilla/

> That's a little cubmersome as I sometimes end up with lots of
> passwords for one account, and sometimes have to make notes as well,
> as to what kind of question it will ask, etc.

Yes, this is the rather annoying part, because PalmOS's
handwriting-recognition software is, in recent version fo PalmOS, much
worse than the original one provided in PalmOS through v. 4.1.1
(Jeff Hawkins's "Graffiti", which was really good).  Xerox sued Palm
Computing over patent violation, and eventually prevailed.  So, what
they ship now is "Graffiti 2" (previously "Jot" from Communication
Intelligence Corporation), which is nowhere near as good and, in my
experience, requires much more manual overcoming of PDA parser errors.

Anyway, I have to type into my PDA not only "Tralfamadore" but also
"Mother's birthplace?" into the text field in Keyring's Bank A record,
which is tedious and annoying work, but at least only a one-time
annoyance.

> Interesting.  I have a different strategy.  I don't think it's the
> height of security, but it allows me to focus on getting only a couple
> things right.  Really, I'm not totally happy with it so this thread
> might inspire some ideas.
> 
> I just make sure my password database always gets used, so I put the
> db on a USB keychain, along with the binaries for linux/win/mac.  That
> way, I can plug into any computer, and access my password database.  I
> also back it and the binaries up to online storage.   My backup
> software (jungledisk) syncs hourly, and grabs it off my usb key or
> elsewhere if  my password db is there and it's updated.  I'll take a
> risk and put copies temporarily onto other computers if I absolutely
> need to.

Actually, if you're willing to assume that Password Gorilla implements
the Twofish symmetric cipher correctly, there's neglible security loss
from putting copies of the db file on other computers -- temporary or
not.  And, of course, lots of benefit from doing so.

Sometimes, when I tell people about my Keyring strategy, people ask me
if I'm not afraid people will steal the (3DES-encrypted) db file from my
backups.  My response is always "Not at all.  I can always use more
safety copies in more locations.  Would you mind if I give you a copy?"

That is, if they can crack a 3DES symmetric cipher within a timespan
worth worrying about (and their initials aren't NSA, and they aren't 
willing to spend a few million dollars of supercomputer time doing it),
then I have a lot bigger problems than a compromised PDA data store.

Anyway, consider this matter from the standpoint of my preferred method
for analyzing all real-world security matters:

1.  Work out all realistic threat models.
2.  Figure out methods to contain/counter/defeat/mitigate those threats.

With my model of Keyring usage, what are the ways for a Bad Guy to get
to my data?  Logically:

1.  Steal either my PDA or a backup db file.  Crack 3DES.  This
    is the brute-force dumb approach, and unlikely.
2.  Rubber-hose decryption.  (Trap me in a blind alley, and say 
    "Type in the Keyring master password, Mr. Moen, or the kneecaps
    get it.")  Effective, but not very stealthy.
3.  Shoulder-surf my master password, then use approach #1 without
    the need to crack the password.  This is the most realistic
    threat, and is why I'm careful about visibility of my 
    data entry when I stylus-enter that password.
4.  Compromise the machine's OS environment where the code runs 
    that reads the password db.  This is why I don't leave 
    Bluetooth or WiFI connectivity on, and am incredibly paranoid
    about what other code I'm willing to install on my PDA.

Threat model #4 is where I win, over people using database-reading
code on general-purpose computing environments -- because I can 
have very high confidence that my PDA's operating environment is 
secure, much higher than I do on any general-purpose computer.

Now, there's a not-strictly-security threat model I also must worry
about.

5.  My PDA dies, or is lost, or is stolen.  Suddenly, I have all kinds
    of backups of the Keyring db, but no device to run Keyring on.
    Suddenly, the only passwords I know are the ones that I have 
    retained in my brain.

One obvious means of recovery is "Go blow $300 on a new PDA", or 
"Get that crummy Palm m100 in the junk drawer going again, and restore
the db onto it."  However, I also have a fallback option:  Several 
suites of management software for PalmOS PDAs, including the open-source
JPilot suite for *ix, include "conduit" extensions that enable them to 
read backups of Keyring databases.

That fallback method would, if I needed to use it, expose my master
Keyring password on the Linux computer in question, so I keep that
access method in reserve and don't use it.  Avoiding using it means I
can be absolutely certain nobody has been capable of stealing my Keyring
passwords -- unless that master criminal has found a way to trick me
into installing Trojan software on my PDA, which ain't likely.



> But my policy just burns down to two things:
> 
> 1) always use an encrypted password database to generate or access passwords
> 2) go through and change my passwords fairly frequently, usually
> coinciding with bouts of paranoia after having opened my db on a
> strange computer.

My alternative eliminates that occasion for paranoia, at its root.  ;->

The price I have to pay is -- as you say -- that I cannot copy passwords
from the password store (via Clipboard) to entry fields on
general-purpose computers.  But, on the other hand, the fact that my
PDA, where the password-access software runs, is a dedicated appliance
and airgapped from general-purpose computers, has other benefits.





More information about the conspire mailing list