You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2013/01/10 10:01:21 UTC
Re: Support for encrypted schema attributes
On 09/01/2013 19:37, Denis Signoretto wrote:
> [...]
> I agree with Fabio, probably this feature it's not so useful in most of common cases.
> I was imagining a general use cases where some user attributes, for security reasons
> or law restrictons, can't be stored cleartext; e.g. a sort of sencondary password or
> a PIN to use for instance to open doors or to enable a payment (some online banking
> use a secondary PIN to confirm a payment operation).
Hi all,
let me summarize the requirements of this new "Encrypted Schema" (for
what I have understood from recent e-mails).
1. Main purpose: store some arbitrary string values encrypted in the
database; this can be enforced by law, for example.
2. When defining an encrypted schema, you must provide the cypher
algorithm to be used and a passphrase.
Such passphrase will be stored by Syncope as encrypted with an internal
key (more or less like we are already doing with user passwords).
3. When creating an attribute with such schema, the value(s) will be
automatically encrypted by Syncope using the provided algorithm and
passphrase.
4. When reading an attribute with such schema (e.g. contained in an
AttributeTO), the value(s) will be sent encrypted.
Only who knows the algorithm and the passphrase will be able to decrypt.
Moreover, you can think to make the admin console able to show such
attribute value(s) as encrypted by default and to decrypt them on demand
after asking for algorithm and passphase.
5. When propagating / synchronizing attribute with such schema,
GuardedString will be used, not String.
6. When changing algorithm or passpshase of an existing schema, new
values will be encrypted with these, old values will remain as they are.
Naturally, one can provide an update procedure.
Does it sound reasonable? If so I will open an issue for this.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Support for encrypted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/01/2013 11:48, Andrei Shakirin wrote:
> Sounds reasonable for me, two additional questions:
>
> 1) Does it make sense optionally to support storing only hash value of passphrase and not passphrase itself?
Yes, definitely: in the summary below, this is implied when you selected
an hashing algorithm.
> 2) Any plans to store X509 certificates?
Yes, again: check SYNCOPE-123 (and related e-mail thread).
Regards.
>> -----Original Message-----
>> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
>> Sent: Donnerstag, 10. Januar 2013 10:01
>> To: dev@syncope.apache.org
>> Subject: Re: Support for encrypted schema attributes
>>
>> On 09/01/2013 19:37, Denis Signoretto wrote:
>>> [...]
>>> I agree with Fabio, probably this feature it's not so useful in most of
>> common cases.
>>> I was imagining a general use cases where some user attributes, for
>>> security reasons or law restrictons, can't be stored cleartext; e.g. a
>>> sort of sencondary password or a PIN to use for instance to open doors
>>> or to enable a payment (some online banking use a secondary PIN to
>> confirm a payment operation).
>>
>> Hi all,
>> let me summarize the requirements of this new "Encrypted Schema" (for
>> what I have understood from recent e-mails).
>>
>> 1. Main purpose: store some arbitrary string values encrypted in the
>> database; this can be enforced by law, for example.
>>
>> 2. When defining an encrypted schema, you must provide the cypher
>> algorithm to be used and a passphrase.
>> Such passphrase will be stored by Syncope as encrypted with an internal key
>> (more or less like we are already doing with user passwords).
>>
>> 3. When creating an attribute with such schema, the value(s) will be
>> automatically encrypted by Syncope using the provided algorithm and
>> passphrase.
>>
>> 4. When reading an attribute with such schema (e.g. contained in an
>> AttributeTO), the value(s) will be sent encrypted.
>> Only who knows the algorithm and the passphrase will be able to decrypt.
>> Moreover, you can think to make the admin console able to show such
>> attribute value(s) as encrypted by default and to decrypt them on demand
>> after asking for algorithm and passphase.
>>
>> 5. When propagating / synchronizing attribute with such schema,
>> GuardedString will be used, not String.
>>
>> 6. When changing algorithm or passpshase of an existing schema, new values
>> will be encrypted with these, old values will remain as they are.
>> Naturally, one can provide an update procedure.
>>
>> Does it sound reasonable? If so I will open an issue for this.
>>
>> Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: Support for encrypted schema attributes
Posted by Andrei Shakirin <as...@talend.com>.
Sounds reasonable for me, two additional questions:
1) Does it make sense optionally to support storing only hash value of passphrase and not passphrase itself?
2) Any plans to store X509 certificates?
Regards,
Andrei.
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Sent: Donnerstag, 10. Januar 2013 10:01
> To: dev@syncope.apache.org
> Subject: Re: Support for encrypted schema attributes
>
> On 09/01/2013 19:37, Denis Signoretto wrote:
> > [...]
> > I agree with Fabio, probably this feature it's not so useful in most of
> common cases.
> > I was imagining a general use cases where some user attributes, for
> > security reasons or law restrictons, can't be stored cleartext; e.g. a
> > sort of sencondary password or a PIN to use for instance to open doors
> > or to enable a payment (some online banking use a secondary PIN to
> confirm a payment operation).
>
> Hi all,
> let me summarize the requirements of this new "Encrypted Schema" (for
> what I have understood from recent e-mails).
>
> 1. Main purpose: store some arbitrary string values encrypted in the
> database; this can be enforced by law, for example.
>
> 2. When defining an encrypted schema, you must provide the cypher
> algorithm to be used and a passphrase.
> Such passphrase will be stored by Syncope as encrypted with an internal key
> (more or less like we are already doing with user passwords).
>
> 3. When creating an attribute with such schema, the value(s) will be
> automatically encrypted by Syncope using the provided algorithm and
> passphrase.
>
> 4. When reading an attribute with such schema (e.g. contained in an
> AttributeTO), the value(s) will be sent encrypted.
> Only who knows the algorithm and the passphrase will be able to decrypt.
> Moreover, you can think to make the admin console able to show such
> attribute value(s) as encrypted by default and to decrypt them on demand
> after asking for algorithm and passphase.
>
> 5. When propagating / synchronizing attribute with such schema,
> GuardedString will be used, not String.
>
> 6. When changing algorithm or passpshase of an existing schema, new values
> will be encrypted with these, old values will remain as they are.
> Naturally, one can provide an update procedure.
>
> Does it sound reasonable? If so I will open an issue for this.
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Re: Support for encrypted schema attributes
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 10/gen/2013, alle ore 10.01, Francesco Chicchiriccò ha scritto:
> On 09/01/2013 19:37, Denis Signoretto wrote:
>> [...]
>> I agree with Fabio, probably this feature it's not so useful in most of common cases.
>> I was imagining a general use cases where some user attributes, for security reasons
>> or law restrictons, can't be stored cleartext; e.g. a sort of sencondary password or
>> a PIN to use for instance to open doors or to enable a payment (some online banking
>> use a secondary PIN to confirm a payment operation).
>
> Hi all,
> let me summarize the requirements of this new "Encrypted Schema" (for what I have understood from recent e-mails).
>
> 1. Main purpose: store some arbitrary string values encrypted in the database; this can be enforced by law, for example.
>
> 2. When defining an encrypted schema, you must provide the cypher algorithm to be used and a passphrase.
> Such passphrase will be stored by Syncope as encrypted with an internal key (more or less like we are already doing with user passwords).
>
> 3. When creating an attribute with such schema, the value(s) will be automatically encrypted by Syncope using the provided algorithm and passphrase.
>
> 4. When reading an attribute with such schema (e.g. contained in an AttributeTO), the value(s) will be sent encrypted.
> Only who knows the algorithm and the passphrase will be able to decrypt.
> Moreover, you can think to make the admin console able to show such attribute value(s) as encrypted by default and to decrypt them on demand after asking for algorithm and passphase.
>
> 5. When propagating / synchronizing attribute with such schema, GuardedString will be used, not String.
>
> 6. When changing algorithm or passpshase of an existing schema, new values will be encrypted with these, old values will remain as they are. Naturally, one can provide an update procedure.
>
> Does it sound reasonable? If so I will open an issue for this.
Absolutely reasonable!
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>
Re: Support for encrypted schema attributes
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 10/01/2013 10:40, ernst Developer wrote:
> Hi Francesco,
> The list of requirements sounds reasonable. I have another question: where
> does Syncope store the encryption key?
Hi Ernst,
for user passwords - and as I wrote below, I am proposing to do the same
with passphrase encryption - the encryption key is barely and statically
defined in source code [1] for 1_0_X, [2] for trunk.
I haven't realized so far how this is bad: I'll open immediately an issue.
Regards.
[1]
http://svn.apache.org/repos/asf/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/persistence/beans/user/SyncopeUser.java
[2]
http://svn.apache.org/repos/asf/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/PasswordEncoder.java
> 2013/1/10 Francesco Chicchiriccò <il...@apache.org>
>
>> On 09/01/2013 19:37, Denis Signoretto wrote:
>>
>>> [...]
>>> I agree with Fabio, probably this feature it's not so useful in most of
>>> common cases.
>>> I was imagining a general use cases where some user attributes, for
>>> security reasons
>>> or law restrictons, can't be stored cleartext; e.g. a sort of sencondary
>>> password or
>>> a PIN to use for instance to open doors or to enable a payment (some
>>> online banking
>>> use a secondary PIN to confirm a payment operation).
>>>
>> Hi all,
>> let me summarize the requirements of this new "Encrypted Schema" (for what
>> I have understood from recent e-mails).
>>
>> 1. Main purpose: store some arbitrary string values encrypted in the
>> database; this can be enforced by law, for example.
>>
>> 2. When defining an encrypted schema, you must provide the cypher
>> algorithm to be used and a passphrase.
>> Such passphrase will be stored by Syncope as encrypted with an internal
>> key (more or less like we are already doing with user passwords).
>>
>> 3. When creating an attribute with such schema, the value(s) will be
>> automatically encrypted by Syncope using the provided algorithm and
>> passphrase.
>>
>> 4. When reading an attribute with such schema (e.g. contained in an
>> AttributeTO), the value(s) will be sent encrypted.
>> Only who knows the algorithm and the passphrase will be able to decrypt.
>> Moreover, you can think to make the admin console able to show such
>> attribute value(s) as encrypted by default and to decrypt them on demand
>> after asking for algorithm and passphase.
>>
>> 5. When propagating / synchronizing attribute with such schema,
>> GuardedString will be used, not String.
>>
>> 6. When changing algorithm or passpshase of an existing schema, new values
>> will be encrypted with these, old values will remain as they are.
>> Naturally, one can provide an update procedure.
>>
>> Does it sound reasonable? If so I will open an issue for this.
>>
>> Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Support for encrypted schema attributes
Posted by ernst Developer <er...@gmail.com>.
Hi Francesco,
The list of requirements sounds reasonable. I have another question: where
does Syncope store the encryption key?
Regards,
Ernst
2013/1/10 Francesco Chicchiriccò <il...@apache.org>
> On 09/01/2013 19:37, Denis Signoretto wrote:
>
>> [...]
>> I agree with Fabio, probably this feature it's not so useful in most of
>> common cases.
>> I was imagining a general use cases where some user attributes, for
>> security reasons
>> or law restrictons, can't be stored cleartext; e.g. a sort of sencondary
>> password or
>> a PIN to use for instance to open doors or to enable a payment (some
>> online banking
>> use a secondary PIN to confirm a payment operation).
>>
>
> Hi all,
> let me summarize the requirements of this new "Encrypted Schema" (for what
> I have understood from recent e-mails).
>
> 1. Main purpose: store some arbitrary string values encrypted in the
> database; this can be enforced by law, for example.
>
> 2. When defining an encrypted schema, you must provide the cypher
> algorithm to be used and a passphrase.
> Such passphrase will be stored by Syncope as encrypted with an internal
> key (more or less like we are already doing with user passwords).
>
> 3. When creating an attribute with such schema, the value(s) will be
> automatically encrypted by Syncope using the provided algorithm and
> passphrase.
>
> 4. When reading an attribute with such schema (e.g. contained in an
> AttributeTO), the value(s) will be sent encrypted.
> Only who knows the algorithm and the passphrase will be able to decrypt.
> Moreover, you can think to make the admin console able to show such
> attribute value(s) as encrypted by default and to decrypt them on demand
> after asking for algorithm and passphase.
>
> 5. When propagating / synchronizing attribute with such schema,
> GuardedString will be used, not String.
>
> 6. When changing algorithm or passpshase of an existing schema, new values
> will be encrypted with these, old values will remain as they are.
> Naturally, one can provide an update procedure.
>
> Does it sound reasonable? If so I will open an issue for this.
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>
R: Support for encrypted schema attributes
Posted by Denis Signoretto <de...@intesys.it>.
+1
Agree with Jan. Nice summary :)
Regards.
Denis
> -----Messaggio originale-----
> Da: Jan Bernhardt [mailto:jbernhardt@talend.com]
> Inviato: giovedì 10 gennaio 2013 11:24
> A: dev@syncope.apache.org
> Oggetto: RE: Support for encrypted schema attributes
>
>
> +1
> Nice summary!
>
> Regards.
> Jan
>
> > -----Original Message-----
> > From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> > Sent: Donnerstag, 10. Januar 2013 10:01
> > To: dev@syncope.apache.org
> > Subject: Re: Support for encrypted schema attributes
> >
> > On 09/01/2013 19:37, Denis Signoretto wrote:
> > > [...]
> > > I agree with Fabio, probably this feature it's not so
> useful in most of
> > common cases.
> > > I was imagining a general use cases where some user
> attributes, for
> > > security reasons or law restrictons, can't be stored
> cleartext; e.g. a
> > > sort of sencondary password or a PIN to use for instance
> to open doors
> > > or to enable a payment (some online banking use a secondary PIN to
> > confirm a payment operation).
> >
> > Hi all,
> > let me summarize the requirements of this new "Encrypted
> Schema" (for
> > what I have understood from recent e-mails).
> >
> > 1. Main purpose: store some arbitrary string values encrypted in the
> > database; this can be enforced by law, for example.
> >
> > 2. When defining an encrypted schema, you must provide the cypher
> > algorithm to be used and a passphrase.
> > Such passphrase will be stored by Syncope as encrypted with
> an internal key
> > (more or less like we are already doing with user passwords).
> >
> > 3. When creating an attribute with such schema, the value(s) will be
> > automatically encrypted by Syncope using the provided algorithm and
> > passphrase.
> >
> > 4. When reading an attribute with such schema (e.g. contained in an
> > AttributeTO), the value(s) will be sent encrypted.
> > Only who knows the algorithm and the passphrase will be
> able to decrypt.
> > Moreover, you can think to make the admin console able to show such
> > attribute value(s) as encrypted by default and to decrypt
> them on demand
> > after asking for algorithm and passphase.
> >
> > 5. When propagating / synchronizing attribute with such schema,
> > GuardedString will be used, not String.
> >
> > 6. When changing algorithm or passpshase of an existing
> schema, new values
> > will be encrypted with these, old values will remain as they are.
> > Naturally, one can provide an update procedure.
> >
> > Does it sound reasonable? If so I will open an issue for this.
> >
> > Regards.
> >
> > --
> > Francesco Chicchiriccò
> >
> > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> > http://people.apache.org/~ilgrosso/
>
>
RE: Support for encrypted schema attributes
Posted by Jan Bernhardt <jb...@talend.com>.
+1
Nice summary!
Regards.
Jan
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Sent: Donnerstag, 10. Januar 2013 10:01
> To: dev@syncope.apache.org
> Subject: Re: Support for encrypted schema attributes
>
> On 09/01/2013 19:37, Denis Signoretto wrote:
> > [...]
> > I agree with Fabio, probably this feature it's not so useful in most of
> common cases.
> > I was imagining a general use cases where some user attributes, for
> > security reasons or law restrictons, can't be stored cleartext; e.g. a
> > sort of sencondary password or a PIN to use for instance to open doors
> > or to enable a payment (some online banking use a secondary PIN to
> confirm a payment operation).
>
> Hi all,
> let me summarize the requirements of this new "Encrypted Schema" (for
> what I have understood from recent e-mails).
>
> 1. Main purpose: store some arbitrary string values encrypted in the
> database; this can be enforced by law, for example.
>
> 2. When defining an encrypted schema, you must provide the cypher
> algorithm to be used and a passphrase.
> Such passphrase will be stored by Syncope as encrypted with an internal key
> (more or less like we are already doing with user passwords).
>
> 3. When creating an attribute with such schema, the value(s) will be
> automatically encrypted by Syncope using the provided algorithm and
> passphrase.
>
> 4. When reading an attribute with such schema (e.g. contained in an
> AttributeTO), the value(s) will be sent encrypted.
> Only who knows the algorithm and the passphrase will be able to decrypt.
> Moreover, you can think to make the admin console able to show such
> attribute value(s) as encrypted by default and to decrypt them on demand
> after asking for algorithm and passphase.
>
> 5. When propagating / synchronizing attribute with such schema,
> GuardedString will be used, not String.
>
> 6. When changing algorithm or passpshase of an existing schema, new values
> will be encrypted with these, old values will remain as they are.
> Naturally, one can provide an update procedure.
>
> Does it sound reasonable? If so I will open an issue for this.
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/