silly password restrictions was:Re: [clug] secure remote access method

[Robert Edwards]

jm wrote:
> 
> 
> Thanks for forking the subject. This is really a separate line of 
> thought on a related topic.
> 
> I think the best solution is fast becoming one time passwords (OTP). To 
> date this hasn't been an option for most due to the cost of the 
> associated hardware. Things such as yubico help. A better way may lie in 
> the use of software on phones. Phones that support third party software 
> and which are open to easy development are becoming more common (eg, 
> iphone, android, etc) among the target user population. I can see having 
> an application on the phone which would work something like this,
> 
> 1) you log into a remote server from your client machine
> 2) as part of the login process the server issues a challenge code
> 3) you enter the challenge code in to the application on the phone
> 4) based on various factors including a secret key and the time it 
> generates a response.
> 5) you enter the response on the client machine
> 6) you are logged in.
> 
> While some may dwell on the possibility of your phone being hack, stolen 
> , etc it is several orders of magnitude better than port knocking or 
> having bezare password rules. Also, being purely software it is cheaper 
> than those RSA fobs that you see on peoples key chains and less obvious 
> what it is. This last point has to be good from a security stand point 
> as well.
> 
> A rough sketch of the algorithm may be something like this, from the 
> server side,
> 
> # chars available on client
> Secret = "Shh!"
> AvailableChars = [a..z, 0..9]
> EntropyRequired = 12  #bits
> TimeFrame=2 # how many minutes either side of current time to allow
> Len = 6 # length of response
> Challenge = choose_random_characters(AvailableChars, EntropyRequired)
> send_challenge(Challenge)
> Response = get_response()
> check_response(TimeFrame, now(), Secret, Challenge, Response, Len)
> 
> 
> define check_response(TimeFrame, Now, Secret, Challenge, Response, Len)
>  for T = Now - TimeFrame to Now + timeFrame do
>      CorrectAnswer = calculate_response(Secret, T, Challenge, Len)
>      if Response == CorrectResponse
>         return allow_login
>  # end of loop
>  return failed
> 
> define calculate(Secret, T, Challenge, Len)
>   WhiteChallenge = whiten(Challenge)
>   WhiteTime = whiten(T)
>   WhiteSecret = whiten(Secret)
>    Hashed = hash(WhiteChallenge + WhiteTime + WhiteSecret)
>    return cut(Hash, Len)
> 
> There's a fare bit of handwaving in the above mostly to do with type 
> conversions and conversion from one set of units to another. The 
> mistakes are free of charge :-).
> 
> Anyone know of any published algorithms, papers, existing software?
> 
> Jeff.
> 

How does http://otp-j2me.sourceforge.net/ suit?

Cheers,

Bob Edwards.

> Steve McInerney wrote:
>> On Fri, 2009-06-19 at 22:34 +1000, Daniel Pittman wrote:
>>  
>>> Heck, recently a group of very, very technical people I was around had a
>>> discussion about a password system that required a password change 
>>> every week,
>>> no reuse for 128 passwords[1], minimum length above 20 characters, 
>>> characters
>>> from all the standard classes[2], no dictionary words, and no more 
>>> than three
>>> characters in sequence from any one class.
>>>
>>> Which was *still* vulnerable to a fairly trivial "rotate the number" 
>>> guessable
>>> sequence of passwords, and which still left plenty of other risks.
>>>     
>>
>> I'd have to hunt a bit to re-dig it up. But some researchers in the UK
>> did a study on password lengths/time to change them and so on. Was a few
>> years ago now. ~ 2000-2005 time frame.
>>
>>