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:[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/
