On Saturday, 5 July 2014 at 18:06:34 UTC, Nick Sabalausky wrote:
On 7/5/2014 8:23 AM, Kagamin wrote:
There was a study, showing that most security vulnerabilities
are caused
by client code rather than cryptographic library code.
Interesting. Link?
Dunno, can't find it right now. I thought, I found it following
links from hap thread, but there's nothing there.
For example, how
would you prevent client code from generating weak encryption
keys or
from using weak algorithm for hash comparison, or how would
you force it
to do what's not required to get the code compiled? How would
you do
that with the quality of library code? Even if you can do
that, it's
still not a cryptographic task, but a general programming
task, the
standard only hints you that those things are necessary.
FWIW, DAuth (pending a possible name change, to prevent
confusion with the completely unrelated OAuth) maintains a list
of non-recommended algos:
https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L109
Cryptographic algorithms don't cause cryptographic weaknesses as
bad as ones from user code.
Example: http://samate.nist.gov/SRD/view_testcase.php?tID=58
Also, DAuth encourages passwords to be stored in a special
structure:
https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L311
which attempts to zero-out the password from memory as early as
it can (and encourages the user to populate it via char[] not
string to avoid having an un-wipable immutable plain-text copy
in memory. See 'toPassword' vs 'dupPassword'). I'm certain the
implementation can be improved. And I'd kinda like to make it
scoped if I can, instead of refcounted. But it's something.
Yeah, better than nothing, but as it integrates poorly with the
rest of user code, people will hack it around by writing byte[]
hashPassword(string) function. Nobody estimates security by
defending the system, one do it by breaking it.
