On 7/6/2014 9:38 AM, Kagamin wrote:
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
Well, of course there are algorithms that *are* inherently insecure at
the algorithmic level, regardless of implementation. Like MD4/MD5,
CRC32, non-crypto DRNGs, etc. But yea, user code is a big giant attack
vector.
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.
Yea, it *is* a calculated compromise. Definitely. It doesn't prevent
anyone from doing the wrong thing since it really *can't* prevent it.
But what it does do is attempt to nudge the user in the right direction
the best it can. Namely, a function is *already* provided to directly
construct a Password struct from a string: dupPassword (as opposed to
the recommended toPassword which requires a mutable char array).
Granted, this dupPassword is a bad thing to use, but just like unsafe
casts, people will occasionally need it or otherwise think they need it.
(Heck, *I've* needed to use it, just because vibe provides its POST vars
in string form.) So by providing this function directly (instead of
omitting dupPassword or just accepting "string password" everywhere),
I'm hoping to:
1. Increase the likelihood people are at least *aware* of what they're
doing: Using a discouraged function (the docs warn about its use) and
"dup"ing a plaintext password that will still remain in memory.
2. Decrease the likelihood of homemade workarounds that may not be as
easily identifiable or greppable.
It's no guarantee of anything, since that's wouldn't be realistic
anyway. But it's a nudge in the right direction, which is the next best
thing.
