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

[Rudy De Busscher]

I looked up the code which I used recently related to AES.

We used the GCM block mode (as it is the most secure and fast, non-stream
based AES encryption mode.)

Something like

   * Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");*

*byte[] nonce = new byte[GCM_NONCE_LENGTH];*

*random.nextBytes(nonce);  // nonce == IV*

*GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, nonce);*

*cipher.init(Cipher.ENCRYPT_MODE, key, spec);*


problem is that GCM is only available with Java 8 :(

So we can probably stick with the current version (default is
AES/ECB/PKCS5Padding)


Although the idea is to just make things harder than using plain text (And
I agree that although it is not absolute or perfectly secure it is a good
thing) I propose to use SHA-256 instead of the SHA-1 (= indicated as
insecure nowadays) hashing algorithm. Just changing the name is required,
no other changes needed. This makes it harder to guess/break the masterSalt
for example. (key in master.hash file)


A few other small remarks

1) Creation of the deltaspike directory in the user home directory is wrong

line 63  if (!masterFile.mkdirs())  -> if
(!masterFile.getParentFile().mkdirs())

2) Exception message on line 109 should use the masterSalt value (as that
is the value that needs to be used to create an entry in the master.hash
file)


regards

Rudy

On 12 May 2017 at 16:09, Mark Struberg (JIRA)  wrote:

>
>  [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Mark Struberg updated DELTASPIKE-1250:
> --
> Description:
> 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.
>
>   was:
> 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.
>
>
> > 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] [Updated] (DELTASPIKE-1250) create a master/client encryption handling

[Mark Struberg]

Hey Rudy!

Thanks for your feedback!

A colleague who glimpsed over the code also catched the folder bug and 
suggested to use SHA-256. I've upgraded this in my repo already.

I think it's time to push this to our cannonical repo, then you could simply 
apply your changes. Ok?

txs and LieGrue,
strub


> Am 13.05.2017 um 11:30 schrieb Rudy De Busscher :
> 
> I looked up the code which I used recently related to AES.
> 
> We used the GCM block mode (as it is the most secure and fast, non-stream
> based AES encryption mode.)
> 
> Something like
> 
>   * Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");*
> 
> *byte[] nonce = new byte[GCM_NONCE_LENGTH];*
> 
> *random.nextBytes(nonce);  // nonce == IV*
> 
> *GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, nonce);*
> 
> *cipher.init(Cipher.ENCRYPT_MODE, key, spec);*
> 
> 
> problem is that GCM is only available with Java 8 :(
> 
> So we can probably stick with the current version (default is
> AES/ECB/PKCS5Padding)
> 
> 
> Although the idea is to just make things harder than using plain text (And
> I agree that although it is not absolute or perfectly secure it is a good
> thing) I propose to use SHA-256 instead of the SHA-1 (= indicated as
> insecure nowadays) hashing algorithm. Just changing the name is required,
> no other changes needed. This makes it harder to guess/break the masterSalt
> for example. (key in master.hash file)
> 
> 
> A few other small remarks
> 
> 1) Creation of the deltaspike directory in the user home directory is wrong
> 
> line 63  if (!masterFile.mkdirs())  -> if
> (!masterFile.getParentFile().mkdirs())
> 
> 2) Exception message on line 109 should use the masterSalt value (as that
> is the value that needs to be used to create an entry in the master.hash
> file)
> 
> 
> regards
> 
> Rudy
> 
> On 12 May 2017 at 16:09, Mark Struberg (JIRA)  wrote:
> 
>> 
>> [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
>> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>> 
>> Mark Struberg updated DELTASPIKE-1250:
>> --
>>Description:
>> 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.
>> 
>>  was:
>> 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.
>> 
>> 
>>> 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 

[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=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=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)

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

[Mark Struberg]

Regarding the exception.
This is by design not the key used to encrypt but only it's hash (which is used 
as key in the master.hash file). I dint want to print out the encryption key or 
the password anywhere.

Otw any attack would be simple. 

LieGrue,
Strub

> Am 13.05.2017 um 11:30 schrieb Rudy De Busscher :
> 
> I looked up the code which I used recently related to AES.
> 
> We used the GCM block mode (as it is the most secure and fast, non-stream
> based AES encryption mode.)
> 
> Something like
> 
>   * Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");*
> 
> *byte[] nonce = new byte[GCM_NONCE_LENGTH];*
> 
> *random.nextBytes(nonce);  // nonce == IV*
> 
> *GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH, nonce);*
> 
> *cipher.init(Cipher.ENCRYPT_MODE, key, spec);*
> 
> 
> problem is that GCM is only available with Java 8 :(
> 
> So we can probably stick with the current version (default is
> AES/ECB/PKCS5Padding)
> 
> 
> Although the idea is to just make things harder than using plain text (And
> I agree that although it is not absolute or perfectly secure it is a good
> thing) I propose to use SHA-256 instead of the SHA-1 (= indicated as
> insecure nowadays) hashing algorithm. Just changing the name is required,
> no other changes needed. This makes it harder to guess/break the masterSalt
> for example. (key in master.hash file)
> 
> 
> A few other small remarks
> 
> 1) Creation of the deltaspike directory in the user home directory is wrong
> 
> line 63  if (!masterFile.mkdirs())  -> if
> (!masterFile.getParentFile().mkdirs())
> 
> 2) Exception message on line 109 should use the masterSalt value (as that
> is the value that needs to be used to create an entry in the master.hash
> file)
> 
> 
> regards
> 
> Rudy
> 
>> On 12 May 2017 at 16:09, Mark Struberg (JIRA)  wrote:
>> 
>> 
>> [ https://issues.apache.org/jira/browse/DELTASPIKE-1250?
>> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>> 
>> Mark Struberg updated DELTASPIKE-1250:
>> --
>>Description:
>> 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.
>> 
>>  was:
>> 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.
>> 
>> 
>>> 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 

[jira] [Closed] (DELTASPIKE-1243) CrossConversationScoped

[Gerhard Petracek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gerhard Petracek closed DELTASPIKE-1243.

Resolution: Later

please reopen this ticket once there is an agreement on the dev-list.

> CrossConversationScoped
> ---
>
> Key: DELTASPIKE-1243
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1243
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Servlet-Module
>Reporter: Frank Cornelis
>Priority: Minor
>
> This new scope, @CrossConversationScoped, allows you to share beans between 
> two servlet container sessions. The lifecycle of the @CrossConversationScoped 
> beans corresponds with the HTTP session of the creating session. Via a 
> CrossConversationStrategy implementation you can link these beans to a second 
> HTTP client (that is not directly linked to the HTTP session of the first 
> client).
> We use this component to glue together a web browser session with some 
> middleware component that talk to the server outside of the web browser 
> session.
> Source code is available at:
> https://github.com/e-Contract/cdi-cross-conversation
> We've licensed under Apache to make it importable in DeltaSpike if this 
> feature seems interesting enough.
> Arquillian based integration tests are also provided.



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