Skip site navigation (1) Skip section navigation (2)

Re: Password security question

From: mlw <pgsql(at)mohawksoft(dot)com>
To: Greg Copeland <greg(at)copelandconsulting(dot)net>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Password security question
Date: 2002-12-17 18:30:21
Message-ID: 3DFF6D3D.4010606@mohawksoft.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers

Greg Copeland wrote:

>On Tue, 2002-12-17 at 10:49, mlw wrote:
>  
>
>>Christopher Kings-Lynne wrote:
>>
>>    
>>
>>>Hi guys,
>>>
>>>Just a thought - do we explicitly wipe password strings from RAM after using
>>>them?
>>>
>>>I just read an article (by MS in fact) that illustrates a cute problem.
>>>Imagine you memset the password to zeros after using it.  There is a good
>>>chance that the compiler will simply remove the memset from the object code
>>>as it will seem like it can be optimised away...
>>>
>>>Just wondering...
>>>
>>>Chris
>>> 
>>>
>>>      
>>>
>>Could you post that link? That seems wrong, an explicit memset certainly 
>>changes the operation of the code, and thus should not be optimized away.
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>
>I'd like to see the link too.
>
>I can imagine that it would be possible for it to optimize it away if
>there wasn't an additional read/write access which followed.  In other
>words, why do what is more or less a no-op if it's never accessed again.
>  
>
It has been my experience that the MSC optimizer uses a patented 
Heisenberg optimizer. :)

>
>  
>



In response to

pgsql-hackers by date

Next:From: Matthew KirkwoodDate: 2002-12-17 18:38:11
Subject: Re: Suggestion; "WITH VACUUM" option
Previous:From: mlwDate: 2002-12-17 18:26:12
Subject: Re: Password security question

pgsql-committers by date

Next:From: Tom LaneDate: 2002-12-18 00:14:25
Subject: pgsql-server/src/backend/executor nodeIndexscan.c
Previous:From: mlwDate: 2002-12-17 18:26:12
Subject: Re: Password security question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group