7 ms·
It's interesting. The author shows some fundamental misunderstandings and makes assumptions that are not necessarily based on real-world situations to present a
by iuguy 16y ago
It's interesting. The author shows some fundamental misunderstandings and makes assumptions that are not necessarily based on real-world situations to present an idea that longer strings with more recognisable characters (e.g. passphrases) are better than shorter strings with larger keyspaces. If you pick two data points you can actually fiddle with the numbers to present either side of the argument as the truth. For example:
A full 16-bit unicode 2 character password has 65 536^2 or 4,294,967,296 permutations to work through.
A lowercase alphabetic password of 6 characters in length has 26^6 = 308,915,776 permutations.
Of course there's a tradeoff involved, and that tradeoff is what IT departments try to manage, with mixed success. It's easier for the software to determine whether or not the password contains methods of increasing the keyspace than whether or not the user has typed out a 200 character long series of 'A' characters, so that's what they use. I don't know whether or not increased length has a higher risk of collisions for some algorithms (that's tptacek territory, not mine). Over time, software products have been guided by best practice standards from organisations like COBIT that define and mandate complex passwords based on keyspace rather than length alone.
Secondly, there is a difference between an online brute force and an offline brute force. Depending on the algorithm, with the right kit (or Amazon EC2 instances) you can get billions of hashes per second to crack a password hash offline. At that point your increased length only matters if the attacker doesn't know about the complexity. The samples provided are terrible as they're all lower case with a space at most. This is the poor end of the trade-off. To brute force a SHA-1 hash of the word 'sum' on my 2 year old laptop takes less than a second.
Online brute forcing (e.g. brute forcing a web form) is generally something you're not going to do if you're looking to compromise a web account, unless it is a specifically targeted attack (e.g. the user is an admin or a specific person of interest). In these situations your brute force rate is dependent on your network throughput, the application's ability to respond to concurrent requests and any other factors that may affect it (such as any monitoring system). Your web application on a linode slice will probably choke out between 40 and a hundred attempts per second (and you'll notice it unless you're blind or have no performance reporting). If you can get past the automation detection in larger sites, like Amazon, Google, Twitter etc. you'll probably be able to go much, much higher. For this reason, web site brute forces tend to be dictionary based, or at most on dictionaries and a number.
Ultimately when choosing a password you need to consider what you're defending against. If you own the box or the app, chances are you trust the defences. If you're going to change the password every few months then maybe you will choose a weaker password. If you don't own the kit and you're not intending to use the password, then use a tool such as Keepass[1] and generate the passwords yourself. That way it doesn't matter what J Arthur Random says on the Internet, you won't need to remember the passwords at all.
[1] - http://keepass.info/ http://keepass.info/
- GrandMasterBirt 16y agoThat's not true and is horsecrap. a) check length of password. Length < 6 = fail. Length < 10 = complexity requirement. Length < 15 = less complexity requirement. Length > 15 = secure. b) ALWAYS do a dictionary lookup on the password. A dic lookup vs a dic attack is cheap. Hell the dic can be stored in memory in a hash map... even with misspellings, we don't even need to be 100% accurate either. Once you have that, basically check complexity: 1 word = no good. 2 words = ok, add a special character in there and a caps. 3 words = great. 3 words + special characters = awesome. etc. Anyone can make one of these in a few hrs. and give error messages like: "Your password is too short" "your password is too simple for it's length, either make it longer or add special characters, numbers, and capitol letters" "your password is made up of a single word or easily obtainable information about you based on information we have in our system, please change the words used or add more of them" This means: (a) people understand why password is rejected and (b) people have choices and (c) increases probability that people won't forget their password. Oh and any system that limits passwords to < 50 characters can fo fk themselves. Too bad ADP (paystub) has a policy of 6-12 characters. Thats right limitations, and I have to use that crap. Is a 4000 byte database column that expansive nowdays? Furthermore... Changing password every 1-3-6 months is also bad. WHY? Simple, very very simple: 99% of the time you will have one of the following situations: - The same password is used + an extra 1 or 2 characters. - The same password is used + different capitalizations. - A different password is used + post-it note. - The user will forget their password immediately. The TRUE answer to the reason why it policies are the way they are is because people don't want to think. "Tom did it this way, it must be secure." "I don't really understand it, so whatever, its the standard, it must work." To make passwords secure they need to enact the policies I stated + a second factor for authentication. If you log in from an "unknown" location (a new one) just send them an email, or sms, or something that gives some key to enter to authorize. This will work in letting people know there is a breach, change pw on need, don't make ppl change passwords nonestop. Lots of advantages. Wow writing this I feel like we need a startup that provides this exact solution. One question for the fellas who know more... how hard is it to spoof someone's ip without them knowing (internal network or external)
- iuguy 16y ago> That's not true and is horsecrap. You must be fun at parties. You do realise that a password of AAAAAAAAAAAAAAAA would be considered completely secure by your system, right? For your second point your dictionary checking algorithm is only as good as your dictionary. If your dictionary is too small then you're not going to do much. It won't do much good for multilingual users either. <snip rant about changing passwords every now and again> So are you proposing that people don't periodically change their passwords? As for spoofing the IP, it depends on where you are and where the target is. If for example you're both on the same internal network, are NATted and your system's on the Internet then it won't distinguish between the two IP addresses. The same applies if both your and the spoofer are going through a proxy, or the spoofer is between you and them (although it is harder to do than just sitting behind the same NAT gateway it is doable).