[
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021537#comment-16021537
]
ASF subversion and git services commented on DELTASPIKE-1250:
-
Commit
[
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021241#comment-16021241
]
ASF subversion and git services commented on DELTASPIKE-1250:
-
Commit
[
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012091#comment-16012091
]
ASF subversion and git services commented on DELTASPIKE-1250:
-
Commit
[
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
[
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
7, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
>
> Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client
> encryption handling
> To: "dev@deltaspike.apache.org" <dev@deltaspike.apache.org>
> Date: Friday, 12 May, 2017, 13:28
>
>
en 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 <rmannibu...@gmail.com> wrote:
>
plaintext.
LieGrue,
Strub
On Fri, 12/5/17, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
Subject: Re: [jira] [Commented] (DELTASPIKE-1250) create a master/client
encryption handling
To: "dev@deltaspike.apache.org" <dev@deltaspik
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
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
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
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
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
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
[
https://issues.apache.org/jira/browse/DELTASPIKE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006784#comment-16006784
]
Mark Struberg commented on DELTASPIKE-1250:
---
A first design proposal can be found on my
15 matches
Mail list logo