Taras, From what I see this license complies with Apache 2.0 and allows to do everything we want with the code. Just the license notice has to be preserved. So, I would add the source file to Ignite.
— Denis > On Feb 12, 2018, at 7:57 AM, Taras Ledkov <tled...@gridgain.com> wrote: > > Colleagues, Denis, > > It will be great to use bcrypt for password hashing in Ignite. > Could you suggest the right way to use bcrypt: > 1. add 'jbcrypt' maven dependency; > 2. include the single 'BCrypt.java' file to our project [1]. > > Does the license allow to include 'BCrypt.java' ? > > [1]. > https://github.com/jeremyh/jBCrypt/blob/master/src/main/java/org/mindrot/BCrypt.java > > <https://github.com/jeremyh/jBCrypt/blob/master/src/main/java/org/mindrot/BCrypt.java> > > On 18.01.2018 13:50, Taras Ledkov wrote: >> Password hashing algorithms of the popular vendors: >> >> mysql: SHA-265, old-native-hash >> postgres: MD5, DES, Extended DES, Blowfish-based >> oracle: SHA-1 >> >> Some about "comparison" SHA-2 vs bcrypt [1]: >> >> > SHA-512 is a cryptographic hash while bcrypt is a password hash or PBKDF >> > (password based key derivation function). >> >> > SHA-512 has been designed to be fast. You don't want any delays when >> > validating a signature, for instance. >> > There is no reason for generic cryptographic hashes to be slow. >> >> > bcrypt on the other hand is a password hash that performs key >> > strengthening on the input. >> > Basically it does this by slowing down the calculation so that attackers >> > will have to spend >> > more resources to find the input by brute forcing or dictionary attacks. >> > The idea is that although the legit users - you in this case - will also >> > be slowed down, >> > they are only slowed down once per password. However the attackers are >> > slowed down for each try. >> > The legit user is of course much more likely to input the right password >> > first. >> >> > Furthermore bcrypt also contains a salt as input, which can be used to >> > avert rainbow table attacks. >> >> Conclusion: bcrypt can provide more security but the popular vendors use SHA >> and even MD5 by default. >> >> [1]. >> https://crypto.stackexchange.com/questions/46550/benchmark-differences-between-sha-512-and-bcrypt >> >> <https://crypto.stackexchange.com/questions/46550/benchmark-differences-between-sha-512-and-bcrypt> >> >> On 18.01.2018 9:29, Vladimir Ozerov wrote: >>> Taras, >>> >>> I think we need a comparison of available options and (possibly) analysis >>> what other vendors use. >>> >>> On Tue, Jan 16, 2018 at 3:56 PM, Taras Ledkov <tled...@gridgain.com> >>> <mailto:tled...@gridgain.com> wrote: >>> >>>> What do you think about usage bcrypt [1], [2] to store encrypted password? >>>> >>>> [1] https://stackoverflow.com/questions/1561174/sha512-vs-blowfi >>>> <https://stackoverflow.com/questions/1561174/sha512-vs-blowfi> >>>> sh-and-bcrypt >>>> [2] https://en.wikipedia.org/wiki/Bcrypt >>>> <https://en.wikipedia.org/wiki/Bcrypt> >>>> >>>> >>>> >>>> On 15.01.2018 11:19, Vladimir Ozerov wrote: >>>> >>>>> 2) Credentials will be stored in a form of [username + hash] [1] >>>>> >>>> -- >>>> Taras Ledkov >>>> Mail-To: tled...@gridgain.com <mailto:tled...@gridgain.com> >>>> >>>> >> >> -- >> Taras Ledkov >> Mail-To: tled...@gridgain.com <mailto:tled...@gridgain.com> > -- > Taras Ledkov > Mail-To: tled...@gridgain.com <mailto:tled...@gridgain.com>
