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:[email protected]]
Sent: Donnerstag, 10. Januar 2013 10:01
To: [email protected]
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/
