Just thinking a bit more about that. As Guido Amarilla pointed out in the beginning of this thread "It would be even safer for each
implementation if you keep this salt secret."
So maybe we should just provide a salting mechanism with clear explanations. I mean OFBiz paswords salted OOTB but only as a
demonstration and clear explanations about not only changing passwords (as it's already done for admin password) but also salt
string. Maybe Michael Jensen's idea of colon separating password and salt could be used ? I also remember the idea of having a salt
string only related to the password at hand (to avoid easy hack if the salt is discovered by a way or another...), this is also
called random salt (the alternative being static salt). But obviously this introduces a new breach has you have to store also the
random salt. Except if you use a part of the record only *you*know (for instance a part of the creation date field, etc.)
My 2cts
Jacques
From: "Jacques Le Roux" <[email protected]>
I'm just aware of https://issues.apache.org/jira/browse/OFBIZ-1151 (part of
https://issues.apache.org/jira/browse/OFBIZ-1525)
Jacques
From: "David E Jones" <[email protected]>
For those interested in this, please note that the message below is part of a discussion that is going on right now and no final
decision or approach has been made. This is something good to be aware of, but there is nothing to act on and no planned
changes yet for the ASF, and for OFBiz we'll be waiting on a recommendation of action from the ASF.
On a more internal functionality note (as opposed to foundation and project policy), we might consider doing something for the
password encrypted used within OFBiz. That should probably be done with a new prefix so that older/shorter SHA strings can
still be used, and actually it shouldn't be too difficult to do (just make sure we support SHA-2 with a 512 bit digest, and
then make it the default).
Has anyone looked into that sort of thing yet?
-David
On May 7, 2009, at 8:22 AM, Jacques Le Roux wrote:
FYI (found on Apache infra ML)
From: "Robert Burrell Donkin" <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NIST advises [1] that SHA1 should be EOL'd by the end of 2010. Recent
research[2] has revealed vulnerabilities in SHA1.
DSA requires a 160bit hash with SHA1 the most common choice. DSA has a
1024bit key length. This is considered too short[4] now with 4096 bits
being better but 8192 preferrable. Most digital signatures - including
many of those which secure the WOT[3] and Apache releases- use SHA1 and
DSA keys.
Debian are preparing to start transitioning away from DSA and SHA1[5]
towards longer keys. IMO Apache should think about how to do the same.
opinions?
some particular issues for apache:
* we ask for MD5 and SHA1 hashes, both of which now have known
vulnerabilities
* by end of 2010, keys of 1024 bits should no longer be considered
secure and will need to be revoked
* by end of 2010, all WOT links signed using SHA1 should be considered
insecure (and that's most of them)
* by end of 2010, signatures by 1024 bit keys should no longer be
considered secure and many of the keys that made them will have been revoked
i've started an issue[6] to track any actions apache needs to take. this
also has attached the results of a baseline scan i ran against
archive.apache.org.
- - robert
[1] See http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
[2] See
http://eurocrypt2009rump.cr.yp.to/ 837a0a8086fa6ca714249409ddfae43d.pdf
[3] Web Of Trust
[4] Applied Cryptography, Long Range Factor Predications
[5] http://www.debian-administration.org/users/dkg/weblog/48
[6] https://issues.apache.org/jira/browse/INFRA-2042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoC4BAACgkQQ617goCdfgNiuQCeLgbNoo82v+AFTLp3YD9DbKPD
OX8AoKcto++UaybAtNr4Tt3F+CH5J1iW
=StHh
-----END PGP SIGNATURE-----
