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 <rdebussc...@gmail.com>:
>
> 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) <j...@apache.org> 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)
>>
