Lightknight said:
The difference in "crackability" of a 14 character password and a 15 character password is in years of processing time and that's only if they don't use the traditional algorithms and brute force measures.
This is because passwords that are 14 characters or smaller are all stored in a hash and broken up into two 7-character parts (easy to crack a 7 character password) but if it's 15 characters or larger then windows does not store the LanMan hash correctly so both segments will be incorrect or null passwords to any decryption utilities trying to crack the LM. That basically ruins brute force attacks.
Umm, ignoring the out-of-date-nesss of the advice/article, I'd also want to point out that if any website is using
Windows of all things to secure the passwords...well, how should I put it - that must me another entry in Shamus' list.
In addition any advice for "oh, here is how to go around an insecure hashing algorithm" is wrong. Saying "use 15 characters" instead of "FUCKING STAY AWAY FROM IT!" can be called "misleading", if we have to be short, and "actively harmful and counter-productive" for practical purposes.
P-89 Scorpion said:
Don't encourage sites to be even more of a pain just to be able to post on a damn forum!
Encourage
how exactly? If anything, Shamus advocates making it easier by removing the nonsensical "security" restrictions. Even then, that's not new take on it, anyway - anybody dealing with security and is at least half-decent has been advocating the same points for
years now. Shamus us bringing these points to the wider public - a good thing if we are to abolish these "security" practices.
Which exact point makes it harder to use websites?
Subbies said:
But aren't passwords written in real words like your second example easily crackable by using rainbow tables?
No, rainbow tables only help with straight hashing - pretty much anybody uses salted hashes. To say these are extremely hard to defeat with a rainbow table is an understatement. An attacker needs both the hashing algorithm AND the hash to generate the table. And since every user has their own hash, then they can't feasibly do it. Even if they were to somehow gain the hashes, they would still need to generate one table per hashed password. Thus, they would need to attack each user seperately which is way more resource intensive than an attacker usually wants to deal with.
Sure, if the attacker targets
you specifically (or any other single person) then you (or they) might be at risk. Still, if that's the case, chances are the attacker would most likely go for other attack vectors rather than blow so much CPU power (as well as all the other time and effort needed) to just attack a single password.
ForumSafari said:
The problem is that these factors don't actually determine how secure a website is, they determine how secure the website thinks it is. The most important vulnerability in account driven websites is how the data at rest is stored and secured. Admittedly this isn't stuff you can/should test yourself but it's far more important than how secure your password is.
For example; your password being fully CORRECT HORSE BATTERY STAPLE'd up is of absolutely no use to you if they don't properly encrypt the passwords at rest since an attacker that gets hold of the database can just read them out. In addition if the hashing algorithm is found or derived then it's child's play to reverse the hashing, strip the salt and get the password that way.
That's before we even get into badly validated input or cross-site trickery. None of that encryption means jack if an attacker can overwrite the email field for a record, request a reset and just reset it themselves.
At my university, we had some overly draconian password policies - they had to be really long and not contain anything that would "aid" in brute forcing it - in addition to capitalisations, special characters and length, you couldn't have sequences (123password or abcpassword), nor any word, for that matter. And whoever developed the fucking password validator decided to include all sorts of dictionaries - English, French, Italian, Welsh, Polish just to name a few. I don't even know how many they were, as when trying to create a password, you just get "entered text contains a word in " - these are just the ones I've hit. And for many of them, I never found out what the word was - seemed that any time I tried anything with a vowel in it, I'd hit a word in some language or other, so, in the end, the password had to me a long line of gibberish
which is really hard to remember. And since you just wasted, like, 15-20 minutes entering various passwords, few moments later the gibberish would have evaporated from your head.
Setting aside that making the users unable to remember the passwords does not help with security, and that the restrictions actually made the attacks easier (reduced search space), we found another issue with it. Email only used 8 characters. Ever. Even if your password was 20 characters long, if you were logging into your university email box it truncated the input to 8 and everything 9+ was ignored. And you were logged in, if those first 8 characters are were correct.
On a separate note, related to websites and security - the user security is one part of security. There are various other attacks that don't rely on the users' actions (e.g., password selection). I'll just use uni again for an example. Or rather, just my time in uni - one relatively well known pizza place came to the town. And they offer ordering over the internet. In the same week compsci students realised that the website was a joke from security standpoint - all the data for the order was stored client-side. ALL OF IT. Including the price. So anybody could easily order any amount of pizza for a pound. Or whatever price they wanted, really. It got patched eventually but it still took a couple of weeks.
Even though it's not to do with with compromising other accounts, it's just a real-world example of how an attacker doesn't necessarily need to attack other accounts. Exploiting SQL Injection vulnerabilities can bypass even the strongest password, while various bugs can remove the need to login as a specific user at all.
