[telecom] Why passwords have never been weaker-and crackers have never been stronger

Per Monty Solomon:

Can anybody comment on the specifics/methodology of this improvement?

- - Pete Cresswell

***** Moderator's Note *****

It has become easier to "crack" passwords by guessing them: samples of passwords entered by users show that user are prone to using the names of relatives, pets, or objects in their immediate vicinity when they have to enter a new password. Common substitutions, such as using "leet speek", a patois once popular with the online hacking community, are also included in the lists used for "dictionary" attacks.

Bill Horne Moderator

Replying to Message-ID: References:

Pete Cresswell:

While there have always been people who have chosen weak passwords, even some of the stronger ones are starting to fall. The main reason for that is PCs are getting faster, and large numbers of systems that can work in parallel are becoming more available. That is, even if you don't control a botnet of other people's infected computers, you can still rent a bunch of virtual machines from Amazon or some other cloud service provider, and do your dirty work there at a fraction of what it used to cost.

Encryption that was fine a few years ago is now no longer considered acceptable. However, companies have not bothered to update their encryption, as customers are not demanding it. (Saying "Of course our passwords are encrypted!" is good enough for most people.) Many of the recent password breaches, while encrypted, have turned out not to be encrypted very well by modern standards.

Your best strategy is to just use different passwords at different sites, so compromise of one will not lead to compromise of all. Even if you have a really strong password, you shouldn't use it everywhere.

John C. Fowler, snipped-for-privacy@yahoo.com

In article ,

On the off-chance that that is not a Rhett-orical[1] question -- 'standard' hacker technique for 'dictionary'-based attacks has included such spelling 'variations' for AT LEAST A DECADE.

[1] A question one asks, but "frankly my dear, don't give a damn" about the answer to. ***** Moderator's Note *****

It was not Rhett-orical. It was Puckish.

Everyone knows that Using /*ANY*/ dictionary word as a password is an invitation to attack. What many users /don't/ know is that hacker dictionaries have all the common variants in them, such as putting an exclamation point at the end of a word. The trick is to use easily-memorable pass-/*PHRASES*/ that won't be in anyone's dictionary.

Bill Horne Moderator

A consumer-grade PC with a few gamer-grade video cards can crack an eight-character password in less than a day. Of course, this will depend on how the password is protected; I believe that number is for weak cryptographic hashes such as MD5, which is used in HTTP Digest authentication and numberous other protocols. There's a growing literature of password-strengthening algorithms, which aim to make even shorter passwords stronger by increasing the computational difficulty of checking for a valid crack.

-GAWollman

Too many people are ignorant about passwords. There's an interesting article in the December 2012 issue of WIRED (page 180) entitled "HACKED" but I couldn't find an URL of it (yet). Another article by the same author is here:

The December 2012 article has many errors of fact (e.g., concerning the computer systems at MIT, etc.) but there are some good suggestions/tips that people should abide, the most important of which is NOT to use the same password for more than one service or system.

A good friend [Mark Crispin (author of the email IMAP RFC and many others)] whose bio is here:

once confided in me that he used the same password on some 50+ systems including BBS systems where the passwords were stored in plaintext and his BBS password was used by an unscrupulous SYSOP to get into many of the other systems to Mark's extreme discomfiture.

The usual rules apply: things that cost more need better protection. If you use a weak password for your online banking, you'll get bitten sooner or later, but even a strong password is no guarantee of safety if you don't review the account regularly of if you keep more money in it than you can afford to lose.

The problem with passwords is that they are, in effect, a "feel good" process, akin to the TSA: they are what Bruce Schneier calls "security theater". Password-based authentication was implemented to prevent time-sharing users from denying how much time they spent using someone else's computer, and only later came to be used as a way to "protect" users' data: passwords have always been a limited technique that is used only because there isn't anything better that computer owners are willing to adopt without external pressure being brought to bear.

Actually securing information from prying eyes is a lot harder than what most companies and/or users are willing to pay for. Two or three-factor authentication is just too complicated for the average user, and too expensive for firms to justify: when an online marketer is working on a two to five percent markup, every second of the IT staff's time is going to be committed to increasing sales, not to protecting data. The data, bluntly put, isn't their problem: the cost of the loss of a social-security or credit-card number is externalized onto the customers, most of whom don't have the ability to take legal action following an attack.

The only effective drivers for improved security are insurance underwriters and governments, and (as Schneier pointed out years ago) they are likely to drive changes in security for the same reasons that they drive effective alarms in banks, night watchmen at high-value targets, etc.: i.e., they are people left holding the bag when too-big-to-deny disasters strike.

The insurance industry is a driver because it's the ultimate loser in any major hack, and they are the only group that has the political and societal muscle needed to force change. That's why there are airbags in cars, and that's why there is an Underwriters Laboratories seal on the electrical panel in your home: the cost of failure is too high to bear, and too visceral for any politician to ignore.

When there's a major computer attack that costs a lot of wealthy people a lot of money (think triple-witching-days on Wall Street), /then/ we'll all be signing on with smart cards after retina verification. In the meantime, we have passwords.

Bill

Somebody suggested the "Dead Pet System"... concatenate the names of two dead pets and add digits to taste.

- - Pete Cresswell

***** Moderator's Note *****

Since one of the most common "secret" questions that sites offer to remember in order to help me recover a forgotten password is "What was your first pet's name?", I have a couple of "virtual" pets and I use those names, which can't ever be guessed.

For sites that insist on knowning my father's middle name, or my mother's maiden name, I have a couple of pseudonyms handy. The main thing to remember is that anything which is in a public record is /NOT/ secure.

Bill Horne Moderator

Actually, more like 3+ decades. Dicti>Everyone knows that Using /*ANY*/ dictionary word as a password is an

Also, what people may not realize is that odd words are in dictionaries too. Your Swedish Gr-Grandfather's given name that hasn't been in common use in a century? That is in a hacker dictionary. That technical term in some very non-IT related field? That is in a dictionary.

Simple passphrases of slammed together words are no-longer sufficient either.

More recent hacker cracking tools will take dictionary words and slam them togther for testing. A password such as "Cow-Pucks#Yesterday" will be found by standard tools and enough GPU power to cycle through everything.

Forgive me for being ignorant, but doesn't the bad guy have to then *try* each password variant s/he generates?

Once upon a time, some login systems put a 10 or 30 or 60 minute time-out interval if you had more than three failed login attempts in a row. (The shell account of my ISP gives you three tries, then a 10 minute lockout.)

I have a few security USB sticks that scramble the data stored on them and go inert if there are more than seven failed logins in a row.

What am I missing? Do most login systems now allow a barrage of login attempts without pause or question?

Seems that regardless of how much password cracking horsepower one has, some sort of time-out on multiple login attempts -- coupled with some sort of alert being sent -- would greatly slow or even pre-empt this bad behavior.

Frank

Dictionary attacks are fast for the same reason that hashing algorithms are fast: the idea of comparing one password hash to another is to make verification quick so as not to take too much of the user's time. That's why dictionary attacks are the preferred vector: if an attacker has a good dictionary, (s)he will have a "hit" often enough that there's no need to actually /decrypt/ the password hash, assuming that (s)he has access to it (see below).

In The Cuckoo's Egg, author Clifford Stoll recounted his surprise in the moment that he learned what a dictionary attack /is/: he was puzzled at the way the attacker who was in his system always copied the /etc/passwd file, which (at that time) contained the password hashes for every user on the system. It wasn't until he was talking with NSA cryptographer Robert Morris that Stoll realized how far behind the (pun intended) curve he was: Morris dismissed Stoll's questions about the /etc/passwd file by mentioning that he had an application that would do a dictionary attack in seconds. This is so great an advantage that NSA crackers spend a lot of time developing new dictionaries, because they can do a million guesses for the same computing cost as a single "brute force" decryption attack.

Of course, the key (again, pun intended) factor is having the hashes available to work on in the first place, which is why reports of breakins at major retailers take on so much importance: not only does a thief gain the advantage of having a data source (s)he can work on at his leisure, but (s)he also benefits from the divergence between business and security needs that is an ever-present gorilla in every IT manager's inbox: large companies are always looking for ways to speed up responses, and database administrators are always under pressure to speed up database dips. While the hashing algorithms that they use for their /own/ computer logins may be up-to-snuff, a DBA who wants to go home on time might choose an older, but faster, hash function to create the password hashes for /customers/, just to get those few extra milliseconds.

That's why a stolen database of password hashes is worth serious coin in the underground cracking world: whomever has it can do "dictionary" attacks without any risk of lockout or getting caught in a Honeypot. Once the attacker finds a password that matches a given hash, (s)he can use the other info in the stolen database to find the account(s) the victim was likely to use the password for.

Of course, this is all moot, because there's a new attack avail #$@@ CARRIER LOST

It depends on the nature of the attack. You are describing what is known as an "online" attack, and these are relatively common -- if you have a thousand machines that all share the same passwords, a cracker can try millions of passwords a second in an online attack.

But the sort of attacks we have been discussing are offline attacks: the cracker has gotten hold of something that either is encrypted using, or contains a cryptographic hash of, a password. These can be cracked completely offline, and the only limit is the computational resources required to test each guess. (In the case of the traditional Unix crypt() function, it's trivial to generate a "rainbow table" of all possible outputs for every (dictionary word, salt) pair, and then cracking is a simple matter of looking up the hashed value in the table to find the original password.)

-GAWollman

Per Thad Floryan:

The posts about decrypting passwords using either an enhanced PC or massive parallel processing are leaving me in limbo.

They seem to beg the question of how the entity attempting to decrypt can tell if they have been successful. Not knowing anything else, I want to think that they would have to try each password that they compute - whatever means they use.

But that seems to approach brute force - differing only in that they can come up with more possibilities in a shorter timeframe.

I'm starting to think that there is something going on that some of the thread contributors take for granted but which other contributors (like me) don't have a clue about. It's as if somehow a given account's password can be computed reliably without having to try logging in to the account multiple times. gMail accounts, for instance.

The reference to "password hashes" sounds like a handle to the part I'm clueless about.

authoritative answer, "it depends."

If the bad guy can get the stored encrypted password, and knows the encryption method, he can use his own code to encrypt and check for match -- *without* ever touching the 'real' system.

'Locking out' account access, even temporarily, makes it easy for the bad guy to do a 'denial of service' by trying passwords he knows are bad.

If they're used as answer to an _unrelated_ question, the fact that it is in a public record is not particularly significant.

e.g. using your birthday as answer for "your father's middle name".

***** Moderator's Note *****

If I enter "lamppoast-dezerte" as my father's middle name, instead of "Joseph", that's one less avenue for a cracker to take. Of course, it's better to have the password for the account tucked away in Password Safe

so that I won't forget it, but for sites that /demand/ an entry in such fields, it's always better to put in nonsense instead of "real" information.

Bill Horne Moderator

It depends. With no information to start with, they have to do that, and most sane systems will detect brute-forcing. That's not what the story is about though.

Brute-forcing in an offline mode (which is where the video card or PAL based systems come into play) works if you have the password's hash. A hash is the output of a one-way scramble of your password - text goes in, and some number of bits come back (usually 128 or 256), such that if even one character of the password is changed, you get an entirely different hash. Password hashes are stored in files or databases (on some unix systems, infamously /etc/passwd or /etc/shadow), and those files can be accidentally exposed to a website or otherwise lifted during a breakin.

So, what the hacker has to do is hash lots and lots of passwords, and then compare the resulting value to the hash value that they stole. If they get a match, that means they can enter the password on the site, and it will be the same as you entering your password. They do their dictonary first, and then start working on chracter patterns a letter at a time.

The issues are that some hashing algorithms (md5 for example) are showing their age, and you can even pre-hash all possible values in what's called a "rainbow table" so you don't even need to brute-force anymore - you just look up the password corresponding to the hash.

Better hashing algorithms mean the cost of running a hash is higher, making the process of breaking the password more expensive. Even better, there's the concept of adding "salt" (an additional string added to every password, either fixed or even unique by user) to the hash, so rainbow tables are either site-specific, or worthless, depending on how it's employed. Salt has existed with hashes for decades, but you STILL find situations every day where they forgot to use it.

What to learn from the article is that there's no such thing as a "clever and rememberable" password. Modern password dictionaries aren't simply the contents of /usr/dict/words; they're hundreds of megabytes of lessons learned over decades of successful password cracks. The ONLY good password is a long and totally random one consisting of all typable characters. Personally, I use LastPass for everything, so every site I go to has a unique password, with values like 'Bd29$UCsPrY9'. My password vault itself is secured by a 40 character passphrase, and backed up with a second factor (a yubikey). *

Blargh. Terrible idea.

Telecom Digest Moderator said:

That's not a bad idea - you HOPE (though talk to Mat Honan about that) that password recovery offers no bypass of the secret questions and no opportunity to guess more than once or twice before telling you to get stuffed.

I handle recovery questions the same way I do passwords - I have lastpass make a random string for each, and then have it save the form values so I know what the values are if I get asked one of the questions. Note: this can be really irritating if the recovery questions are asked over the phone, and I wouldn't be surprised if humans are less than diligent about making sure that what I just said (Q-3-7-h-question mark-l-

2-7-g-H-x) matches what they have on file. I've been playing around with the idea of using nonsense words instead for these; Lastpass has a "prononceable" password generator, giving you values like 'tonficutonel'. *

Thank you for the background!

A highly educational post.

Frank

Per PV:

Thanks! Now the thread jells for me.

Per PV:

Not to beat a dead horse... but...

If I'm understanding this thread correctly:

- Sites and DBs do not record a user's password. Instead they record the hashed result and apply the hashing algorithm to whatever the user types in.

- The password compromises referred to start with the hostile entity obtaining the site or DB's table of hash values/users.

- The massive computation comes in when it's time to figure out what password created each hash value.

- The value in extremely long and arcane (basically nonsense) strings lies in the additional computational power needed to back into the hashed value.

- (and I'm extrapolating here) Cases where somebody "hacks" somebody's email account, unless many accounts under the same provider were also "hacked" are mostly just some individual either guessing somebody's PW from information they know about the person or the person's PW having been compromised some way - like in an email message, or harvested by malware.