So? Write it down and keep it in your wallet. You more-or-less know how to secure your wallet, right? Thus, your password will be just as safe. Also, if your wallet isn’t safe, you almost certainly have much bigger problems than losing the passwords it contains.
Note, of course, that this doesn’t apply to passwords you want to keep more securely than your Social Security number and driver’s license. If you know any such passwords, and I doubt you do, the best advice is probably to make them completely random, thousands of bits long, and store them on a USB thumb drive on a lanyard attached to either your clothing or your body.
Mathematically, yes. Practically speaking? I suspect two or three dictionary words stuck together is as secure as “&p4*381]G” assuming that you don’t explicitly tell the attacker that you’re using a password of that form.
Can you cite even one case where a “couple of dictionary words joined together” password was cracked by a dictionary attack (or similar?).
I suppose it’s possible that after exhausting the dictionary, the attacker could then turn around and try every combination of two, but you’ve now gone from 80K or so possibilities to 80K squared possibilities, and that’s only for two words, and for the very small subset of passwords that are of this form. My guess is that the attacker either gives up after the dictionary (after all, they’ve usually got lots of accounts to try and hack, and they’ll get into some with just a dictionary attack), or they go to a symbol-combination approach at that point, looking for shorter, random passwords.
And as has been mentioned, almost nobody does this anyway unless they’ve gotten a local copy of the password database. They’re far more likely these days to put up some semi-useful “free” service on the Internet that requires “free” registration, (or hack an existing insecure one that stores passwords in plaintext or somesuch), then try those username/password combinations on the good stuff.
While Rainbow tables can provide spectacular results, those results are gained at the cost of a massive amount of precomputing and space. To crack an eight character mixed case password with numbers requires a 1/2 Terabyte rainbow table, which is 16 times bigger than the table required for a 7 character password.
41 characters are currently unachievable for Rainbow tables.
Unix systems use Salt to defeat dictionary and Rainbow attacks. Basically, you add a short string (always the same) to the beginning of every password before hashing. It does not even matter if the salt string is known by an attacker - no password directly matches anything in the dictionary. The attacker could generate an entirely new dictionary/Rainbow table including the salt if they knew it, but it would take so long as to invalidate the exercise. This is one of the reasons for regular password changes - if the password is attacked by brute-force, by the time it has been cracked, the password is useless.
I think it’s a general principle of cryptography that you assume that the attacker knows the general form of the passphrase. Anything else is “security through obscurity”. That’s why I say that we should think in more general terms of symbols from a set of symbols, rather than the specific case of characters from the set of alphanumerical characters + punctuation. Assume that the attacker has a rough idea of what set of symbols you are choosing from.
Ruminator, the question of how many English words there are is a knotty one. When you get up into the 50,000 - 100,000 range, you are including a huge number of very obscure words.
The most obscure word in the OP’s example is probably “Pallas”, a proper noun, which nevertheless shows up in OneLook’s “common words only” category.
You’re generalizing that statement far too much. The “general form of the passphrase” for the vast majority of password sites is basically: “stream of typable characters of defined minimum and maximum lengths.” I’ve never seen one that tells you to use, say, three dictionary words concatenated. I agree that a site which did require that would be less secure (because it defines a smaller search space for the attacker), but that’s the opposite of what the OP’s asking, which is: if you use such a phrase in place of, say, a random string, are you reducing your security noticably? I still claim not: there are an infinite number of such possible simplifications (all numbers, letters first, then numbers, dictionary word + number, dictionary word backwards, dictionary word repeated, etc.), and once you get beyond the ones that are used by a significant fraction of the population (name, family/pet names, dictionary word, phone and SS numbers, dictionary word + 1 digit), that space will rapidly approach that of just doing symbol combinations. Besides, usually you have multiple accounts to attempt, and in such a case it’s almost always better to try to attack multiple accounts with simple passwords than to try and crack one account with hard ones. A surprisingly large number of folks use “password” as their password, for example.
(And by your definition all passwords are security through obscurity–after all, the only thing protecting you is something that you know and others shouldn’t–your password.)
You don’t get that from knowledge of the site, but from knowledge of the user. For instance, anyone reading this thread (which could be anyone in the wide world) might reasonably guess that Skald’s actual password, while not the specific phrase in the OP, is still a multi-word phrase.
It’s not a secure site and I don’t trust my Javascript knowledge enough to dissect exactly everything it does. I feel like it’s fine but really what’s the advantage of giving it my real password?
For no particular reason I decided to download ophcrack from that link, and AVG (2011) jumped to attention and claimed it was malware. Is this a case of overzealous AVG?
Probably. AV programs seem to consider any sort of cracking or hacking tool malware. To me they really wouldn’t be malware unless they can be run in an automated fashion, but I guess it’s too difficult to make that distinction.
Just an additional bit of fuel to the fire… crypto (and good password protection) are generally based on the concept of 'computational feasibility" - SHA has fallen victim to folks thinking it was secure; MD5 had a fail (via Playstation(s) - all attempts to encode a password are vulnerable.
As Denis Leary said, “Life’s gonna’ suck when you grow up; it sucks pretty bad right now.” Same thing applies to InfoSec.
For excel, it doesn’t have to take a long time to crack the file, mostly because the ‘hashing’ system that Office uses is fairly limited - we have a quick routine that we use at work that doesn’t necessarily find the original password, but only takes a few minutes to find a password that will open up the file, by trying all distinct hash combinations.
As I recall, the passwords that it generates are generally very long, with all of the characters except the last being ‘A’ or ‘B’, and the last can be any letter or some other characters.