James Mohr wrote: > There are enough open source projects with there own authentication, so you > would not be re-inventing the wheel. Further, most of the problems lie not in > the authentication mechanism, but failures in the rest of the code (i.e. SQL > injection, assuming that if particular code is reached the user *must* be > logged in, etc.)
Just because other projects do it doesn't make it a good idea. > These are going to happen with HTTP authentication, so you > are definately lulling yourself a false sense of security if you think "there > are few chances of security holes" with HTTP authentication. True, but then there's yet another subsystem to design/develop/maintain. Why not leverage the Apache developers to (unwittingly) help with Trac? Furthermore, I'm fairly certain Apache offers more authentication options than any of these other projects you mention that provide their "own" authentication. Do you already have all your users in a LDAP db? Or MySQL db? Or any authentication mechanism supported by PAM? Apache's plugins let you use those as is. > Also, I have HTTP authorization only set up to access the webserver itself. > That is, unless the user has an HTTP user and password, they cannot even > input the URLs to the various software I have installed. Each has its own > user management, which is actually **more** security. Not really. Forcing my browser's password-manager to remember three logins for the same site doesn't provide more security. It just provides a bigger hurdle to actually using the system. > Using HTTP authentication you have a single point of failure. Granted it > might be more "convenient" than an intergrated user management, but > convenience is that natural enemy of security. And obtuseness is also the enemy of security, in that users will find a way to subvert security to make it more convenient (ie a browser's password-manager). > In my case, if one package is comprimised, the cannot access any other. > Knowing that the application uses HTTP authentication, I know that should I > be able to compromise the application I am an authorized user from the > standpoint of the web server. You have a multitude of unstated assumptions that you're using here, and I don't want to try and point out each one, so let me just say this: while some users of Trac certainly use it in large scale and/or public-facing deployments, others (like me) use it on internal (behind firewall) sites where security is not an issue, and for small projects that can't afford a full-time "project-management admin" to maintain three mammoth software packages, coordinate three user databases, etc. One of the key features of Trac for me is that I, as a developer on a project, can spend 5 minutes getting a trac site up for my project, that's it. I leverage my department's sys-admins by using (via mod_pam) the user-database that they have to maintain anyway (on their own budget). etc, etc. Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users -~----------~----~----~----~------~----~------~--~---
