On Thu Aug 21 04:35:16 2008, Justin Karneges wrote:
On Wednesday 20 August 2008 03:10:54 Dirk Meyer wrote:
> Maybe it is a stupid idea, but why not use the md5 sum of the key
> password as server password? Replace md5 with sha256 to be more
> up-to-date.
Yes, that's sort of what I was thinking.
IIRC, MD5 would be okay there, although it'd raise some eyebrows. You
need a preimage attack to get the private key, and (from what I know)
MD5 and SHA have the same levels of preimage weakness found thus far.
Still, might as well use SHA-512 or something - although someone
determined could still simply brute force a password in a week or two
by hiring a botnet.
It would probably work for fresh
accounts. Unfortunately for users who already have an account, it
would be a
risk to use the same password for their private key. They'd have
to pick a
new password to bootstrap the system securely.
Right.
Another issue is that the
client would need to know in advance that it should send a hashed
password to
login to the server. Accidentally sending the plain one could
result in a
private key compromise. We can't rely on a server feature to tell
us which
way to authenticate either, since it is the server we're not
trusting! :) We
also can't rely on the user always using a proper client. The
moment they
play with some cool new Jabber client that only supports PLAIN,
there they go
sending their private key password to the server (or worse, over an
unencrypted link, where *anyone* could get it).
No, it's far worse than that. Most SASL implementations store
passwords in the clear, especially if they support multiple
authentication mechanisms.
So merely using DIGEST-MD5 doesn't mean the server doesn't know your
real password anyway.
But Remko's right, if we require two passwords (one for Jabber, one
for a
private key) then a lot of people will just make them the same,
completely
defeating the point. I think we'll have this problem whether or
not the
private keys are stored on the server or locally.
Oh, I think most people will (and possibly even should) keep the
private key without any specific password. What'll happen in a
pragmatic-but-reasonable world is that the key will be in the
operating system's "secure store", just like their password often is
today.
If they have to put a password on it, it'll be the same password they
use everywhere, of course.
Quite honestly, I think any attempt to provide key storage on servers
is just doomed - no doubt the odd client will do it (via private XML,
or PEP/POP/PIP), but I don't think we should be encouraging it.
Key exchange between clients, however, is much simpler - we can
perform a simple client-to-client authentication, securely bound to a
peer-to-peer encrypted channel - as we would do for key verification
- but this time use it to authenticate that you own both clients
(devices, etc).
This should allow the expensive RSA keys to be copied securely from,
say, desktop to mobile phone, or even between different clients on
the same machine, reducing the likelyhood of lost keys.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
