Home : News : Blog : All
Anakam Blog - All
Insights into Authentication, Identity Management and Trusted Access
Monday, August 23, 2010

Password Policies and Identity Security
by Anna Slomovic, Anakam CPO

Two interesting studies of password strength were published in the past couple of months. Microsoft researchers Dinei Florêncio and Cormac Herley published “Where Do Security Policies Come From?”, in which they examine password policies of 75 different Web sites in order to understand the diversity of password requirements on those sites. Joseph Bonneau and Sören Preibusch, researchers at the University of Cambridge, published “The Password Thicket: Technical and Market Failures in Human Authentication on the Web,” in which they examined 150 web sites with free user accounts that require passwords in order to understand technical variations in password implementations.

National Institute of Standards and Technology (NIST) Special Publication SP 800-63-1 discusses password strength in terms of “guessing entropy.” This is the degree of difficulty that an attacker would have in guessing a password and impersonating a user. NIST recommends different password strengths for Level 2 authentication, depending on how long a user may keep a password before changing it and how long a user must wait after three failures before trying again. For example, if a web site’s policy is to permit re-try after one minute and to allow users to keep their passwords for five years, a password would need 37 bits of entropy to qualify as Level 2. However, if a password must be changed every 90 days and a user must wait a full day before trying to log in after three failures, a 22-bit password would provide Level 2 assurance level.

The Microsoft researchers found that password strength varies for different types of sites. They found median password policy strength of 19.9 bits for dot-com sites, 31 bits for banks and other financial institutions, 43.7 for dot-edu sites, and 47.6 for dot-gov sites.  Since many sites examined by the researchers also permit e-mail accounts as user names, the only thing between the attacker and account compromise is the password. The authors attribute the differences in password strength to different competitive pressures on different types of sites. Dot-com sites must compete for customers and want to keep usability high, so they reduce login complexity. Banks, dot-edu and dot-gov sites, by contrast, do not face similar pressures, and in many cases their users have no choice about dealing with them. As a result, such sites are willing to require complex passwords even when such policies lead to somewhat lower usability.

Researchers at Cambridge focus on a somewhat different aspect of password authentication. They note that in spite of security concerns, many users still choose passwords that are easy to guess, write down their passwords and share them with others. They also re-use their passwords on multiple sites (average of five sites per password), and sometimes use the same passwords on sites that do not house sensitive or personal information, like content sites, and ones that do, like financial services sites. The authors believe that what they call low-security sites, i.e., ones that do not house sensitive personal or financial information, use password login as a way to collect marketing information about users or a way to establish a trusted relationship with users, but by doing this they are creating more complexity that users are not able to manage effectively. Since low-security sites do not bear the consequences of password compromise at high-security sites, they have no incentive to implement strong security protections for passwords. In fact, compromise of passwords at low-security sites has led to account compromises at high-security sites, and this dynamic is not changing. The authors are not optimistic either about a change in security practices at low-security sites without some sort of regulatory mandate, or about the willingness of low-security sites to adopt federated identity protocols, which might reduce their ability to gather marketing information.

There is, of course, another approach to password management that would reduce concerns about guessable or shared passwords. Sites that house or provide access to sensitive personal or financial information could implement two-factor authentication with a modality that uses one-time passcodes. This would greatly reduce the sites’ vulnerability to password attacks, particularly attacks involving large numbers of compromised passwords, because guessed or shared passwords will not enable account access without the possession of one-time passcodes.

And what about reduced usability? Although two-factor authentication protocols are becoming more user-friendly, they are and will remain more complex than usernames and passwords. Nevertheless, when users understand that without adequate security they face loss of personal or financial information that might be as traumatic as the loss of a job and would require significant effort to fix, they might welcome spending a little extra time at login.





Thursday, August 5, 2010

The Fine Print Isn't Enough
by Anna Slomovic, Anakam CPO
Installing automated strong authentication linked to potentially risky transactions, like password reset, helps mitigate security risks. Businesses and individuals expect their sensitive information and financial interests to be protected, no matter what the contractual small print says. The Baidu case and others like it tell us that the courts also agree, but good business practices shouldn't wait on the courts for a reading on the minimal effort required. Best practice tells us that protecting your customer's personal information and your own corporate data is the smart thing to do.

Read More




Wednesday, June 23, 2010

Vulnerability Assessment — Do You Know Who Is Accessing Your Data?
by Anna Slomovic, Anakam CPO
Organizations remain accountable for data protection whether their data resides behind corporate firewalls or in the cloud, and regardless of the method by which the data is accessed. Analyzing potential attack vectors related to remote access, identifying vulnerabilities, and implementing solutions to minimize risk of compromise is an essential part of securing systems and networks. The threats and potential vulnerabilities involving credentials used to access corporate networks and view or transact business with corporate data need to be addressed along with more traditional defense assessments.

Read More




Friday, April 2, 2010

Privacy and Consent in Patient Health Information
by Anna Slomovic, Anakam CPO
The growing scale of electronic health information exchange has brought us face-to-face with the question about the extent to which patient should be able to control access to their health information. With paper records patients could decide to not tell one doctor about other doctors they were seeing, or not to tell one doctor what medications were prescribed for them by other doctors. This is being fundamentally changed by the ability to search for electronic health information and then collect and collate it.

Read More




Wednesday, March 10, 2010

Don’t Put the Key Under the Mat – Authentication AND Encryption Working Together
by Anna Slomovic, Anakam CPO
In order to prevent different types of attacks against usernames and passwords, organizations have made the login process more difficult--passwords have become more complex, additional “security questions” have become part of the process, and some organizations have moved toward two-factor authentication either because they are required to do so by regulation or because they find the risk of unauthorized access to be too high for the type of data they house.

Read More




Tuesday, February 16, 2010

Patient Identity and Health IT
by Dr. Bill Braithwaite, Anakam CMO
Having a way to represent the identity of a patient in electronic transactions when the patient is not present is critical. According to the HIPAA Privacy Rule, there are at least 17 data elements that can be used to identify a patient that must be removed before a medical record can be considered ‘de-identified’. It is essential that the data that represents the patient be accurately matched to the person who is the subject of this data across all records about that person.

Read More




Friday, February 12, 2010

Telework and Corporate Security
by Jose Jimenez, Anakam Sr. Director, Health Information Technology
In February 2010, Federal Government offices in Washington, D.C. closed for four days because of an historic snowfall in the Washington-Baltimore region. Last fall, President Obama declared the H1N1 flu pandemic a national emergency. These extreme examples and many other more ordinary ones highlight the importance of teleworking in today’s connected environment.

Read More




Wednesday, February 10, 2010

Secrets and Authentication
by Anna Slomovic, Anakam CPO
Five to ten years ago, little known facts about our lives were widely used for authentication before we were permitted access to sensitive information. Quite often the question was, “What was your mother’s maiden name?” This was a “shared secret” model of authentication. Over time, as more organizations use the same facts in various contexts, “shared secrets” become much less secret.

Read More




Monday, January 25, 2010

Authentication and Electronic Signatures
by Anna Slomovic, Anakam CPO
An interesting court case was recently sent for trial in New York federal court. The case revolves around an appropriate level of authentication for an individual who electronically signed an insurance application.

Read More




Thursday, January 14, 2010

Authenticating Password Re-sets
by Anna Slomovic, Anakam CPO
In the past few days Google has announced that its Gmail system suffered an attack in which the Chinese authorities apparently tried to gain information about activities of human rights activists. In its corporate blog, Google posted information about the attack and about how it is responding. Interestingly, some of the accounts were accessed not through a security breach at Google but through a misuse of Gmail credentials.

Read More




12
Anakam Blog
return
Policy
Technical
Product Demo
Want to learn more about our products in the Anakam Identity Suite®? Request an online demo or contact us directly at (888) 826-2526.
Product Demo
RSSSubscribe to this blog
Enter your email address:



Delivered by FeedBurner
Blogroll