[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Password Lengths


> Does this gives you as much additional security as you would expect??
	Perhaps I should clarify. 
     This is not some scheme i have just dreamed up. This is the scheme 
   I need to implement to get my systems to cluster with Digital UNIX 
   systems running C2 security. Although Digital C2 security allows you 
   a choice of password encryption methods (theoretically), in practice
   everyone appears to be using the default as shipped, which is the 
   bigcrypt() function I described (a.k.a. algorithm 0 in DECspeak). 
   The description may be flawed, as it is not the result of reading 
   any official DEC documentation, but more due to "experimentation".

> 	0123456701234567
> You would get 2 identical crypt strings (possibly with different salts and 
> so different results, but basically the same with no perturbation of the 
> password segments by one another).
	Not quite. The first encrypted block is used to provide the 
    salt for the second. i,e.  cyphertext[p] => salt[p+1]
> Without going into serious theory (meaning my books are out on loan and I 
> am no crypto expert), it would appear to me that you are buying yourself 
> considerably less than it may otherwise appear since you can crack 
> passwords in 8 character chunks in parallel, and the full scale dictionary 
> crack (take a few CDs with all possible crypt results) has got no more 
> difficult.

	Hmm, Suppose you have 4 chunks. (Suppose the password is a dictionary
   word like "antidisestablishmentarianism"). As for a standard crypt regime,
   you know the initial salt, and so you can search the dictionary by using
   foreach (word)  strcmp(pw->pw_passwd,crypt(word,pw->pw_passwd)) /*(c-shell)*/
   until you find a match. One could just replace crypt by bigcrypt()
   here, but the space to search has expanded to 4*8 cleartext characters.
    The salt for each chunk depends on the results of the encryption of the
   previous chunk. So parallelism at the chunk level is lost, unless you 
   search the salt space too. For the above example, you will need 4 crypt()'s
   in a row, with the salt for each depending on the previous crypt() return.
    Maybe I am missing something, but I dont see much  scope for a parallel
   attack there. 
      However, I didnt design it :-). I agree it is probably not very 
   mathematically secure, but then, I'm not an expert on this by any means,
   being just a humble rocket scientist. 
    I consider the weakness in this to be that you know, to the nearest 8 
   characters, how long the plaintext password is, and can skew the search of
   the cleartext space appropriately. There are few words in english that 
   have that many letters. The up side is that users are unlikely to choose
   dictionary words, but will use phrases instead (We apply a minimum
   password length limit of 8 characters or more to users here). 
> Why not go straight for an MD5 or SHA based password scheme - gets you 
> more bits and better handling of long passwords.
        Im my case this is what our central servers are using. If anyone else
    can benefit from this, then I'm more than happy to help them out. I 
    am using MD5 passwords on our linux based firewall, and consider them
    more secure. However this scheme does have the advantage of 
    backwards compatability. 

> [            Friends don't let friends use sendmail!              ]
			 Don't mock, This is what provides my job security. :-)
atp@mssly1.mssl.ucl.ac.uk 		  	  Andy Phillips
atp@mssl.ucl.ac.uk 			Mullard Space Science Laboratory, 
phillips@isass1.solar.isas.ac.jp	 Dept. Space and Climate Physics,
mssly1::atp				    University College London.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []