Cryptography and D

[Rikki Cattermole via Digitalmars-d]

On 6/07/2014 6:06 a.m., 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?
>
>> 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
>
> And, by default, it will error out (at compile-time whenever possible)
> if the application code attempts to use any such algorithm:
>
>    https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L169
>
> Getting around the error requires acknowledging your intent via
> -version=DAuth_AllowWeakSecurity
>
> 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.
>
> Obviously there are natural limits to these measures, so it can't
> *guarantee* anything, only help guide the application developer. And it
> doesn't/can't address all possible issues. But it's at least something.

For reference, Cmsed's password authentication that is built in will 
automatically hash passwords and will not store in any way the plain 
text version [0].
Also supports upgrading hashes as needed. From older algorithms to newer 
preferred ones.

[0] 
https://github.com/rikkimax/Cmsed/blob/master/source/user/cmsed/user/models/userauth.d#L57