Re: [Dolibarr-dev] Vulnerabilities

Hi, that's a reason, yes. It still needs to be really prominent. Either don't store passwords as default or let the user make the decision directly in the setup. Salting in 3.5 is good. MD5 not, sorry. :) Assume it to be cracked, there are fully working rainbow tables. Maybe 3.5 is a possibility t

Re: [Dolibarr-dev] Vulnerabilities

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.

Re: [Dolibarr-dev] Vulnerabilities

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

Re: [Dolibarr-dev] Vulnerabilities

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).

Re: [Dolibarr-dev] Vulnerabilities

Hi, (sorry, I don't know how to reply directly to the existing thread: http://lists.nongnu.org/archive/html/dolibarr-dev/2013-10/msg3.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

Re: [Dolibarr-dev] Vulnerabilities

Le 18/10/2013 17:02, Doursenaud, Raphaël a écrit : > > 2013/10/17 Laurent Léonard > > > As specified at the end of the article you pointed, those > vulnerabilities are > fixed in Dolibarr 3.4.1: > > > It also says "However, their sanitization methods were

Re: [Dolibarr-dev] Vulnerabilities

On Fri, Oct 18, 2013 at 5:10 PM, Marcos García wrote: > I think we all knew about this vulnerabilities... And if not, we have been > warned about them months ago... > > But it is great that you fixed them. > > But I hoever do not understand well if they are fixed or just they have a temporary hac

Re: [Dolibarr-dev] Vulnerabilities

I think we all knew about this vulnerabilities... And if not, we have been warned about them months ago... But it is great that you fixed them. Regards, *Marcos García* marcos...@gmail.com 2013/10/18 Doursenaud, Raphaël > > 2013/10/17 Laurent Léonard > >> As specified at the end of the a

Re: [Dolibarr-dev] Vulnerabilities

2013/10/17 Laurent Léonard > As specified at the end of the article you pointed, those vulnerabilities > are > fixed in Dolibarr 3.4.1: > It also says "However, their sanitization methods were not fixed, and no mention was made on a future patch. Other SQLi vectors are likely." in the introduct

Re: [Dolibarr-dev] Vulnerabilities

On Thu, Oct 17, 2013 at 4:20 PM, Maxime Kohlhaas wrote: > Hi all, > > I just have been informed about this article : > http://forelsec.blogspot.fr/2013/10/dolibarr-340-multiple-vulnerabilities.html > > I'll take a look into it ASAP but I wanted to share this with you first. > > Regards, > > Thanks

Re: [Dolibarr-dev] Vulnerabilities

Hi Maxime, As specified at the end of the article you pointed, those vulnerabilities are fixed in Dolibarr 3.4.1: 10/06/2013 - Vendor notified of remotely exploitable vulnerabilities 10/07/2013 - Vendor acknowledges vulnerability, no timeline provided 10/11/2013 - Vendor states fix will be in th