Assurance

["Joe St Sauver" <>]

Russ commented:

#One issue with password credentials is the possibility of brute force 
password
#attacks from the Internet. 

Interesting data on that, at least in the context of sshd:

-- Whitepaper: http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html
-- Usernames and passwords seen:
   http://www.dragonresearchgroup.org/insight/sshpwauth-cloud.html
-- Sources (IP addresses with timestamps and ASNs) seen conducting ssh 
attacks:
   http://www.dragonresearchgroup.org/insight/sshpwauth.txt

Brute force attacks *do* remain a very real issue today.

#The password policies in InCommon Silver/Bronze
#mitigate the security risk but leave institutions open to possibility of 
#denial of service from the Internet due to lockout or temporary suspension 
#rules if the institution has a large number of services exposed to the 
#internet. 

Practically, I've always been a fan of OpenVMS's handling of brute force
attacks: it pioneered the concept of temporarily ignoring continued brute 
force attempts from a *particular source IP*, while not locking out 
legitimate users attempting to connect from some *other* IP address. 

[Yes, I know that OpenVMS isn't in the mainstream of modern operating 
system deployment, I'm just saying that it got some very subtle things 
very right, and that even includes attacks attempting to leverage large 
numbers of bots.]

I'd also suggest that while rate limiting and lockout policies were 
often carefully enforced when access was largely shell based, my 
suspicion is that many distributed services (such as SMTP Submit on 
Port 587) may NOT correctly rate limit and handle lockouts in the
face of brute force attacks, or if they do, they may do so strictly 
"locally" (e.g., for that service only) rather than sharing that 
"defensive posture" information with other services (such as IMAPS
or sshd) in a collaborative way. 

For example, if you had an anti-brute forcing rule that said 10 
failed logins over the course of an hour would be sufficient to 
trigger that rule, I'm not sure 5 failures on SMTP Submit plus
5 more failures on some other service would result in that rule 
firing for all Internet-exposed services (but I'd love to be 
pleasantly surprised :-)).

#We have seen very high rates of attacks on common usernames 
#such as "david". 

"david"'s one of the widely seen usernames mentioned in the DRG visualization
mentioned above, so I can certainly believe that particular ID is/will be
hammered, absolutely.

#Brute force attacks may be less likely or at least a different issue with
#two-factor. 

Given sufficiently long and complex passwords, and assuming denial of 
service considerations are handled appropriately, and assuming that 
other issues (such as transmission of credentials in plain text isn't
an issue, and malware infestations on the end systems isn't an issue) 
I'm not sure that username and password need be less resistent to 
*brute force* attacks than two-factor authentication.

Regards,

Joe