Re: lynx-dev Options, V.Links, random (was: patch 6 - UI Pages)

[T.E.Dickey]

> On Wed, 15 Dec 1999, T.E.Dickey wrote: 
>  
> > > Relying on rand() for security is really a bad design choice, IMO.  
> >  
> > otoh, it improved on what was there (addressed the immediate cause for 
> > concern).   
>  
> Yes - slightly, IMO. 
>  
> > I don't believe that any of us can come up with a completely 
> > secure scheme (nor could the critics ;-).   
>  
> Why not?  (I assume we are talking about temp files; for the Options Menu 
> "secret", there really isn't any need for secure secrets to protect against 
> "spoofing" from outside.) 

for the latter, I changed that just-for-completeness.
temp-files is what we're talking about.
  
> Not for all situations of course.  For example, if O_CREAT|O_EXCL is 
> broken in the underlying filesystem, there isn't much we can do about 
> it.  But I am still wondering whether the OpenHiddenFile()/IsOurFile() 
> *is* spoof-proof on a sane system (and I admit I have never tried to 
> completely understand that code - what with the directory traversal and 
> uid check stuff...).  If it isn't secure on a sane system (non-broken 
> filesystem etc.), using rand() may just detract from that fact. 

I don't see how rand() makes it less secure - it doesn't change the checks,
but makes the selection of names less obvious (obviousness was the point of
the criticism).
  
> > However, using a sequential name 
> > opens us up to criticism from people who don't concern themselves over 
> > whether the underlying filesystems itself is secure.   
>  
> If they are wrong and we are right, we shouldn't listen to them. 

easy in principal, hard in practice.
  
> > Using rand() merely 
> > guarantees that the average fool (i.e., "hacker") would not break in. 
>  
> While the skillful fool still may, I assume.  If he knows at which second 
> srand() was called, the sequence of numbers should be completely 
> reproduceable. 

if
  
> Btw, I think 
>  
>     counter = ( 10000.0 * rand() ) / RAND_MAX; 
>  
> should be 
>  
>     counter = ( 10000.0 * rand() ) / (RAND_MAX+1.0); 
>  
> if you always want to have 4 digits or less. 

ok

> Using random numbers for temp filenames opens up a small chance, about 
> one-in-10000, for name collisions.  Therefore a chance for very 

no - we already deal with name collisions (I did check that - it simply
tries the next one on a failure).

> Of course, something like this could also happen with sequential 
> numbering, but *only* in a session that is long enough that the counter 

or with a session that crashes, or happens to use the same numbers as someone
else.

> can wrap around.  In that case it would be easily predictable and easy 
> to diagnose. 
>  
> If a random number component in the filename is really desired - how 
> about using it *in addition* to a straightforward counter.  I.e., 
>    /tmp/L<piddigits>-<randdigits>-<counterdigits>TMP.html 

total length was what I looked at - changing the counter to random used the
same length as before.
  
> (If total length is a problem - 1. "L", "TMP", and hyphens could be 
> done away with [but I prefer to have them, for matching]; 2. Windos/DOS 
> already use a different format anyway and aren't "safe" anyway; 3. the 
> names used now are already above a 14-character limit, so that old 
> limit doesn't seem to matter; 4.  we could use less than 4 digit for 
> <randdigits>.) 
>  
>   Klaus 
>  


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey