If we do OFBIZ-9150 then we will have a tool to create SHA-512 hashes from
plain passwords words.
This tool could then be used in production to re-seed passwords, and possibly
fields, hashes.
We would then use SHA-512 encryption as default and have a properties in
security.properties to define the used encryption
If people prefer to keep less secure SHA1, that's their problem but it should
not be the default for the community
For demo data I don't see any problems changing hashes to be SHA-512 hashed.
Jacques
Le 14/12/2016 à 21:44, Taher Alkhateeb a écrit :
Ouch, didn't know that!
So then perhaps a parameterized approach is prudent while maintaining
backward compatibility. Might also give us the ability to add other
algorithms in the future.
On Dec 14, 2016 11:30 PM, "Scott Gray" <[email protected]> wrote:
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 <[email protected]>
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 <[email protected]>
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:[email protected]]
发送时间: 2016年12月5日 22:24
收件人: [email protected]
抄送: 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
