Cryptography and D

Nick Sabalausky via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 6 11:36:34 PDT 2014


On 7/6/2014 4:22 AM, Rikki Cattermole wrote:
> On 6/07/2014 6:45 p.m., Nick Sabalausky wrote:
>>
>> The idea behind the auto-zeroing Password type in DAuth: you do your
>> best to give it [hopefully] the one and only copy of the plaintext
>> password data, in mutable form, and DAuth nukes it from memory as soon
>> as it's able to. Not if/when GC kicks in, sweeps it, and reuses it. And
>> not just a copy of the data, but the actual [hopefully] original buffer.
>> Any further attempts (deliberate or accidental) to read that data
>> through any other reference will only receive zeros.
>
> My reasoning is simple. Only upon setting the password for a user will
> the plaintext version ever be in memory or when logging in for
> authentication.
> Now this should be coming as a parameter via routes in some format as a
> string. If this cannot be caught by the GC and cleaned up, how exactly
> does your method help?
>
> So as far as I'm concerned, if it cannot be cleaned up, there are bigger
> problems to worry about then just securing this one tiny piece of code.
>

I wanted to keep the door open for, and help encourage, applications 
that *do* avoid having a password in an immutable buffer.

I realize that your library relies on vibe anyway, so in your case, yes 
this measure wouldn't help without corresponding changes within vibe.d. 
That is a fair point. But DAuth (again, I may want to change the name), 
is designed to be a general-purpose password-based user authentication 
tool, reusable from any sort of program, so that situation/limitation 
doesn't necessarily apply to DAuth.

> Unless of course, we want some method to guard against this e.g. all
> data given to routes in Vibe is actually protected and will be
> forcefully freed upon finishing of the route.
>

That's actually an interesting idea. I had been imagining a possible 
enhancement to vibe that would handle passwords separately, but 
depending on the application, a password isn't necessarily the only 
sensitive data sitting around.



More information about the Digitalmars-d mailing list