[Mageia-sysadm] Users authentication on forums

nicolas vigier boklm at mars-attacks.org
Tue Apr 26 20:24:41 CEST 2011


On Tue, 19 Apr 2011, Michael Scherer wrote:

> Le lundi 11 avril 2011 à 14:39 +0200, nicolas vigier a écrit :
> > Hello,
> > 
> > For authentication on the forums, we are currently using ldap. The user
> > sends his login and passwords to phpbb which use it to authenticate on
> > ldap server. Because of this, someone with root access on the forums
> > server can access password of any user connecting to the forums. And
> > because important passwords are transfered, the connection needs to be
> > in SSL, so the *.mageia.org certificate also needs to be installed. So
> > access to the server needs to be restricted to sysadmin team only, who
> > also need to be able to check what is being done on forums, check it is
> > secure, etc ... And I think this makes forums admins not happy.
> 
> Then what about doing like french forums, and not connect at all to our
> ldap.
> 
> This let people the whole freedom to do what they want and allow us to
> focus on stuff that we need ( like deploying everything that need to be
> deployed, wiki, bittorrent server, etc, see the bugzilla for list of
> thing to do ).

Yes, that's what I was thinking first. One day that I decided to be
lazy and started to think how to get ride of forums. Maybe that is not
a good idea. But it was planned to migrate forums to an other server
installed and managed by other people, and we have the same problem in
that case, that other people not in sysadmin team are root on this server.
But even if we don't do that and continue to be the only root on the
server, someone hacking the phpbb server could easily add a password
logger in source code and steal passwords allowing access to svn or some
other servers.

So to avoid a security hole in one web app to give access to everything,
I think it would be useful to separate authentication part. Actually I
don't know enough about openid, oauth and other protocols to say which
one is better. But we can see this with help of webteam.

> 
> - we would need to make changes to applications, in a non upstreamable
> way. It was one of the point in favor of ldap , that everything can be
> easy to share. If we start to go this way, we will end like each time we
> go this way, with a huge forked stuff. Packagers learned this the hard
> way more than once. And lack of time + big pile of customization is what
> blocked forum upgrade for years, so I really think we start to learn
> from our past mistakes.

I think a phpbb oauth plugin could be upstreamable. There is already an
openid plugin, where we could add an option to force openid server, and
maybe upstream this option.

> - openid/oauth manage the authentication ( and some vcard stuff ) but
> not the autorisation. For example, Transifex ( and others django
> application ) do use ldap groups for autorisation and I think that's
> rather a good idea to manage this using ldap.
> 
> While it is not the case right now for forums, as said before, there was
> some discussions about having i18n/packagers/etc people having extended
> rights on some subforums, this would be harder to be done cleanly
> without a ldap access.

I though it was too difficult to do it in phpbb, so we decided to not
use ldap groups in phpbb. But using external authentication does not
prevent us to use ldap groups. It should be possible to give limited
ldap access to phpbb to read group infos and use something else for
authentication.

> - moreover, keeping group of people outside of our ldap would make
> various process harder. 
> 
> For example, if we want to elect moderators representatives, this would
> be tedious to do it on epoll if the group is stored elsewhere ( it is
> tedious now but there is some bug to fix for that ). If we want to setup
> a ml synced with ldap ( like board-private@ ), this would also cause
> data duplication. Email aliases are also based on ldap group membership,
> etc.

I agree that we shouldn't store groups elsewhere.

> - Most web applications will also need to access to email of users for
> various reasons ( like sending email ), most will also store the email
> for later usage. That's personal information that we should also protect
> and I think the various threads on the subject in the past, or the
> recent issue regarding Epsilon, or Google show that enough people care
> about that. We cannot share them with anyone without having this written
> in the privacy policy, ( policy that is still a draft cf bug 452 ) and
> told to users. 
> 
> 
> - Moreover, if we start to give private informations to 3rd party
> websites, they should IMHO also have a privacy policy, and respect it.
> But yet, we cannot do much to make sure it is enforced or respected,
> unless if we are root. And if we are root on the server, then I see no
> reason to not handle like the others ( ie, puppet etc ). Then we are
> back on the same issues that sparkled the proposal.
> 
> 
> - As said on irc, there is the security issues. While we can suffer from
> it on our servers too, this would be a wrong way of evaluating the risk.
> If we take for example X external web sites, managed by X different
> group, and the Mageia web applications, there is more attack surface
> ( around X+1 time more ) than just having the Mageia applications. And
> unless we can guarantee that all 3rd party admins will be skilled enough
> in the arcane of security, the risk would likely be bigger than smaller.

I think using an authentication server is better for security :
 - without authentication server, all web sites receive the ldap
   password, and have read/write access to the ldap from the user
   account. Someone taking control of one website can access all
   passwords of users connecting.
 - with authentication server, the web sites (except authentication
   web site) do not receive the password, so they cannot steal it, cannot
   authenticate on other websites. It's bad if one of the website is
   attacked, but it doesn't give access to the svn or other websites.



More information about the Mageia-sysadm mailing list