Username/password authentication for thin clients

[Vladimir Ozerov]

Igniters,

Current Ignite has no means for user authentication and authorization. I
believe this is a big flaw in the product and we should start working on
it. As a first step I would like to propose to add simple username/password
authentication for our thin clients ("thin", JDBC, ODBC).

Proposed design:
1) Define hidden persistent cache for user credentials
2) Credentials will be stored in a form of [username + hash] [1]
3) Default superuser ignite/ignite will be defined by default. This is the
only user which can create other users
4) Authentication will be disabled by default to let users migrate from
previous versions easily
5) Clients will optionally pass username and password to the cluster during
handshake phase.
6) Password will be delivered in a *plain form*, because otherwise clients
will have to implement complex hashing logic on their own. SSL will be used
to protect passwords.
7) Create SQL commands for user management (CREATE USER, ALTER USER, DROP
USER)
8) May be we will also create native public API.

This will be our foundation for further security enhancements, such as:
- Node authentication
- Authorization mechanics
- Various no-password authentication techniques (e.g. certificate-based)

Please share your thoughts on proposed design.

Vladimir.

[1] Exact cryptographic function is to be defined.

[dmagda]

The overall proposal sounds simple and reasonable to me. However, I would suggest us to consider requirements of REST, Web Console and scripts that needs to be adopted too.

Alexey K., Andrey N., as Web Console maintainers please chime in.

Vladimir, do you think simple password based authentication and SQL commands for user management will be ready by 2.5 release?

—
Denis

> On Jan 15, 2018, at 12:19 AM, Vladimir Ozerov <[hidden email]> wrote:
>
> Igniters,
>
> Current Ignite has no means for user authentication and authorization. I
> believe this is a big flaw in the product and we should start working on
> it. As a first step I would like to propose to add simple username/password
> authentication for our thin clients ("thin", JDBC, ODBC).
>
> Proposed design:
> 1) Define hidden persistent cache for user credentials
> 2) Credentials will be stored in a form of [username + hash] [1]
> 3) Default superuser ignite/ignite will be defined by default. This is the
> only user which can create other users
> 4) Authentication will be disabled by default to let users migrate from
> previous versions easily
> 5) Clients will optionally pass username and password to the cluster during
> handshake phase.
> 6) Password will be delivered in a *plain form*, because otherwise clients
> will have to implement complex hashing logic on their own. SSL will be used
> to protect passwords.
> 7) Create SQL commands for user management (CREATE USER, ALTER USER, DROP
> USER)
> 8) May be we will also create native public API.
>
> This will be our foundation for further security enhancements, such as:
> - Node authentication
> - Authorization mechanics
> - Various no-password authentication techniques (e.g. certificate-based)
>
> Please share your thoughts on proposed design.
>
> Vladimir.
>
> [1] Exact cryptographic function is to be defined.

[Taras Ledkov]

What do you think about usage bcrypt [1], [2] to store encrypted password?

[1]
https://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt
[2] 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: [hidden email]

[Vladimir Ozerov]

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 <[hidden email]> wrote:

> What do you think about usage bcrypt [1], [2] to store encrypted password?
>
> [1] https://stackoverflow.com/questions/1561174/sha512-vs-blowfi
> sh-and-bcrypt
> [2] 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: [hidden email]
>
>

[Taras Ledkov]

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

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 <[hidden email]> wrote:
>
>> What do you think about usage bcrypt [1], [2] to store encrypted password?
>>
>> [1] https://stackoverflow.com/questions/1561174/sha512-vs-blowfi
>> sh-and-bcrypt
>> [2] 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: [hidden email]
>>
>>

--
Taras Ledkov
Mail-To: [hidden email]

[Taras Ledkov]

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


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
>
> 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<[hidden email]>  wrote:
>>
>>> What do you think about usage bcrypt [1], [2] to store encrypted password?
>>>
>>> [1]https://stackoverflow.com/questions/1561174/sha512-vs-blowfi
>>> sh-and-bcrypt
>>> [2]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:[hidden email]
>>>
>>>
>
> --
> Taras Ledkov
> Mail-To:[hidden email]

--
Taras Ledkov
Mail-To: [hidden email]

[Alexey Kuznetsov]

Taras,

How about to take a look at https://shiro.apache.org/ ?
Apache Shiro™ is a powerful and easy-to-use Java security framework.

It also supports Blowfish.
https://shiro.apache.org/static/1.3.1/apidocs/org/apache/shiro/crypto/BlowfishCipherService.html
And has Apache license.

--
Alexey Kuznetsov

[dmagda]

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 <[hidden email]> 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 <[hidden email]> <mailto:[hidden email]> 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: [hidden email] <mailto:[hidden email]>
>>>>
>>>>
>>
>> --
>> Taras Ledkov
>> Mail-To: [hidden email] <mailto:[hidden email]>
> --
> Taras Ledkov
> Mail-To: [hidden email] <mailto:[hidden email]>