The Center for Education and Research in Information Assurance and Security (CERIAS)

The Center for Education and Research in
Information Assurance and Security (CERIAS)

CERIAS Blog

Page Content

Login with Facebook, Google and LinkedIn

Share:
Is your management considering logins using Facebook, Google or LinkedIn accounts? What are the risks? One consideration is password policies. I experimented to find out what were the effective password policies in place:
SiteMinimum CharactersReuse?Trivial?All lower-case?Expiration
FaceBook6YesNoYesNo
Google8NoNoYesNo
LinkedIn6YesNoYesNo
All 3 prevented the use of trivial passwords such as 123456. However, all accepted a password consisting only of lower-case letters, and none of the services seems to implement password expiration, at least not in a reasonable time frame (1 year or less). Password expiration is necessary to protect against password guessing attacks, because given enough time a slow trickle of systematic attempts will succeed. The weaker the other password requirements and protections (e.g., number of tries allowed/minute) are, the quicker the expiration period should be. In my opinion, all 3 have weak password policies overall. However, if you *must* have a "login with your X account" feature, I suggest using Google's service and not the others, at least when considering only password policies. Google has the best policy by far (potentially thousands of times stronger), with 8 characters and not allowing the re-use of previous passwords.

After 16 login failures, Google presents a captcha. This struck me as a large number, but FaceBook allows an even greater number of attempts before blocking (I lost count). On Facebook, you can continue login attempts simply by clearing the Facebook cookies in the browser, which apparently provides an unlimited number of login attempts and a great weakness towards password guessing attacks. But then, clearing the browser's cookies also bypasses the Google captcha... How disappointing. LinkedIn is the only one that didn't lose track of login attempts by clearing browser cookies or using a different browser; after 12 failed attempts, it required answering a captcha. So, if you must have 2 login services, I would suggest Google and LinkedIn, and to avoid Facebook.

Other considerations, such as the security of the login mechanism and trustworthiness of the service, are not addressed here.

Looking for fail2ban++

Share:
If you're looking for a worthwhile project, here's something that could benefit most security practitioners. The application "fail2ban" has been extremely useful in blocking sources of undesirable behavior such as brute force attacks on password mechanisms, spammers (by hooking it up to your mail server's rejection log), as well as hostile vulnerability scanners. However, it only works for IPv4. Discussions (and patches) I've seen to make it work with IPv6, unfortunately focus on making it understand IPv6 addresses, and miss an important point. With IPv6, entities, even home users, will have large networks at their disposal. As a result, it may be futile to block a single IPv6 address. However, blocking whole IPv6 networks with the same threshold as a single IPv4 user may block legitimate users. I need a program that will work like fail2ban but will allow progressive blocking, as follows: If undesirable behavior is observed from IP addresses within a network of size N past threshold T(N), block the entire network. This would work with multiple network sizes, starting with singleton IPs and scaling up to large networks, with the threshold increasing and being more tolerant the larger the network is. How the threshold changes with the size of the network should be configurable.

A corollary of the above is that when we'll move to IPv6, as some service providers have already done, password strength, and the strength of secrets and applications in general, will have to increase because we will have to be more tolerant of undesirable behavior, until the threshold of the attacker's network size is reached. This will of course be likely a lot more, and at a minimum the same, as what we tolerate on IPv4 for a single address.