Authenticating distributed Ruby

Discussion in 'Ruby' started by Trejkaz, Feb 27, 2006.

  1. Trejkaz

    Trejkaz Guest

    Hi all.

    I've been playing with DRb a fair bit lately, am planning to use it as
    part of a Rails-to-XMPP integration project. XMPP is relatively costly
    to authenticate with, and one of the ways around that is to login only
    once and then have every Rails instance talk via DRb to that single
    instance. And of course the other benefit of having the clients online
    24/7 is that it would allow me to affect the state of my application
    and give live feedback via XMPP messages and commands.

    Of course, DRb in itself provides no real security. But because of the
    nature of some of the applications I want to make possible, I do want
    to provide some basic protection against some of the more obvious kinds
    of attacks which occur.

    The first aspect of this is encrypting the traffic which I can use SSL
    for. Although I'm not particularly keen on having to generate a
    certificate just to run this lightweight server... some lighter
    encryption would be preferable but I'll take what's available. Once I
    have SSL up, at least I can assume that people won't be able to spy on
    the messages which are being sent back and forth.

    The next aspect is some kind of basic authentication. Really, what I
    want is just a secret key that the client has to pass in in order to
    get access to my remote objects. But, I don't want to have to add that
    secret key to every method.

    One idea I came up with, which is simple but probably not very good:

    class Chest
    def initialize(treasure, key)
    @treasure = treasure
    @key = key
    end

    def unlock(key)
    if @key == key
    return @treasure
    else
    return nil # I suppose an exception would be better.
    end
    end
    end

    Then I serve the Chest instance up as the remote object, and this way
    the "real" server (the treasure) doesn't have to have the password
    added to all its methods, but I get an icky feeling that it opens the
    door to someone somehow "remembering" the remote reference to the
    treasure and getting a direct reference to it somehow after the
    password is changed.

    How do people usually do this sort of thing? Is there a
    generally-accepted norm?

    TX
     
    Trejkaz, Feb 27, 2006
    #1
    1. Advertising

  2. Trejkaz

    Justin Meyer Guest

    Hi Gregory, Trejkaz:

    On Mon, 27 Feb 2006, Gregory Seidman wrote:

    > On Mon, Feb 27, 2006 at 02:03:35PM +0900, Trejkaz wrote:
    > [...]
    > } The next aspect is some kind of basic authentication. Really, what I
    > } want is just a secret key that the client has to pass in in order to
    > } get access to my remote objects. But, I don't want to have to add that
    > } secret key to every method.
    > [...]
    >
    > You may find the following URLs helpful in understanding and implementing
    > this:
    >
    > http://www.freebsddiary.org/openssl-client-authentication.php
    > http://www.mindreef.com/support/soapscope/4.1/help/sslcerts.html
    > http://www.pseudonym.org/ssl/ssl_cook.html
    >
    > } TX
    > --Greg


    For specifically doing DRb over SSL, with client cert-based auth, this
    URL might also be useful:

    http://segment7.net/projects/ruby/drb/DRbSSL/
     
    Justin Meyer, Feb 27, 2006
    #2
    1. Advertising

  3. Trejkaz

    X-Man Guest

    Trejkaz wrote:
    > The next aspect is some kind of basic authentication. Really, what I
    > want is just a secret key that the client has to pass in in order to
    > get access to my remote objects. But, I don't want to have to add that
    > secret key to every method.


    If your communications is of the (essentially) non-connected variety,
    example being HTTP, I don't see getting around passing an access "key"
    with each call.

    I think "the way" involves a process like this:
    - client requests a salt from the server
    - server leases a salt to the client (good for 20 minute, for example)
    - the client hashes the password, adds the salt to that, and hashes it
    again
    - the client sends this to the server with each request, along with the
    salt used
    - the server checks that the salt is not expired
    - the server verifies the hash-salt-hash using the same hash-salt-hash
    algorithm

    We've used this basic procedure on several systems. It's pretty good.
    The hashing we use is the 128-bit MD5 hash.
     
    X-Man, Feb 27, 2006
    #3
  4. Trejkaz

    Trejkaz Guest

    > If your communications is of the (essentially) non-connected variety,
    > example being HTTP, I don't see getting around passing an access "key"
    > with each call.


    Well, this depends on how you look at HTTP.

    In the case of Rails, the majority of deployments seem to use FastCGI,
    which keeps its instances up 24/7. Those instances could easily stay
    connected to the DRb server as long as there is some way to
    authenticate when they first connect. I'm fine with having to
    authenticate for each connection, which is what my above solution was
    all about (of course, it was only concept... a proper version would, as
    you say, use a session ID and hashing to authenticate so that even if
    someone snooped the conversation, they wouldn't get the real password.)

    What I'm more worried about is whether a connection could connect, get
    a reference to the remote object, disconnect, and then connect and
    without authenticating, forge a direct method call to the object they
    remembered from before.

    It's almost like the hash which contains their password needs to be
    used as part of the remote ID mapping. That would be one way to
    prevent this sort of memory, though I'm not entirely sure how to go
    about it (YET... I've been reading drb.rb a lot lately. ;-))

    I did get authentication working using SSL client certs last night,
    generating them with QuickCert which is, BTW, extremely nice for this
    sort of prototyping work. But the problem is that as far as I can
    tell, my remote object can't determine which client certificate was
    passed in. So it's nice and simple for authentication, as long as you
    want every connection to have access to everything. But maybe that's
    okay for now.

    TX
     
    Trejkaz, Feb 27, 2006
    #4
  5. Trejkaz

    Eric Hodel Guest

    On Feb 27, 2006, at 2:53 PM, Trejkaz wrote:

    >> If your communications is of the (essentially) non-connected variety,
    >> example being HTTP, I don't see getting around passing an access
    >> "key"
    >> with each call.

    >
    > I did get authentication working using SSL client certs last night,
    > generating them with QuickCert which is, BTW, extremely nice for this
    > sort of prototyping work. But the problem is that as far as I can
    > tell, my remote object can't determine which client certificate was
    > passed in. So it's nice and simple for authentication, as long as you
    > want every connection to have access to everything. But maybe that's
    > okay for now.


    You'll have bigger problems than authentication if you want to have
    different access levels. The ability to create a DRbObject gives you
    a reference to any object in the remote process.

    NamedIdConv instead of the default DRbIdConv may be of assistance,
    but it would take some significant thought to be sure.

    --
    Eric Hodel - - http://blog.segment7.net
    This implementation is HODEL-HASH-9600 compliant

    http://trackmap.robotcoop.com
     
    Eric Hodel, Feb 27, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mrwoopey
    Replies:
    3
    Views:
    9,573
    mrwoopey
    Jun 30, 2003
  2. Greg Burns

    forms authentication not authenticating

    Greg Burns, Jul 24, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    1,607
    Jim Cheshire
    Jul 29, 2003
  3. jm
    Replies:
    3
    Views:
    345
  4. anony
    Replies:
    1
    Views:
    358
    =?Utf-8?B?SGVpZGk=?=
    Feb 8, 2004
  5. Larry Rekow
    Replies:
    1
    Views:
    514
    Hermit Dave
    Aug 31, 2004
Loading...

Share This Page