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