> > (if memory serves correctly, it's basically this: the server sends a
> > header/welcome message in it's header message to the client... the client
> > hashes that welcome string with it's password and uses that instead of the
> > clear text password to authenticate... thus, if the header has the
> > clients IP address and the date in it, you're reasonably safe from replay
> > attacks (assuming the client machine is secure, and that's a required
> > assumption anyway)..
>
> Yes, this is pretty much how it works, however I think it would be better
> to use a string that is more random than the header method you've
> suggested. PHPLIB has a function that generates a cryptographically
> random string for use in their challenge-response system.
I think that's pretty much irrelevent... if we're defending against
sniffers, then they get to see the header, making it change faster/better
doesn't make any difference, they don't have to guess it. If they're going
to bruteforce your password out of the response, it doesn't matter what
the starting point is, as long as they know it (and a sniffer will) ...
gibberish versus a text string for a salt doesn't change the problem.
(I seem to recall that there is a MD5 weakness with appending text to the
value being hashed... but I can't find the reference... I think the
suggested fix was to hash the hash...)
> > Why the headache? Because my money is apparently on the line, and
> > without ANY protections from sniffers :-( and probably no chance to
> > decline payment for any domains that are fraudulently registered with my
> > authentication/passwd. (see item 5 of exhibit a in the reseller
> > agreement.)
>
> Yeah. I think we need to have something stronger than MD5 hashes, though.
> When you create a new user, you have to send the password back to the
> server cleartext. I think it might be better to use DES or something
> similar and encrypt the entire connection by using the reseller password
> as the encryption key.
AFAIK, legally, encryption is a _much_ bigger headache than
authentication... there's no ITAR problem with using cryptography for
authentication ... that said, I don't know much about that field... and 40
bit encryption would be "just fine" in comparison to plain text.
I don't know much about the opensrs target environments, nor have I read
through much of the client API ... but an obvious, simple fix for those of
us that are concerned, could be to provide an SSL webserver for creating
userid/passwords ...
-------
hhmm, from http://www.opensrs.org/clientfaq.shtml
2. Will my webserver require SSL in order to register domain names?
The server running the OpenSRS client does not require SSL
support as this will be provided as part of the protocol support as
part of the OpenSRS server.
out of date, wrong, or we missed something in our perusal of the
source code?
----------------------------------------------------------------------
tbrown@BareMetal.com | Don't go around saying the world owes you a living;
http://BareMetal.com/ | the world owes you nothing; it was here first.
web hosting since '95 | - Mark Twain
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:38:00 EDT