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

[jm]

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.

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.
>
>