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ò <[email protected]>
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/
