Thanks Scott
We are salting passwords* so we are a bit more secure. But yes, you are never
too secure.
Adam explains here http://tinyurl.com/z8zrsoc in OFBIZ-1151 that salting OOTB
seed data is another issue.
Note that in all cases the password would not change for users, only the hashes.
But yes the work done with OFBIZ-8537 does not include a tool for generating new hashes and we have not yet a tool to generate salted hashes when
releasing as suggested Adam.
Now, is that really a big deal? I don't think so because I guess/hope nobody is fool enough to use OOTB passwords and ashes. Especially for admin
user, even the name admin should not be used.
Nevertheless I think we should OOTB use SHA-512 instead of SHA-1 for our ashes
(with now 10 000 iterations thanks to r1773066) even if not hashed.
This for the purpose of leading our users to the best solution.
We should also documenting it, eg by mentioning this thread and referring to https://cryptosense.com/parameter-choice-for-pbkdf2/ (to be maintained of
course, this area will evolve...)
I'll create a OFBIZ-8537 subtask for that
Jacques
*(since 2012[1], thanks Adam! And talked about it since 2010[2])
[1] http://svn.apache.org/viewvc?view=revision&revision=1327741
http://markmail.org/message/ljalfchlgrfwdz7k
[2] http://markmail.org/message/ai3o3c5nyu4uvonp
Le 14/12/2016 à 21:30, Scott Gray a écrit :
Maybe ask LinkedIn, Zappos, Evernote, Living Social or Adobe if it's
prudent to assume that no one will ever get hold of your password hashes.
One researcher was able to recover 80% (~140 million) of passwords from the
LinkedIn breach in a single day, they were using unsalted SHA1.
Regards
Scott
On 9 December 2016 at 02:17, Taher Alkhateeb <slidingfilame...@gmail.com>
wrote:
I think the best solution in here is to actually parameterize the
encryption algorithm with a default backwards compatible choice (SHA1).
However, I'm not sure that we do need that. SHA1 is okay I think, and it
has the most support out there in terms of libraries. Do we have any
history of people cracking passwords in OFBiz _because_ they are SHA1? I
mean for that to happen, I think not only does the password have to be
weak, but the attacker should have access to the database and be able to
retrieve the password hashes, which seems less likely to me.
On Fri, Dec 9, 2016 at 12:06 PM, Michael Brohl <michael.br...@ecomify.de>
wrote:
I agree, Hans.
A new implementation should be optional and not simply replace the old.
Regards,
Michael
Am 09.12.16 um 03:12 schrieb Hans Bakker:
What is the impact?
if people have to re-enter the password then it is not acceptable.
it should be backwards compatible.
Regards,
Hans
On 08/12/16 16:33, Michael Brohl wrote:
Jacques,
I have no time to think about it more so I would prefer to create a
Jira, provide a patch and wait a few days for people to review.
I see no need to hurry with this issue.
Thanks,
Michael
Am 08.12.16 um 10:01 schrieb Jacques Le Roux:
OK, nobody expressed a concern so I'll apply a lazy consensus and
implement "SHA-512 and increase PBKDF2_ITERATIONS to 10 000"
Else please express your concern now before I create a Jira for that
Thanks
Jacques
Le 05/12/2016 à 16:38, Jacques Le Roux a écrit :
Thanks Jinghai, indeed Argon does not seems to be implemented in
available JDKs, maybe later...
Jacques
Le 05/12/2016 à 15:48, Shi Jinghai a écrit :
Hi Jacques,
Personally I'd prefer PBKDF2 rather than Argon, because the encrypt
of PBKDF2 is done by JDK, I don't know whether Argon has been
supported by JDK.
Kind Regards,
Shi Jinghai
-----邮件原件-----
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2016年12月5日 22:24
收件人: dev@ofbiz.apache.org
抄送: gregory draperi
主题: Replace password encryption SHA-1 by SHA-512
Hi,
At https://issues.apache.org/jira/browse/OFBIZ-8537 Junyuan has
contributed a new PBDKF2_SHA* one way encryption for password
At http://svn.apache.org/viewvc?rev=1772589&view=rev Jinghai has
committed it, I made few remarks on this commit, one of this comment
was also discussed in the Jira by Pierre and Michael. It's about
using PBDKF2 OOTB.
After reading https://cryptosense.com/parameter-choice-for-pbkdf2/
I
think we should replace our current SHA1 default implementation by
SHA-512 and increase PBKDF2_ITERATIONS to 10 000
We should also provide new PBDKF2_SHA1 password data.
As suggested by the article above, another step would be to use
Argon https://password-hashing.net/
What do you think?
Jacques
