Linux Authentication Architecture Question: - Security

This is a discussion on Linux Authentication Architecture Question: - Security ; Howdy, I am writing a UDP server daemon in perl, and I would like to back-end its authentication into whatever the Linux box happens to be using for user authentication at the moment. In consideration of PAM, LDAP, and the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Linux Authentication Architecture Question:

  1. Linux Authentication Architecture Question:

    Howdy,

    I am writing a UDP server daemon in perl, and I would like to back-end
    its authentication into whatever the Linux box happens to be using for
    user authentication at the moment.

    In consideration of PAM, LDAP, and the legacy password authentication
    system, what is the most forward compatible, and installation tolerant
    way of doing this? I want to be able to distribute the daemon and
    have it compile and work with various distros without a myriad of
    grabastic dependencies.

    The data is not sensitive to snooping, but it does need to be
    authenticated. So CHAP over UDP should be sufficient. Is there a way
    to pipe to "login" on the backend or something?

    Thanks in advance!





  2. Re: Linux Authentication Architecture Question:

    shrike@cyberspace.org wrote:
    > Howdy,
    >
    > I am writing a UDP server daemon in perl, and I would like to back-end
    > its authentication into whatever the Linux box happens to be using for
    > user authentication at the moment.


    *WHY*? There are so many already existing, why can't you simply use the
    existing LDAP or similar infrastructures?

    > In consideration of PAM, LDAP, and the legacy password authentication
    > system, what is the most forward compatible, and installation tolerant
    > way of doing this? I want to be able to distribute the daemon and
    > have it compile and work with various distros without a myriad of
    > grabastic dependencies.


    Depends on what you want. PAM isn't a protocol, it's a manager for other
    protocols. LDAP is extremely powerful, but too powerful and too potentially
    mis-configurable or many setups.


    > The data is not sensitive to snooping, but it does need to be
    > authenticated. So CHAP over UDP should be sufficient. Is there a way
    > to pipe to "login" on the backend or something?
    >
    > Thanks in advance!


    If all you need is authentication, why not simply use Kerberos? Are you
    married to the use of UDP in this project?

  3. Re: Linux Authentication Architecture Question:

    In article <21bc80f1-87ea-4a90-a27c-a6c646c81895@d1g2000hsg.googlegroups.com>,
    "shrike@cyberspace.org" writes:
    >Howdy,
    >
    >I am writing a UDP server daemon in perl, and I would like to back-end
    >its authentication into whatever the Linux box happens to be using for
    >user authentication at the moment.
    >
    >In consideration of PAM, LDAP, and the legacy password authentication
    >system, what is the most forward compatible, and installation tolerant
    >way of doing this? I want to be able to distribute the daemon and
    >have it compile and work with various distros without a myriad of
    >grabastic dependencies.
    >
    >The data is not sensitive to snooping, but it does need to be
    >authenticated. So CHAP over UDP should be sufficient. Is there a way
    >to pipe to "login" on the backend or something?


    That sounds like either a lot of work or bad security.

    If you don't want to send the password in the clear, you have
    to have some sort of encryption which probably requires something
    like a connection.

    Why do you want to use UDP? Why not ssh or ssl/web?


    --
    These are my opinions, not necessarily my employer's. I hate spam.


  4. Re: Linux Authentication Architecture Question:

    On 15.09.2008, Nico Kadel-Garcia wrote:
    >> The data is not sensitive to snooping, but it does need to be
    >> authenticated. So CHAP over UDP should be sufficient. Is there a way
    >> to pipe to "login" on the backend or something?
    >>
    >> Thanks in advance!

    >
    > If all you need is authentication, why not simply use Kerberos?


    Maybe because Kerberos is the only protocol having in Linux just one
    kosher implementation, which is buggy from time to time and has way, way
    to complicated API?

    > Are you
    > married to the use of UDP in this project?


    --
    Secunia non olet.
    Stanislaw Klekot

  5. Re: Linux Authentication Architecture Question:

    Hal Murray wrote:
    > In article <21bc80f1-87ea-4a90-a27c-a6c646c81895@d1g2000hsg.googlegroups.com>,
    > "shrike@cyberspace.org" writes:
    >> Howdy,
    >>
    >> I am writing a UDP server daemon in perl, and I would like to back-end
    >> its authentication into whatever the Linux box happens to be using for
    >> user authentication at the moment.
    >>
    >> In consideration of PAM, LDAP, and the legacy password authentication
    >> system, what is the most forward compatible, and installation tolerant
    >> way of doing this? I want to be able to distribute the daemon and
    >> have it compile and work with various distros without a myriad of
    >> grabastic dependencies.
    >>
    >> The data is not sensitive to snooping, but it does need to be
    >> authenticated. So CHAP over UDP should be sufficient. Is there a way
    >> to pipe to "login" on the backend or something?

    >
    > That sounds like either a lot of work or bad security.
    >
    > If you don't want to send the password in the clear, you have
    > to have some sort of encryption which probably requires something
    > like a connection.
    >
    > Why do you want to use UDP? Why not ssh or ssl/web?


    I think folks are missing the OP's question.

    He's writing a service. It doesn't matter what kind.
    He wants to authenticate access to it.

    With no additional work or extra configuration required for his custom
    service, he wants to use whatever the server OS uses for interactive
    sessions. If it uses /etc/passwd, his service would use /etc/passwd.
    If it uses LDAP or NIS or whatever, his service would plug into the
    authentication architecture the same way that interactive logins do,
    transparently, no extra config required at installation.

    I suspect it's a matter of configuring pam correctly by writing a pam
    module for the service, sticking a reference to it in a custom config
    file, and dropping the config file into /etc/pam.d when you install the
    service. That's a guess on my part. I haven't had a reason to drink of
    the pam nectar deeply yet. I just poke at it from time to time for
    stuff other people write.

  6. Re: Linux Authentication Architecture Question:

    Stachu 'Dozzie' K. wrote:
    > On 15.09.2008, Nico Kadel-Garcia wrote:
    >>> The data is not sensitive to snooping, but it does need to be
    >>> authenticated. So CHAP over UDP should be sufficient. Is there a way
    >>> to pipe to "login" on the backend or something?
    >>>
    >>> Thanks in advance!

    >> If all you need is authentication, why not simply use Kerberos?

    >
    > Maybe because Kerberos is the only protocol having in Linux just one
    > kosher implementation, which is buggy from time to time and has way, way
    > to complicated API?
    >
    >> Are you
    >> married to the use of UDP in this project?

    >


    It's gotten pretty stable, and many if not most LDAP setups run on top of it
    for authentication handling. And the utilities and libraries to use it have
    gotten pretty integral to contemporary versions of Linux, so little new
    implementation work is needed.

  7. Re: Linux Authentication Architecture Question:

    On Sep 15, 3:25*pm, Nico Kadel-Garcia wrote:
    > shr...@cyberspace.org wrote:
    > > Howdy,

    >
    > > I am writing a UDP server daemon in perl, and I would like to back-end
    > > its authentication into whatever the Linux box happens to be using for
    > > user authentication at the moment.

    >
    > *WHY*? There are so many already existing, why can't you simply use the
    > existing LDAP or similar infrastructures?


    The data transmitted isn't security sensitive, only the authentication
    process is. From that standpoint, all I want to do is pass credentials
    and let the OS handle the rest. CHAP is fine for that IMHO since it's
    dirt simple and reliable. Writing a CHAP implementation over UDP will
    pay dividends in not having to support LDAP, Kerberos, etc. etc. If I
    use whatever AAA system the user already has, my phone bill stays low
    because I don't have to support other peoples AAA software.

    >
    > > In consideration of PAM, LDAP, and the legacy password authentication
    > > system, what is the most forward compatible, and installation tolerant
    > > way of doing this? *I want to be able to distribute the daemon and
    > > have it compile and work with various distros without a myriad of
    > > grabastic dependencies.

    >
    > Depends on what you want. PAM isn't a protocol, it's a manager for other
    > protocols. LDAP is extremely powerful, but too powerful and too potentially
    > mis-configurable or many setups.
    >


    PAM is still not that broadly distributed. At least the last time I
    checked, Slackware didn't have it, and recompiling the dependent
    libraries to get it is not for the faint of heart. I want a
    monolithic daemon, that installs and uses whatever AAA system is
    there. I will leave supporting AAA to the people who are good at
    it.

    > > The data is not sensitive to snooping, but it does need to be
    > > authenticated. So CHAP over UDP should be sufficient. *Is there a way
    > > to pipe to "login" on the backend or something?

    >
    > > Thanks in advance!

    >
    > If all you need is authentication, why not simply use Kerberos? Are you
    > married to the use of UDP in this project?


    Yes. I am actually tunneling within a UDP based session layer
    protocol. So UDP comes with the territory.

    Thanks in advance!


  8. Re: Linux Authentication Architecture Question:

    On Sep 15, 6:31*pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
    Murray) wrote:
    > In article <21bc80f1-87ea-4a90-a27c-a6c646c81...@d1g2000hsg.googlegroups.com>,
    >
    >
    >
    > *"shr...@cyberspace.org" writes:
    > >Howdy,

    >
    > >I am writing a UDP server daemon in perl, and I would like to back-end
    > >its authentication into whatever the Linux box happens to be using for
    > >user authentication at the moment.

    >
    > >In consideration of PAM, LDAP, and the legacy password authentication
    > >system, what is the most forward compatible, and installation tolerant
    > >way of doing this? *I want to be able to distribute the daemon and
    > >have it compile and work with various distros without a myriad of
    > >grabastic dependencies.

    >
    > >The data is not sensitive to snooping, but it does need to be
    > >authenticated. So CHAP over UDP should be sufficient. *Is there a way
    > >to pipe to "login" on the backend or something?

    >
    > That sounds like either a lot of work or bad security.
    >
    > If you don't want to send the password in the clear, you have
    > to have some sort of encryption which probably requires something
    > like a connection.
    >


    That is partially correct. CHAP uses hash algorithms and a shared
    random value to authenticate. Passwords are never sent, and
    consequently no encryption, shared or public key is required.

    >
    > Why do you want to use UDP? *Why not ssh or ssl/web?
    >


    SSH is WAY to heavy. The data is not security sensitive, so why should
    I burn cycles encrypting it? Second, why should I support users who
    hose up their SSH or httpd installations?

    > --
    > These are my opinions, not necessarily my employer's. *I hate spam.



  9. Re: Linux Authentication Architecture Question:

    On Sep 15, 10:08*pm, Allen Kistler wrote:
    > Hal Murray wrote:
    > > In article <21bc80f1-87ea-4a90-a27c-a6c646c81...@d1g2000hsg.googlegroups.com>,
    > > *"shr...@cyberspace.org" writes:
    > >> Howdy,

    >
    > >> I am writing a UDP server daemon in perl, and I would like to back-end
    > >> its authentication into whatever the Linux box happens to be using for
    > >> user authentication at the moment.

    >
    > >> In consideration of PAM, LDAP, and the legacy password authentication
    > >> system, what is the most forward compatible, and installation tolerant
    > >> way of doing this? *I want to be able to distribute the daemon and
    > >> have it compile and work with various distros without a myriad of
    > >> grabastic dependencies.

    >
    > >> The data is not sensitive to snooping, but it does need to be
    > >> authenticated. So CHAP over UDP should be sufficient. *Is there a way
    > >> to pipe to "login" on the backend or something?

    >
    > > That sounds like either a lot of work or bad security.

    >
    > > If you don't want to send the password in the clear, you have
    > > to have some sort of encryption which probably requires something
    > > like a connection.

    >
    > > Why do you want to use UDP? *Why not ssh or ssl/web?

    >
    > I think folks are missing the OP's question.
    >
    > He's writing a service. *It doesn't matter what kind.
    > He wants to authenticate access to it.
    >
    > With no additional work or extra configuration required for his custom
    > service, he wants to use whatever the server OS uses for interactive
    > sessions. *If it uses /etc/passwd, his service would use /etc/passwd.
    > If it uses LDAP or NIS or whatever, his service would plug into the
    > authentication architecture the same way that interactive logins do,
    > transparently, no extra config required at installation.
    >
    > I suspect it's a matter of configuring pam correctly by writing a pam
    > module for the service, sticking a reference to it in a custom config
    > file, and dropping the config file into /etc/pam.d when you install the
    > service. *That's a guess on my part. *I haven't had a reason to drinkof
    > the pam nectar deeply yet. *I just poke at it from time to time for
    > stuff other people write.


    That's it in a nutshell. I am starting to think I will need to go
    through the source to telnetd, dig out the respective bits and make a
    perl extension. But I _really_ would rather work with an API or
    something instead of sticking my fingers in some positively ancient
    code. I would think somebody would have some documentation for the
    relative functions in glibc, or wherever the auth functions are in the
    shared libraries. This really shouldn't be too hard.


  10. Re: Linux Authentication Architecture Question:

    shrike@cyberspace.org wrote:
    > I am writing a UDP server daemon in perl, and I would like to back-end
    > its authentication into whatever the Linux box happens to be using for
    > user authentication at the moment.


    I would use PAM for the authentication. That way you don't have to care
    about the actual authentication backend in use. PAM has modules for LDAP,
    kerberos, passwd and many more backends.

    Toni
    --
    ---------------------------------------------------------------------------
    e9427514 (at) student.tuwien.ac.at

  11. Re: Linux Authentication Architecture Question:

    Antonio Batovanja wrote:
    > shrike@cyberspace.org wrote:
    >> I am writing a UDP server daemon in perl, and I would like to back-end
    >> its authentication into whatever the Linux box happens to be using for
    >> user authentication at the moment.

    >
    > I would use PAM for the authentication. That way you don't have to care
    > about the actual authentication backend in use. PAM has modules for LDAP,
    > kerberos, passwd and many more backends.
    >
    > Toni


    Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
    the client. The number of people who just slap in authentication technologies
    and don't think about this is... actually most of the Subversion using community.

  12. Re: Linux Authentication Architecture Question:

    Nico Kadel-Garcia wrote:
    > Antonio Batovanja wrote:
    >> shrike@cyberspace.org wrote:
    >>> I am writing a UDP server daemon in perl, and I would like to back-end
    >>> its authentication into whatever the Linux box happens to be using for
    >>> user authentication at the moment.

    >>
    >> I would use PAM for the authentication. That way you don't have to care
    >> about the actual authentication backend in use. PAM has modules for LDAP,
    >> kerberos, passwd and many more backends.
    >>
    >> Toni


    > Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
    > the client. The number of people who just slap in authentication technologies
    > and don't think about this is... actually most of the Subversion using community.


    Please clarify that for me.
    What does *transport encryption* from the client to the server have to do
    with the server process authenticating the user *on the server locally*
    using PAM?

    Sure, the transport channel *should* be encrypted, but that's a different
    problem.

    Toni
    --
    ---------------------------------------------------------------------------
    e9427514 (at) student.tuwien.ac.at

  13. Re: Linux Authentication Architecture Question:

    Antonio Batovanja wrote:
    > Nico Kadel-Garcia wrote:
    >> Antonio Batovanja wrote:
    >>> shrike@cyberspace.org wrote:
    >>>> I am writing a UDP server daemon in perl, and I would like to back-end
    >>>> its authentication into whatever the Linux box happens to be using for
    >>>> user authentication at the moment.
    >>> I would use PAM for the authentication. That way you don't have to care
    >>> about the actual authentication backend in use. PAM has modules for LDAP,
    >>> kerberos, passwd and many more backends.
    >>>
    >>> Toni

    >
    >> Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
    >> the client. The number of people who just slap in authentication technologies
    >> and don't think about this is... actually most of the Subversion using community.

    >
    > Please clarify that for me.
    > What does *transport encryption* from the client to the server have to do
    > with the server process authenticating the user *on the server locally*
    > using PAM?
    >
    > Sure, the transport channel *should* be encrypted, but that's a different
    > problem.
    >
    > Toni


    Some clients, like Jabber's default setup, store passwords in cleartext on the
    server. Some clients, such as Subversions's built-in HTTP and HTTPS tools,
    store it in cleartext on the client. The latter is the worst, because it will
    store your PAM passwords locally, in cleartext.

    The lack of encryption from client to server for this usage means that the
    passwords go over the wire in the clear, even if the authentication is done
    locally on the server.

+ Reply to Thread