Re: [coldsync-hackers] m500: cannot coldsync

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Sat, Sep 22, 2001 at 05:08:59PM -0700, David A. Desrosiers wrote:
> 	Ideally, you should create the storage hash as a combination of two
> pieces of data, their supplied password, and some other verifyable piece of
> data (UserID is a logical one).

	As is the serial number, on those machines that have it.

> When the user sets up ColdSync for the first
> time (some sort of ./configure wizard needed?) they can be prompted to sync
> their Palm, which can get the UserID from it, and if a password is set,
> prompt them for the password. md5 these two, store in the .rc file.

	Let's see if I got this straight:

	In the normal course of events, you stick your Palm into the
cradle and hit the HotSync button. The Palm sends a wakeup packet to
the desktop, then sends it a packet containing the md5 hash of the
password stored in "Saved Preferences.prc". The desktop is then
supposed to verify this password, and proceed to sync if it's okay.

	What you're suggesting is the following: before ever syncing,
the user runs a setup utility, gives it his name ("John Smith"), his
Palm userID (12345), and his Palm password ("abcdef").
	This utility then computes
	md5("John Smith" . "12345" . md5("abcdef"))
(where "." means concatenation) and stores the result to ~/.palm-password .
	Then, when you sync, the sync application (be it pilot-xfer,
ColdSync, or whatever) receives the md5 hash of the password, as
above, as well as the username and userid. It then computes
	md5(username_from_palm . userid_from_palm . passwd_from_palm)
and compares this to the contents of ~/.palm-password . The two will
match only if the username, userID, and password (and whatever other
data you want to throw in) match.

	Is this more or less correct? If so, then this means that
neither the password, nor the md5 hash of the password, are stored in
readable form on the desktop. But if it never needs to be sent to the
Palm, that's okay.

> > 	Of course, inevitably someone's dumbass sysadmin will chmod
> > 775 /, which means that /homes/, /homes/arensb/, /homes/arensb/.palm/,
> > and /homes/arensb/.palm/password can be replaced.
> 
> 	Which is exactly why the combination hash is the best approach. You
> don't get the password, or the usable hash of the password, you get a hybrid
> hash. I've said that a third piece of information, the LastSyncTime should
> be used here also, to make sure that the hash in the local .rc file changes
> at every sync, and if someone gets the .rc file, they will not be able to
> tell what the password was.

	The username is generally known. Depending on the utilities
being used, the user ID might be known or easily guessable (better to
choose one randomly). The modification times on the desktop's PDB
files give you a pretty good idea of the last modification time. And a
lot of people are going to have easily-guessed passwords. So now you
start crunching numbers.

> > It'll be necessary to override the protection check in cases like
> > these. Of course, if an attacker can replace ~/.palm/password, he can
> > also replace the config file and tell it to ignore the insecure
> > permissions, so the Right Thing would appear to be to make this option
> > settable only from the command line.
> 
> 	The triple hash idea solves this. Although, if you've been locally
> compromised, your .pdb files are in the clear too.

	Yeah, and I'd rather keep it this way (though now that I think
of it, it should be fairly easy to write a pair of conduits that
decrypt and encrypt your databases, which narrows the time during
which they can be stolen. Personally, though, I'm not that paranoid).

	I've also wondered whether it might be possible to add a
library hook in PalmOS such that each record is individually encrypted
before being sent to the desktop. Done properly, this could preserve
the PDB structure but hide the contents. Just a thought.

> If we control both desktop and client components (conduits),

	I don't control the conduits. ColdSync allows external
programs to make system calls on the Palm, which can allow them to
read the unencrypted password directly.
	On the plus side, it doesn't read any pathnames from the Palm.
That is, given a secure workstation, you can't set up a Palm to make
ColdSync execute /tmp/crackstuff. Plus, the sysadmin can restrict
which conduits can be executed.
	Compare this to sendmail: a user can run all sorts of nasty
programs from his .forward , and sendmail will let him (if it hasn't
been set up to use smrsh). But sendmail doesn't read pathnames out of
the message[1], so the weakest link becomes ~/.forward , not sendmail
itself.
	This is as it should be. Personally, I fully support people's
right to shoot themselves in the foot if they're determined to do so.

[1] Well, it used to. But I haven't seen it do that for years, now.

> 	We have to be careful of a few things though:
> 
> 	1. Bypassing the existing encryption

	...where "encryption" is defined to include rot13.

> 	2. Making it hard for a user to retrieve data if they "forgot" their
> 	   password.

	You mean, beyond a sympathetic "Gosh, it sucks to be you"?

> 	3. Hardening this to the point where Palm takes our ideas and
> 	   implements them at the OS level.

	If you live in the U.S. and have a pile of cash, you should be
able to patent your implementation, no matter how ridiculous.

> 	We have to do at least what they do, on our implementation, and
> perhaps extend it a bit, but not make it overly complex or impossible to
> use.

	Yeah, that's one of the classic tradeoffs. Please, do share
what you do with this. If pilot-link and ColdSync used similar
schemes, it might make it easier for people to switch back and forth.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
			Above all else -- sky.
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.