On 10/09/10 4:06 AM, [email protected] wrote:
I understand your point, but I think it's fair to ask "can we do
better?"
Your implication is, "don't try, don't even discuss trying".
I think that's a cop out, intellectually lazy, and boring; but sure,
it avoids the risks associated with any change.
I tend to be one of those who agree with that.
http://iang.org/ssl/h6_its_your_job_do_it.html
However it is complicated. Security work is very tricky, and a lot of
stuff that is done is plain wrong, but is supported to-the-death by its
advocates. So you need to be in for the long run to learn this stuff,
which often means seeing the same discussion about NIST RNGs or
certificates or key lengths over and over again.
And, the people who do feel they know it all get tired and cranky with
newcomers :) Not without cause, because nobody pays them to be here,
and nobody appreciates good expertise delivered quietly. So being
cranky and arrogant is actually good for business. Security business is
very sad, really.
Understandable, testable, safe.
When 25% of your users never log in again, I would add "...for small
values of safe".
Possibly speaking out of turn here, but I designed a similar system once
which had the user-password encrypting the data store for that user.
Nice and elegant, but it hits real world issues like that. The real
world issue I had was "I lost my password, reset it please!" which tends
to be the #1 support problem for password-based systems.
The solution I came up with [1] is to encrypt the data to two keys. One
is the user's password and the other is support's key. The latter can
be offline, like an OpenPGP public key, and therefore subject to
internal governance controls.
iang
[1] which was never implemented, so who knows...
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
