It is an option because some users need to interface dolibarr with some
external system that needs authentication with clear password. In such
case, api or dolibarr addon/modules et batch needs to find password (an
example is module ldap).
When option is on, password is hashed with a md5 password.
With version 3.5, parameter "MAIN_SECURITY_SALT" will allow to choose value
for the salt.
In most cases, when we don't have the escape into the sql function, it is
because the data is not a data coming from a user input but a data computed
by dolibarr code because calling the request.
For example conf->entity is a data always defined by dolibarr and does not
depends from user input.
But you are right, it would be safer to always escape parameter.
This is a good remind for developper.
2013/11/3 Philip Lehmann-Böhm <phi...@philiplb.de>
> Hi, thank you for the answer.
> Ok,
> why is this an option? This is just not optional. Thanks for pointing me
> to it, I wouldn't have found it. :) The whole column "pass" should just
> be removed.
> How is the password crypted? I assume a salted and hashed password?
>
> How comes that you use an own function to escape query parameters and
> not the buildin ones?
> Take for example this one: admin/facture.php
>
> line 161: $sql.= " WHERE nom = '".$db->escape($value)."'";
>
> line 194: $sql.= " VALUES ('".$value."', '".$type."',
> ".$conf->entity.", ";
>
> $value is the same variable, one time escaped, one time not. Maybe this
> is dangerous, maybe not. If you'd use prepared statements and not string
> concatenation, this would not have slipped through.
>
> No offense meant, this is just important. :)
>
> Am 03.11.2013 22:11, schrieb Destailleur Laurent:
> > There is already an option to have password crypted into database (menu
> > security - encrypt password)
> >
> > Also you suggest to use a method to sanitized sql request parameters.
> > Using such a function to clean sql parameters is already done. The
> > function is called db->escape (a method of mysql.class.php). Port to use
> > it step by step was started few years ago.
> >
> > In a future the continuous integration platform should also be able to
> > cry when escaping parameters will be forgotten.
> >
> >
> >
> > 2013/11/3 Philip Lehmann-Böhm <phi...@philiplb.de
> > <mailto:phi...@philiplb.de>>
> >
> > Hi,
> >
> > (sorry, I don't know how to reply directly to the existing thread:
> >
> http://lists.nongnu.org/archive/html/dolibarr-dev/2013-10/msg00003.html
> > )
> >
> > This just blew my mind a bit. In this topic, especialy the denial of
> > starting to use parametrized queries.
> > And that the password is stored in plain text in the database is a
> > no go.
> >
> > And the statement, that everything of the quoted website has been
> fixed
> > is not true. I run a freshly installed Dolibarr 3.4.1 and the
> passwords
> > are indeed available in plain text!
> >
> > I'm willing to help here and this is what I propose:
> > - Are there plans to drop the plain password column? Has this already
> > happened in the next version? This goes to much in the core of
> Dolibarr,
> > so I won't be able to patch this in a meaningful timespan.
> >
> > - Not using prepared statements is a no go as well. I'd add support
> for
> > them in the mysql.class.php (not familiar with the others) with a
> > function like this:
> > function parametrizedQuery($query, $params,
> > $usesavepoint=0,$type='auto')
> > And then start to port the code to use it step by step and making
> some
> > pull requests.
> >
> > What do you think? Would this be a way to go?
> >
> > Best Regards
> > Philip
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > Dolibarr-dev@nongnu.org <mailto:Dolibarr-dev@nongnu.org>
> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> >
> >
> >
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > Dolibarr-dev@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> >
>
> _______________________________________________
> Dolibarr-dev mailing list
> Dolibarr-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
_______________________________________________
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
