[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006784#comment-16006784
 ] 

Mark Struberg commented on DELTASPIKE-1250:
---

A first design proposal can be found on my github repo 
https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250

Will now add a main method to generate the master password and encrypt content

> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted has derived from a master password 
> and box-locale information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009249#comment-16009249
 ] 

ASF subversion and git services commented on DELTASPIKE-1250:
-

Commit ebcac8257f3a170d5dcb2e8244e476830ade4c43 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=ebcac82 ]

DELTASPIKE-1250 add CLI client and switch to sha256


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009248#comment-16009248
 ] 

ASF subversion and git services commented on DELTASPIKE-1250:
-

Commit a57fbcfa7e924fa65c167daedf7e523a5c4169c5 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a57fbcf ]

DELTASPIKE-1250 CipherService for encrypting/decrypting with secrets


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012091#comment-16012091
 ] 

ASF subversion and git services commented on DELTASPIKE-1250:
-

Commit 0cdede08c07b0ed791b9018e1ea5281b690728ae in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=0cdede0 ]

DELTASPIKE-1250 only log out the master.hash index key not the hash itself


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021241#comment-16021241
 ] 

ASF subversion and git services commented on DELTASPIKE-1250:
-

Commit d1cc650d68686d02656f53a4f532a2acb911bc6d in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=d1cc650 ]

DELTASPIKE-1250 add documentation and improve JavaDocs


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021537#comment-16021537
 ] 

ASF subversion and git services commented on DELTASPIKE-1250:
-

Commit 98d4c2ab2ea2ce15cfe60c637a3792c3843b49f4 in deltaspike's branch 
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=98d4c2a ]

DELTASPIKE-1250 adding documentation for encryption


> create a master/client encryption handling
> --
>
> Key: DELTASPIKE-1250
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1250
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 1.7.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> For storing passwords in our configuration I'd like to implement a 2 stage 
> approach to symmetric encryption.
> The current ideas is to have an encrypted hash derived from a master password 
> and machine specific information (MAC, IP, expiry date, etc).
> This encrypted sequence is different on every box. But the decrypted hash is 
> not.
>  
> With this hash we can encode a user password, which is then ofc the same on 
> different boxes. 
> Of course all that is just security by obscurity, but it's still much better 
> than plaintext and even close to Hashicorp Vault.
> After all, the only really secure way is using a hardware crypto box plus the 
> user has to manually provide a password and not using static passwords but 
> 1-time consumable tokens.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Rudy De Busscher]

Hi Mark,

As I'm working lately quite a lot with security and encryption, I was
interested in your implementation.

I don't have the time today to look into details, but I already have some
questions

- Why hashing with SHA-1 (not a secure hashing algorithm anymore). Why the
additional hashing (before AES encryption) as you mention that we try only
to 'obscure'.
- When I use AES, I always use an Initialization Vector (IV) and specify
the Block mode and padding.

I'll try to find some time this weekend to study the code in detail.

best regards
Rudy


On 11 May 2017 at 19:05, Mark Struberg (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16006784#comment-16006784 ]
>
> Mark Struberg commented on DELTASPIKE-1250:
> ---
>
> A first design proposal can be found on my github repo
> https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250
>
> Will now add a main method to generate the master password and encrypt
> content
>
> > create a master/client encryption handling
> > --
> >
> > Key: DELTASPIKE-1250
> > URL: https://issues.apache.org/
> jira/browse/DELTASPIKE-1250
> > Project: DeltaSpike
> >  Issue Type: New Feature
> >  Components: Configuration
> >Affects Versions: 1.7.2
> >Reporter: Mark Struberg
> >Assignee: Mark Struberg
> > Fix For: 1.8.0
> >
> >
> > For storing passwords in our configuration I'd like to implement a 2
> stage approach to symmetric encryption.
> > The current ideas is to have an encrypted has derived from a master
> password and box-locale information (MAC, IP, expiry date, etc).
> > This encrypted sequence is different on every box. But the decrypted
> hash is not.
> >
> > With this hash we can encode a user password, which is then ofc the same
> on different boxes.
> > Of course all that is just security by obscurity, but it's still much
> better than plaintext and even close to vault.
> > After all, the only really secure way is using a hardware crypto box
> plus the user has to manually provide a password and not using static
> passwords but 1-time consumable tokens.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

Txs Rudy, any help is welcome!


> - Why hashing with SHA-1

I guess you mean the master hash?

Oki, there are 3 encryption tokens in place:

1.) The master password provided by the user in the CLI when creating the 
master password (writing the CLI right now):

$> java -jar apache-deltaspike-core-impl.jar encode -masterPassword 
myMasterPassword -masterSalt someSecretOnlyKnownToMeAndTheApplication

The masterPassword does NOT get stored anywhere. Neither in plain text nor 
encrypted. It's _only_ known to the user who creates the masterHas.

2.) The masterPassword ("myMasterPassword") gets hashed and THIS will be used 
to encrypt/decrypt the user passwords in the end. 
Of course the hash does _not_ get stored directly but only encrypted via the 
master Salt ("someSecretOnlyKnownToMeAndTheApplication"). 
The key in the ~/.deltaspike/master.hash properties file is the the hash hashed 
again: effectively hash(hash(masterPassword)). That way you cannot get back 
from the key in the master.hash file to the key used to decrypt the hash of the 
masterPassword

3.) the hash of the masterPassword (as stored in the master.hash file encrypted 
via the masterSalt) is then used to encrypt/decrypt the actual security, e.g. a 
jdbc.user.password.
There is again a CLI to encode it
$> java -jar apache-deltaspike-core-impl.jar encode -plaintext 
ThisIsMyDatabasePassword -masterSalt someSecretOnlyKnownToMeAndTheApplication



To give more protection, the masterSalt is only known to the administrator and 
the application. This could also include installation dependent information 
like the MAC address, the UID of the /dev/sda disk, etc. Even the current day! 
That way you can force a master password hash which is only valid for a single 
day, of course without having to re-encrypted information stored somewhere in 
your DB etc. every day.


Makes sense?

LieGrue,
strub




> - When I use AES, I always use an Initialization Vector (IV) and specify
> the Block mode and padding.


Glad to improve that part!


> Am 11.05.2017 um 21:11 schrieb Rudy De Busscher :
> 
> Hi Mark,
> 
> As I'm working lately quite a lot with security and encryption, I was
> interested in your implementation.
> 
> I don't have the time today to look into details, but I already have some
> questions
> 
> - Why hashing with SHA-1 (not a secure hashing algorithm anymore). Why the
> additional hashing (before AES encryption) as you mention that we try only
> to 'obscure'.
> - When I use AES, I always use an Initialization Vector (IV) and specify
> the Block mode and padding.
> 
> I'll try to find some time this weekend to study the code in detail.
> 
> best regards
> Rudy
> 
> 
> On 11 May 2017 at 19:05, Mark Struberg (JIRA)  wrote:
> 
>> 
>>[ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
>> focusedCommentId=16006784#comment-16006784 ]
>> 
>> Mark Struberg commented on DELTASPIKE-1250:
>> ---
>> 
>> A first design proposal can be found on my github repo
>> https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250
>> 
>> Will now add a main method to generate the master password and encrypt
>> content
>> 
>>> create a master/client encryption handling
>>> --
>>> 
>>>Key: DELTASPIKE-1250
>>>URL: https://issues.apache.org/
>> jira/browse/DELTASPIKE-1250
>>>Project: DeltaSpike
>>> Issue Type: New Feature
>>> Components: Configuration
>>>   Affects Versions: 1.7.2
>>>   Reporter: Mark Struberg
>>>   Assignee: Mark Struberg
>>>Fix For: 1.8.0
>>> 
>>> 
>>> For storing passwords in our configuration I'd like to implement a 2
>> stage approach to symmetric encryption.
>>> The current ideas is to have an encrypted has derived from a master
>> password and box-locale information (MAC, IP, expiry date, etc).
>>> This encrypted sequence is different on every box. But the decrypted
>> hash is not.
>>> 
>>> With this hash we can encode a user password, which is then ofc the same
>> on different boxes.
>>> Of course all that is just security by obscurity, but it's still much
>> better than plaintext and even close to vault.
>>> After all, the only really secure way is using a hardware crypto box
>> plus the user has to manually provide a password and not using static
>> passwords but 1-time consumable tokens.
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.15#6346)
>> 

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

Btw, the date, etc should of course _not_ get handed over as masterSalt in 
cleartext! 
If someone would debug the app (also stealing the jars) then a string like "my 
app-2017-05-12-192.168.4.123
Then it would be easily recognisable how the pattern looks like. 
But if you just apply a sha1 on that string, then nobody could tell what is 
behind is. And you could hie this information pretty well in your application 
somewhere.

Of course that does still not create absolute security (there is no such thing 
like an absolute security).
But an attacker would need
* the actual encrypted secret information string
* the ~/.deltaspike/master.hash file (or wherever you store it, this is just 
the default)
* the fully running application (with most business applications this is not as 
easy as it sounds - try to install a big app on some fresh server...)
* the algorithm of the masterSalt.


LieGrue,
strub



> Am 12.05.2017 um 12:31 schrieb Mark Struberg :
> 
> Txs Rudy, any help is welcome!
> 
> 
>> - Why hashing with SHA-1
> 
> I guess you mean the master hash?
> 
> Oki, there are 3 encryption tokens in place:
> 
> 1.) The master password provided by the user in the CLI when creating the 
> master password (writing the CLI right now):
> 
> $> java -jar apache-deltaspike-core-impl.jar encode -masterPassword 
> myMasterPassword -masterSalt someSecretOnlyKnownToMeAndTheApplication
> 
> The masterPassword does NOT get stored anywhere. Neither in plain text nor 
> encrypted. It's _only_ known to the user who creates the masterHas.
> 
> 2.) The masterPassword ("myMasterPassword") gets hashed and THIS will be used 
> to encrypt/decrypt the user passwords in the end. 
> Of course the hash does _not_ get stored directly but only encrypted via the 
> master Salt ("someSecretOnlyKnownToMeAndTheApplication"). 
> The key in the ~/.deltaspike/master.hash properties file is the the hash 
> hashed again: effectively hash(hash(masterPassword)). That way you cannot get 
> back from the key in the master.hash file to the key used to decrypt the hash 
> of the masterPassword
> 
> 3.) the hash of the masterPassword (as stored in the master.hash file 
> encrypted via the masterSalt) is then used to encrypt/decrypt the actual 
> security, e.g. a jdbc.user.password.
> There is again a CLI to encode it
> $> java -jar apache-deltaspike-core-impl.jar encode -plaintext 
> ThisIsMyDatabasePassword -masterSalt someSecretOnlyKnownToMeAndTheApplication
> 
> 
> 
> To give more protection, the masterSalt is only known to the administrator 
> and the application. This could also include installation dependent 
> information like the MAC address, the UID of the /dev/sda disk, etc. Even the 
> current day! That way you can force a master password hash which is only 
> valid for a single day, of course without having to re-encrypted information 
> stored somewhere in your DB etc. every day.
> 
> 
> Makes sense?
> 
> LieGrue,
> strub
> 
> 
> 
> 
>> - When I use AES, I always use an Initialization Vector (IV) and specify
>> the Block mode and padding.
> 
> 
> Glad to improve that part!
> 
> 
>> Am 11.05.2017 um 21:11 schrieb Rudy De Busscher :
>> 
>> Hi Mark,
>> 
>> As I'm working lately quite a lot with security and encryption, I was
>> interested in your implementation.
>> 
>> I don't have the time today to look into details, but I already have some
>> questions
>> 
>> - Why hashing with SHA-1 (not a secure hashing algorithm anymore). Why the
>> additional hashing (before AES encryption) as you mention that we try only
>> to 'obscure'.
>> - When I use AES, I always use an Initialization Vector (IV) and specify
>> the Block mode and padding.
>> 
>> I'll try to find some time this weekend to study the code in detail.
>> 
>> best regards
>> Rudy
>> 
>> 
>> On 11 May 2017 at 19:05, Mark Struberg (JIRA)  wrote:
>> 
>>> 
>>>   [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
>>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
>>> focusedCommentId=16006784#comment-16006784 ]
>>> 
>>> Mark Struberg commented on DELTASPIKE-1250:
>>> ---
>>> 
>>> A first design proposal can be found on my github repo
>>> https://github.com/struberg/deltaspike/tree/DELTASPIKE-1250
>>> 
>>> Will now add a main method to generate the master password and encrypt
>>> content
>>> 
 create a master/client encryption handling
 --
 
   Key: DELTASPIKE-1250
   URL: https://issues.apache.org/
>>> jira/browse/DELTASPIKE-1250
   Project: DeltaSpike
Issue Type: New Feature
Components: Configuration
  Affects Versions: 1.7.2
  Reporter: Mark Struberg
  Assignee: Mark Struberg
   Fix For: 1.8.0
 
 
 For storing passwords in our configuration I'd like to implement a 2
>>> stage approach to symmetric encryption.
 The current ideas is to have an encrypte

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Romain Manni-Bucau]

I think until we support a hsm strategy- which relies on infra more than
encryption - we can just put it all in clear, security level will be 1-1.
So IMHO it is really "do people feel more comfortable with unclear text
even if it is as secured as clear text". If we start to go until "if I'm in
the app" then the security is compromished anyway even if it is sha etc...

So concretely I think it is fine but if the proposed action is just to move
to sha-256 or another impl it doesnt hurt much to do, if the action is more
impacting like creating 1000 files of 1M with a very specific stratégy to
read a byte in each of them depending the file timestamp and jumping on a
leg I'm not sure it does worth it since the assumption to access the clear
password is exactly the same as having it in clear.

makes sense?



Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-05-12 12:57 GMT+02:00 Mark Struberg :

> Btw, the date, etc should of course _not_ get handed over as masterSalt in
> cleartext!
> If someone would debug the app (also stealing the jars) then a string like
> "my app-2017-05-12-192.168.4.123
> Then it would be easily recognisable how the pattern looks like.
> But if you just apply a sha1 on that string, then nobody could tell what
> is behind is. And you could hie this information pretty well in your
> application somewhere.
>
> Of course that does still not create absolute security (there is no such
> thing like an absolute security).
> But an attacker would need
> * the actual encrypted secret information string
> * the ~/.deltaspike/master.hash file (or wherever you store it, this is
> just the default)
> * the fully running application (with most business applications this is
> not as easy as it sounds - try to install a big app on some fresh server...)
> * the algorithm of the masterSalt.
>
>
> LieGrue,
> strub
>
>
>
> > Am 12.05.2017 um 12:31 schrieb Mark Struberg  >:
> >
> > Txs Rudy, any help is welcome!
> >
> >
> >> - Why hashing with SHA-1
> >
> > I guess you mean the master hash?
> >
> > Oki, there are 3 encryption tokens in place:
> >
> > 1.) The master password provided by the user in the CLI when creating
> the master password (writing the CLI right now):
> >
> > $> java -jar apache-deltaspike-core-impl.jar encode -masterPassword
> myMasterPassword -masterSalt someSecretOnlyKnownToMeAndTheApplication
> >
> > The masterPassword does NOT get stored anywhere. Neither in plain text
> nor encrypted. It's _only_ known to the user who creates the masterHas.
> >
> > 2.) The masterPassword ("myMasterPassword") gets hashed and THIS will be
> used to encrypt/decrypt the user passwords in the end.
> > Of course the hash does _not_ get stored directly but only encrypted via
> the master Salt ("someSecretOnlyKnownToMeAndTheApplication").
> > The key in the ~/.deltaspike/master.hash properties file is the the hash
> hashed again: effectively hash(hash(masterPassword)). That way you cannot
> get back from the key in the master.hash file to the key used to decrypt
> the hash of the masterPassword
> >
> > 3.) the hash of the masterPassword (as stored in the master.hash file
> encrypted via the masterSalt) is then used to encrypt/decrypt the actual
> security, e.g. a jdbc.user.password.
> > There is again a CLI to encode it
> > $> java -jar apache-deltaspike-core-impl.jar encode -plaintext
> ThisIsMyDatabasePassword -masterSalt someSecretOnlyKnownToMeAndTheA
> pplication
> >
> >
> >
> > To give more protection, the masterSalt is only known to the
> administrator and the application. This could also include installation
> dependent information like the MAC address, the UID of the /dev/sda disk,
> etc. Even the current day! That way you can force a master password hash
> which is only valid for a single day, of course without having to
> re-encrypted information stored somewhere in your DB etc. every day.
> >
> >
> > Makes sense?
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >> - When I use AES, I always use an Initialization Vector (IV) and specify
> >> the Block mode and padding.
> >
> >
> > Glad to improve that part!
> >
> >
> >> Am 11.05.2017 um 21:11 schrieb Rudy De Busscher  >:
> >>
> >> Hi Mark,
> >>
> >> As I'm working lately quite a lot with security and encryption, I was
> >> interested in your implementation.
> >>
> >> I don't have the time today to look into details, but I already have
> some
> >> questions
> >>
> >> - Why hashing with SHA-1 (not a secure hashing algorithm anymore). Why
> the
> >> additional hashing (before AES encryption) as you mention that we try
> only
> >> to 'obscure'.
> >> - When I use AES, I always use an Initialization Vector (IV) and specify
> >> the Block mode and padding.
> >>
> >> I'll try to find some tim

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

Well, not 100% d'accord. 

Of course it is just a split-secret security. 
Parts of the secret are in a file, others in the application.
An attacker would need to gather
* the master.hash file
* the application (or at least the masterSalt text or algorithm)
* the encrypted date (Database etc).

So he actually needs quite some access already!
This is surely better than a cleartext password stored in the database which 
everyone could see.

But of course, once an attacker comes over the debug port, etc - then ALL 
security is gone. 
I think our approach is not much behing Hashicorp Vault in that regard (you 
could btw also gather parts of the secret from a remote box in your code). 
After all the ONLY secure system is if you have a HSM (a hardware security 
device) which has it's OWN pin entry (!) AND you only access the information 
via a consumable 1-time security token.
But as long as e.g. the database is just secured with a static text 
(username/password) then everything else is mathematically breakable.

Still there is imo a HUGE difference between a cleartext password and a 
split-secret approach.

LieGrue,
strub

> Am 12.05.2017 um 13:06 schrieb Romain Manni-Bucau :
> 
> I think until we support a hsm strategy- which relies on infra more than
> encryption - we can just put it all in clear, security level will be 1-1.
> So IMHO it is really "do people feel more comfortable with unclear text
> even if it is as secured as clear text". If we start to go until "if I'm in
> the app" then the security is compromished anyway even if it is sha etc...
> 
> So concretely I think it is fine but if the proposed action is just to move
> to sha-256 or another impl it doesnt hurt much to do, if the action is more
> impacting like creating 1000 files of 1M with a very specific stratégy to
> read a byte in each of them depending the file timestamp and jumping on a
> leg I'm not sure it does worth it since the assumption to access the clear
> password is exactly the same as having it in clear.
> 
> makes sense?
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | JavaEE Factory
> 
> 
> 2017-05-12 12:57 GMT+02:00 Mark Struberg :
> 
>> Btw, the date, etc should of course _not_ get handed over as masterSalt in
>> cleartext!
>> If someone would debug the app (also stealing the jars) then a string like
>> "my app-2017-05-12-192.168.4.123
>> Then it would be easily recognisable how the pattern looks like.
>> But if you just apply a sha1 on that string, then nobody could tell what
>> is behind is. And you could hie this information pretty well in your
>> application somewhere.
>> 
>> Of course that does still not create absolute security (there is no such
>> thing like an absolute security).
>> But an attacker would need
>> * the actual encrypted secret information string
>> * the ~/.deltaspike/master.hash file (or wherever you store it, this is
>> just the default)
>> * the fully running application (with most business applications this is
>> not as easy as it sounds - try to install a big app on some fresh server...)
>> * the algorithm of the masterSalt.
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 12.05.2017 um 12:31 schrieb Mark Struberg >> :
>>> 
>>> Txs Rudy, any help is welcome!
>>> 
>>> 
 - Why hashing with SHA-1
>>> 
>>> I guess you mean the master hash?
>>> 
>>> Oki, there are 3 encryption tokens in place:
>>> 
>>> 1.) The master password provided by the user in the CLI when creating
>> the master password (writing the CLI right now):
>>> 
>>> $> java -jar apache-deltaspike-core-impl.jar encode -masterPassword
>> myMasterPassword -masterSalt someSecretOnlyKnownToMeAndTheApplication
>>> 
>>> The masterPassword does NOT get stored anywhere. Neither in plain text
>> nor encrypted. It's _only_ known to the user who creates the masterHas.
>>> 
>>> 2.) The masterPassword ("myMasterPassword") gets hashed and THIS will be
>> used to encrypt/decrypt the user passwords in the end.
>>> Of course the hash does _not_ get stored directly but only encrypted via
>> the master Salt ("someSecretOnlyKnownToMeAndTheApplication").
>>> The key in the ~/.deltaspike/master.hash properties file is the the hash
>> hashed again: effectively hash(hash(masterPassword)). That way you cannot
>> get back from the key in the master.hash file to the key used to decrypt
>> the hash of the masterPassword
>>> 
>>> 3.) the hash of the masterPassword (as stored in the master.hash file
>> encrypted via the masterSalt) is then used to encrypt/decrypt the actual
>> security, e.g. a jdbc.user.password.
>>> There is again a CLI to encode it
>>> $> java -jar apache-deltaspike-core-impl.jar encode -plaintext
>> ThisIsMyDatabasePassword -masterSalt someSecretOnlyKnownToMeAndTheA
>> pplication

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Romain Manni-Bucau]

2017-05-12 13:16 GMT+02:00 Mark Struberg :

> Well, not 100% d'accord.
>
> Of course it is just a split-secret security.
> Parts of the secret are in a file, others in the application.
> An attacker would need to gather
> * the master.hash file
> * the application (or at least the masterSalt text or algorithm)
> * the encrypted date (Database etc).
>
> So he actually needs quite some access already!
> This is surely better than a cleartext password stored in the database
> which everyone could see.
>
> But of course, once an attacker comes over the debug port, etc - then ALL
> security is gone.
> I think our approach is not much behing Hashicorp Vault in that regard
> (you could btw also gather parts of the secret from a remote box in your
> code).
> After all the ONLY secure system is if you have a HSM (a hardware security
> device) which has it's OWN pin entry (!) AND you only access the
> information via a consumable 1-time security token.
> But as long as e.g. the database is just secured with a static text
> (username/password) then everything else is mathematically breakable.
>
> Still there is imo a HUGE difference between a cleartext password and a
> split-secret approach.
>

Nop, not theorically. I understand it feels different, kind of "oh a
password" vs "what's that text?" but if you have accesses to read the clear
password then the encrypted one is as easy to get. All this security relies
on the local access (which gives you access to the files, db etc...), all
other things put around is cosmetic to make people comfortable with it.
More it is split longer it will be to get but since the algo is predictable
then not more secured until you rotate the strategy very often, like each
minute.


>
> LieGrue,
> strub
>
> > Am 12.05.2017 um 13:06 schrieb Romain Manni-Bucau  >:
> >
> > I think until we support a hsm strategy- which relies on infra more than
> > encryption - we can just put it all in clear, security level will be 1-1.
> > So IMHO it is really "do people feel more comfortable with unclear text
> > even if it is as secured as clear text". If we start to go until "if I'm
> in
> > the app" then the security is compromished anyway even if it is sha
> etc...
> >
> > So concretely I think it is fine but if the proposed action is just to
> move
> > to sha-256 or another impl it doesnt hurt much to do, if the action is
> more
> > impacting like creating 1000 files of 1M with a very specific stratégy to
> > read a byte in each of them depending the file timestamp and jumping on a
> > leg I'm not sure it does worth it since the assumption to access the
> clear
> > password is exactly the same as having it in clear.
> >
> > makes sense?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-05-12 12:57 GMT+02:00 Mark Struberg :
> >
> >> Btw, the date, etc should of course _not_ get handed over as masterSalt
> in
> >> cleartext!
> >> If someone would debug the app (also stealing the jars) then a string
> like
> >> "my app-2017-05-12-192.168.4.123
> >> Then it would be easily recognisable how the pattern looks like.
> >> But if you just apply a sha1 on that string, then nobody could tell what
> >> is behind is. And you could hie this information pretty well in your
> >> application somewhere.
> >>
> >> Of course that does still not create absolute security (there is no such
> >> thing like an absolute security).
> >> But an attacker would need
> >> * the actual encrypted secret information string
> >> * the ~/.deltaspike/master.hash file (or wherever you store it, this is
> >> just the default)
> >> * the fully running application (with most business applications this is
> >> not as easy as it sounds - try to install a big app on some fresh
> server...)
> >> * the algorithm of the masterSalt.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 12.05.2017 um 12:31 schrieb Mark Struberg  >>> :
> >>>
> >>> Txs Rudy, any help is welcome!
> >>>
> >>>
>  - Why hashing with SHA-1
> >>>
> >>> I guess you mean the master hash?
> >>>
> >>> Oki, there are 3 encryption tokens in place:
> >>>
> >>> 1.) The master password provided by the user in the CLI when creating
> >> the master password (writing the CLI right now):
> >>>
> >>> $> java -jar apache-deltaspike-core-impl.jar encode -masterPassword
> >> myMasterPassword -masterSalt someSecretOnlyKnownToMeAndTheApplication
> >>>
> >>> The masterPassword does NOT get stored anywhere. Neither in plain text
> >> nor encrypted. It's _only_ known to the user who creates the masterHas.
> >>>
> >>> 2.) The masterPassword ("myMasterPassword") gets hashed and THIS will
> be
> >> used to encrypt/decrypt the user passwords in the end.
> >>> Of course the h

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

With your take even pgp is unsecure!

Because if you can get the private key file AND you know the password, then you 
can encrypted everything.

Ofc there is no absolute security, but given enough chained steps which are 
cryptographically strong in itself makes it still so much better than plaintext.

LieGrue,
Strub




On Fri, 12/5/17, Romain Manni-Bucau  wrote:

 Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client 
encryption handling
 To: "dev@deltaspike.apache.org" 
 Date: Friday, 12 May, 2017, 13:28
 
 2017-05-12 13:16 GMT+02:00 Mark
 Struberg :
 
 > Well, not 100%
 d'accord.
 >
 > Of
 course it is just a split-secret security.
 > Parts of the secret are in a file, others
 in the application.
 > An attacker would
 need to gather
 > * the master.hash
 file
 > * the application (or at least the
 masterSalt text or algorithm)
 > * the
 encrypted date (Database etc).
 >
 > So he actually needs quite some access
 already!
 > This is surely better than a
 cleartext password stored in the database
 > which everyone could see.
 >
 > But of course, once
 an attacker comes over the debug port, etc - then ALL
 > security is gone.
 > I
 think our approach is not much behing Hashicorp Vault in
 that regard
 > (you could btw also gather
 parts of the secret from a remote box in your
 > code).
 > After all the
 ONLY secure system is if you have a HSM (a hardware
 security
 > device) which has it's OWN
 pin entry (!) AND you only access the
 >
 information via a consumable 1-time security token.
 > But as long as e.g. the database is just
 secured with a static text
 >
 (username/password) then everything else is mathematically
 breakable.
 >
 > Still
 there is imo a HUGE difference between a cleartext password
 and a
 > split-secret approach.
 >
 
 Nop, not
 theorically. I understand it feels different, kind of
 "oh a
 password" vs
 "what's that text?" but if you have accesses
 to read the clear
 password then the
 encrypted one is as easy to get. All this security relies
 on the local access (which gives you access to
 the files, db etc...), all
 other things put
 around is cosmetic to make people comfortable with it.
 More it is split longer it will be to get but
 since the algo is predictable
 then not more
 secured until you rotate the strategy very often, like
 each
 minute.
 
 
 >
 > LieGrue,
 > strub
 >
 > > Am 12.05.2017 um 13:06 schrieb Romain
 Manni-Bucau  >:
 > >
 > > I think until we support a hsm
 strategy- which relies on infra more than
 > > encryption - we can just put it all
 in clear, security level will be 1-1.
 >
 > So IMHO it is really "do people feel more
 comfortable with unclear text
 > > even
 if it is as secured as clear text". If we start to go
 until "if I'm
 > in
 > > the app" then the security is
 compromished anyway even if it is sha
 >
 etc...
 > >
 > >
 So concretely I think it is fine but if the proposed action
 is just to
 > move
 >
 > to sha-256 or another impl it doesnt hurt much to do,
 if the action is
 > more
 > > impacting like creating 1000 files of
 1M with a very specific stratégy to
 >
 > read a byte in each of them depending the file
 timestamp and jumping on a
 > > leg
 I'm not sure it does worth it since the assumption to
 access the
 > clear
 >
 > password is exactly the same as having it in clear.
 > >
 > > makes
 sense?
 > >
 >
 >
 > >
 > >
 Romain Manni-Bucau
 > > @rmannibucau
 <https://twitter.com/rmannibucau> | 
 Blog
 > > <https://blog-rmannibucau.rhcloud.com>
 | Old Blog
 > > <http://rmannibucau.wordpress.com> |
 Github <https://github.com/
 >
 rmannibucau> |
 > > LinkedIn <https://www.linkedin.com/in/rmannibucau>
 | JavaEE Factory
 > > <https://javaeefactory-rmannibucau.rhcloud.com>
 > >
 > > 2017-05-12
 12:57 GMT+02:00 Mark Struberg :
 > >
 > >> Btw,
 the date, etc should of course _not_ get handed over as
 masterSalt
 > in
 >
 >> cleartext!
 > >> If someone
 would debug the app (also stealing the jars) then a
 string
 > like
 >
 >> "my app-2017-05-12-192.168.4.123
 > >> Then it would be easily
 recognisable how the pattern looks like.
 > >> But if you just apply a sha1 on
 that string, then nobody could tell what
 > >> is behind is. And you could hie
 this information pretty well in your
 >
 >> application somewhere.
 >
 >>
 > >> Of course that does
 still not create absolute security (there is no such
 > >> thing like an absolute
 security).
 > >> But an attacker
 would need
 > >&

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Romain Manni-Bucau]

sure, point is master key in clear or not doesnt change anything. Security
of such a system is only guaranteed by the split of the master key and the
encrypted value but when you have both at the same location security is not
more a question.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-05-12 13:50 GMT+02:00 Mark Struberg :

> With your take even pgp is unsecure!
>
> Because if you can get the private key file AND you know the password,
> then you can encrypted everything.
>
> Ofc there is no absolute security, but given enough chained steps which
> are cryptographically strong in itself makes it still so much better than
> plaintext.
>
> LieGrue,
> Strub
>
>
>
> ----
> On Fri, 12/5/17, Romain Manni-Bucau  wrote:
>
>  Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client
> encryption handling
>  To: "dev@deltaspike.apache.org" 
>  Date: Friday, 12 May, 2017, 13:28
>
>  2017-05-12 13:16 GMT+02:00 Mark
>  Struberg :
>
>  > Well, not 100%
>  d'accord.
>  >
>  > Of
>  course it is just a split-secret security.
>  > Parts of the secret are in a file, others
>  in the application.
>  > An attacker would
>  need to gather
>  > * the master.hash
>  file
>  > * the application (or at least the
>  masterSalt text or algorithm)
>  > * the
>  encrypted date (Database etc).
>  >
>  > So he actually needs quite some access
>  already!
>  > This is surely better than a
>  cleartext password stored in the database
>  > which everyone could see.
>  >
>  > But of course, once
>  an attacker comes over the debug port, etc - then ALL
>  > security is gone.
>  > I
>  think our approach is not much behing Hashicorp Vault in
>  that regard
>  > (you could btw also gather
>  parts of the secret from a remote box in your
>  > code).
>  > After all the
>  ONLY secure system is if you have a HSM (a hardware
>  security
>  > device) which has it's OWN
>  pin entry (!) AND you only access the
>  >
>  information via a consumable 1-time security token.
>  > But as long as e.g. the database is just
>  secured with a static text
>  >
>  (username/password) then everything else is mathematically
>  breakable.
>  >
>  > Still
>  there is imo a HUGE difference between a cleartext password
>  and a
>  > split-secret approach.
>  >
>
>  Nop, not
>  theorically. I understand it feels different, kind of
>  "oh a
>  password" vs
>  "what's that text?" but if you have accesses
>  to read the clear
>  password then the
>  encrypted one is as easy to get. All this security relies
>  on the local access (which gives you access to
>  the files, db etc...), all
>  other things put
>  around is cosmetic to make people comfortable with it.
>  More it is split longer it will be to get but
>  since the algo is predictable
>  then not more
>  secured until you rotate the strategy very often, like
>  each
>  minute.
>
>
>  >
>  > LieGrue,
>  > strub
>  >
>  > > Am 12.05.2017 um 13:06 schrieb Romain
>  Manni-Bucau   > >:
>  > >
>  > > I think until we support a hsm
>  strategy- which relies on infra more than
>  > > encryption - we can just put it all
>  in clear, security level will be 1-1.
>  >
>  > So IMHO it is really "do people feel more
>  comfortable with unclear text
>  > > even
>  if it is as secured as clear text". If we start to go
>  until "if I'm
>  > in
>  > > the app" then the security is
>  compromished anyway even if it is sha
>  >
>  etc...
>  > >
>  > >
>  So concretely I think it is fine but if the proposed action
>  is just to
>  > move
>  >
>  > to sha-256 or another impl it doesnt hurt much to do,
>  if the action is
>  > more
>  > > impacting like creating 1000 files of
>  1M with a very specific stratégy to
>  >
>  > read a byte in each of them depending the file
>  timestamp and jumping on a
>  > > leg
>  I'm not sure it does worth it since the assumption to
>  access the
>  > clear
>  >
>  > password is exactly the same as having it in clear.
>  > >
>  > > makes
>

Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

Well, plain masterpassword in some file -> shared secret between DB and file 
system.
encrypted masterpwd in some file + application token -> shared secret between 
DB, file system, application, + + +. The app could literally pull it from 
anywhere, including a remote system like vault.
So it's surely not worse than the plain pwd option. 

If one doesn't want to leverage a more dynymic token then just use a static 
string in your app and be done. 

LieGrue,
strub


> Am 12.05.2017 um 15:11 schrieb Romain Manni-Bucau :
> 
> sure, point is master key in clear or not doesnt change anything. Security of 
> such a system is only guaranteed by the split of the master key and the 
> encrypted value but when you have both at the same location security is not 
> more a question.
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> 
> 2017-05-12 13:50 GMT+02:00 Mark Struberg :
> With your take even pgp is unsecure!
> 
> Because if you can get the private key file AND you know the password, then 
> you can encrypted everything.
> 
> Ofc there is no absolute security, but given enough chained steps which are 
> cryptographically strong in itself makes it still so much better than 
> plaintext.
> 
> LieGrue,
> Strub
> 
> 
> 
> ------------
> On Fri, 12/5/17, Romain Manni-Bucau  wrote:
> 
>  Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client 
> encryption handling
>  To: "dev@deltaspike.apache.org" 
>  Date: Friday, 12 May, 2017, 13:28
> 
>  2017-05-12 13:16 GMT+02:00 Mark
>  Struberg :
> 
>  > Well, not 100%
>  d'accord.
>  >
>  > Of
>  course it is just a split-secret security.
>  > Parts of the secret are in a file, others
>  in the application.
>  > An attacker would
>  need to gather
>  > * the master.hash
>  file
>  > * the application (or at least the
>  masterSalt text or algorithm)
>  > * the
>  encrypted date (Database etc).
>  >
>  > So he actually needs quite some access
>  already!
>  > This is surely better than a
>  cleartext password stored in the database
>  > which everyone could see.
>  >
>  > But of course, once
>  an attacker comes over the debug port, etc - then ALL
>  > security is gone.
>  > I
>  think our approach is not much behing Hashicorp Vault in
>  that regard
>  > (you could btw also gather
>  parts of the secret from a remote box in your
>  > code).
>  > After all the
>  ONLY secure system is if you have a HSM (a hardware
>  security
>  > device) which has it's OWN
>  pin entry (!) AND you only access the
>  >
>  information via a consumable 1-time security token.
>  > But as long as e.g. the database is just
>  secured with a static text
>  >
>  (username/password) then everything else is mathematically
>  breakable.
>  >
>  > Still
>  there is imo a HUGE difference between a cleartext password
>  and a
>  > split-secret approach.
>  >
> 
>  Nop, not
>  theorically. I understand it feels different, kind of
>  "oh a
>  password" vs
>  "what's that text?" but if you have accesses
>  to read the clear
>  password then the
>  encrypted one is as easy to get. All this security relies
>  on the local access (which gives you access to
>  the files, db etc...), all
>  other things put
>  around is cosmetic to make people comfortable with it.
>  More it is split longer it will be to get but
>  since the algo is predictable
>  then not more
>  secured until you rotate the strategy very often, like
>  each
>  minute.
> 
> 
>  >
>  > LieGrue,
>  > strub
>  >
>  > > Am 12.05.2017 um 13:06 schrieb Romain
>  Manni-Bucau   > >:
>  > >
>  > > I think until we support a hsm
>  strategy- which relies on infra more than
>  > > encryption - we can just put it all
>  in clear, security level will be 1-1.
>  >
>  > So IMHO it is really "do people feel more
>  comfortable with unclear text
>  > > even
>  if it is as secured as clear text". If we start to go
>  until "if I'm
>  > in
>  > > the app" then the security is
>  compromished anyway even if it is sha
>  >
>  etc...
>  > >
>  > >
>  So concretely I think it is fine but if the proposed action
>  is just to
>  > move
>  >
>  > to sha-256 or another impl it doesnt hurt much to do,
>  if the action is
>  > more
>  > > impacting like creating 1000 files of
>  1M with a v