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) <[email protected]> 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)
>
