Polytechnic University of the Philippines Open University Quezon City Master of Science in Information Technology Project in Advanced Organization of Database Firebird Database Herminiño C. Lagunzad Firebird Database


Password complexity rules more annoying, less effective than lengthy ones



Download 312.53 Kb.
Page6/9
Date24.06.2017
Size312.53 Kb.
#21663
1   2   3   4   5   6   7   8   9

Password complexity rules more annoying, less effective than lengthy ones


By:  Casey Johnston, June 2013
Few Internet frustrations are so familiar as the password restriction. After creating a few (dozen) logins for all our Web presences, the use of symbols, mixed cases, and numbers seems less like a security measure and more like a torture device when it comes to remembering a complex password on a little-used site. But at least that variety of characters keeps you safe, right? As it turns out, there is some contrary research that supports both how frustrating these restrictions are and suggests it’s possible that the positive effect of complexity rules on security may not be as great as long length requirements.

Let's preface this with a reminder: the conventional wisdom is that complexity trumps length every time, and this notion is overwhelmingly true. Every security expert will tell you that “Supercalifragilistic” is less secure than “gj7B!!!bhrdc.” Few password creation schemes will render any password uncrackable, but in general, length does less to guard against crackability than complexity.

A password is not immune from cracking simply by virtue of being long—44,991 passwords recovered from a dump of LinkedIn hashes last year were 16 characters or more. The research we describe below refers specifically to the effects of restrictions placed by administrators on password construction on their crackability. By no means does it suggest that a long password is, by default, more secure than a complex one.

In April, Ars checked in with a few companies that place a range of restrictions on how passwords must be constructed, from Charles Schwab’s 8-character maximum to Evernote’s “use any character but spaces.” Reasons ranged from whether customers can stand typing certain characters with a mobile phone to password-cracking being the last of a company’s concerns compared to phishing or malware.

A pair of studies done in 2011 and 2012 on password length and construction showed two things: first, customer frustration increases significantly with complexity, but less so with length. Second, a number of password cracking algorithms can be more easily thwarted by a long password that is created without number, symbol, or case requirements than are shorter passwords that are required to be complex, particularly for a large number of guesses. That is, shorter, more complex password restrictions beget passwords that can be more frustrating to everyone except the only entity who shouldn’t have it: the password cracker.

The first study in 2011 specifically addressed the problems of usability in password complexity (full disclosure: both studies mentioned in this article were conducted in part by Michelle L. Mazurek, wife of Ars Gaming Editor Kyle Orland). The study authors looked at 12,000 passwords created by participants under a variety of construction methods, including comprehensive8, where passwords must be at least 8 characters and include both an uppercase and lowercase letter, as well as a digit and a symbol, and must not contain dictionary words; basic8, where passwords must be 8 characters with no other restrictions; and basic16, where passwords must be 16 characters with no other restrictions.

Study participants experienced the most difficulty with the comprehensive8 requirements from beginning to end. Only 17.7 percent were able to create a password that met all of the requirements in the first try, compared to well over 50 percent for the rest of the conditions. Twenty-five percent of comprehensive8 testers gave up before they could even make a password that satisfied the requirements, compared to 18.3 percent or less for other conditions. Over 50 percent of comprehensive8 participants stored their password either on paper or electronically, compared to 33 percent for those with the 16-character minimum and less for the rest of the conditions.

Despite the fact that passwords that impose a lot of requirements on content are harder to make and harder to remember, their use could be justified if they proved to be significantly more secure than, say, basic8 or basic 16. But contrary to password creation advice external to site-based creation rules, that did not seem to be the case.

Using 12,000 passwords sourced from Mechanical Turk participants, the researchers applied two cracking algorithms to see which types tended to stand up best to attacks. One was based on a Markov model that makes guesses based on character frequency, and the other was developed by another team of researchers and takes “training data” from password and dictionary word lists and then applies mangling rules to the text to form guesses.

http://cdn.arstechnica.net/wp-content/uploads/2013/05/password-crack-tries-640x310.png

The percent of passwords cracked vs. the number of guesses, using the second, more robust cracking method.
Per the researchers’ tests, the basic 16-character passwords were the hardest to crack for a “powerful attacker.” After 10 billion guesses, only around 12 percent of the 16-character passwords had been cracked, compared to 22 percent of the comprehensive8 passwords and almost 60 percent of the basic8 passwords.

It's worth nothing that the cracking algorithms used in this experiment differ from those Ars detailed in its story on real-world password crackers: one algorithm is a modified mask attack, while the other is based on the publicly available Weir algorithm. In either case, the results of using these cracking methods may differ from those used by real-world password crackers.

While the study casts doubt on whether complex and short password requirements result in passwords that are more secure than ones that just require length, it did find an interesting effect from the password restrictions. When the researchers compared passwords created under basic8 restrictions that happened to meet comprehensive8 restrictions to passwords actually created under comprehensive8 restrictions, the latter were significantly harder to guess.

Mazurek suggests two reasons to Ars for apparent resilience of passwords created under long-length restrictions versus short-and-complex ones. One is that there may not be enough good guessing data for long passwords due to the dearth of long-password requirements, which she said is true for both her own team and crackers in the wild. "It won't remain true long-term if people start requiring (and using) long passwords everywhere," Mazurek told Ars in an e-mail. The second reason is that "the space of possible passwords is just bigger... so relatively common long passwords are still less common than relatively common short passwords."

Between the two studies, it’s less clear why those in charge of setting password rules should ever lower length restrictions while raising complexity restrictions. If those people are interested both in more security and less frustration for users, the better solution seems to be setting a higher character limit and leaving all of the other restrictions out.

But from our brief survey of sites, 16 characters seems to be the maximum more often than the minimum, and complexity rules abound. Ironically, Microsoft, which sponsored both of these studies in part, sets its own maximum at 16 characters. If admins are interested in a more secure restriction, a (long) flat length requirement could go further than one that allows short passwords but requires complications.



How Important Is Password Complexity?

By:  Brien Posey, August 2013


About a month ago, I was walking through an airport and someone walking the opposite direction was talking to their friend about their password. I only heard a few words of their conversation, but the guy said that with today's computing power it would more time than the universe has even existed to crack his password through brute force.

As I thought about the statement later on, I began to wonder about whether the guy really knew what he was talking about or if he was just trying to impress his friend. Theoretically it should be possible to create a password that takes billions of years to crack, but I can only imagine how cumbersome it would likely be to enter such a password. That got me thinking, how difficult is it to crack a standard password?

I remember back in the '90s, everybody seemed to recommend having a password with at least eight characters, at least one number, and at least one symbol. Today each organization has its own password length and complexity requirements, but the recommendations from so long ago are still widely used. While it might have taken an absurd amount of time to crack such a password back then, computing power has increased exponentially, so I honestly wondered if those password guidelines were still viable today.

To put this to the test, I created a simple zip file and I asked my wife to password protect it. I didn't give her any firm guidelines other than to tell her to make it a strong password, but not to go crazy with the password length. In other words, I wanted her to use a password that realistically represented one that might be used in a corporate environment today.

Once she password protected the file, I set out trying to crack the password. First I tried a dictionary-based crack, and when that didn't work, I resorted to brute force.

I have to admit that I underestimated the challenge. I initially attempted the brute force crack on my laptop (while it was running on battery no less). I've got a high end laptop that is designed for gaming, so I thought that the crack would probably be done before we finished dinner. Wrong!

With my laptop battery getting low, I decided to break out the big guns. I had a few servers in my house that I wasn't using for anything at the moment, so I decided to distribute the load across multiple servers, and across multiple CPU cores on each server. All together I had 40 CPU cores running at close to 4 GHz trying to crack my wife's password.

Just to make things interesting, I bumped up the priority of the underlying process to as high of a level as I possibly could. Doing so made the servers non responsive to user input because nearly all of the available CPU resources were being used to crack the password.

Within a few hours all but one of the servers overheated and the automatic shutdown mechanism engaged to prevent hardware damage. Since the remaining server seemed to be operating at a safe temperature, I let it keep running. That one server was using eight CPU cores to try to crack the password and has been averaging 1200 attempts per second, 24 hours a day. The job has been running for over two weeks and the password has not been revealed yet.

Since the password has proven to be so difficult to crack, I decided to do some math and find out how many possible password combinations there really are. Again, I have no idea what password my wife used or how many characters it is, so I started out by looking some standard password requirements.

Suppose for a moment that someone created an eight-character password and used only lowercase letters. Assuming that the cracker knew the password length and that the password only used lower case letters, they would have to try a maximum of 217,180,147,158 password combinations (217.1 billion).  At a rate of 1200 password attempts per second, it could take up to five and a half years to crack the password.

So what if the user also used uppercase passwords? In that case, the number of possible combinations increases to 54,507,958,502,660 (54.5 trillion). At 1200 passwords per second, it could take up to 1440 years to crack the password.

If you also throw digits into the mix then the number of possible combinations for an eight-character password increases to 221,919,451,578,090 (221 trillion). At 1200 attempts per second, it would take nearly 6,000 years to try every possible combination.

So what if we really got crazy and also threw in special symbols? If you were to use every symbol that a computer can generate (including obscure ANSI codes) then there are 669,377,422,333,079,720 (669 quadrillion) possible combinations.  At 1200 password attempts per second, it would take 17,688,182 years to try every password combination. Seventeen million years is far short of the age of the universe, but it's still way too long to wait for a password to be cracked.

Remember that all of these insanely huge numbers were based on a mere eight-character password. So what if we increase the password length to nine characters? As you will recall, when we based the password solely on upper and lower case letters and digits (62 total characters) there were 221,919,451,578,090 passwords and it would take about five and a half years to try every combination at 1200 words per second.  If you increase the length to nine characters then the total combinations explodes to 13,759,005,997,841,642 (13.7 quadrillion). At 1200 password attempts per second, it would take roughly 363,579 years to try every combination. Adding one character to the password length took the time required to crack the password from about 5 years to hundreds of thousands of years.

Of course it is possible to perform more attempts per second. Part of the reason why my server is only able to attempt 1200 passwords per second is because the file is using 256-bit encryption. A weaker form of encryption would result in more attempts per second and a shorter time to crack the password. Similarly, adding additional CPU cores could decrease the time it takes to crack the password. If I were serious about trying to crack the password, I could lease an insane amount of computing power from a cloud provider.

Even so, there is no denying that length and complexity play a critical role in password security. Passwords can be made even more secure by using multi-factor authentication, or even trying out Windows 8's picture password feature.


  1. Partitioning Methods


Partitioning Concepts

By: Oracle
Partitioning enhances the performance, manageability, and availability of a wide variety of applications and helps reduce the total cost of ownership for storing large amounts of data. Partitioning allows tables, indexes, and index-organized tables to be subdivided into smaller pieces, enabling these database objects to be managed and accessed at a finer level of granularity. Oracle provides a rich variety of partitioning strategies and extensions to address every business requirement. Moreover, since it is entirely transparent, partitioning can be applied to almost any application without the need for potentially expensive and time consuming application changes.
This chapter contains the following topics:

  • Basics of Partitioning

  • Benefits of Partitioning

  • Partitioning Strategies

  • Overview of Partitioned Indexes





Download 312.53 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9




The database is protected by copyright ©ininet.org 2024
send message

    Main page