Cryptography and D

[Nick Sabalausky via Digitalmars-d]

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.