Tricks I use:
From 1977-2001, I used variants (swap out the vowel for another vowel) of a nonsense word in a 1976 Doonesbury. The only password note was a tiny post-it with the current vowel and if the suffix was in play (used if the shop required a longer password).
Now:
Old addresses - number and street
Old phone numbers - once upon a time, the first 2 digits were expressed as characters - revive it.
Old lovers
One I’'m playing with: look at the address in the address bar on the signon page. Come up with a consistent way to convert all or part of it into a usable password.
FOR THE YOUNG-UNS:
You are going to find a bunch of people asking you for “security questions”
Your mother’s maiden name is public record.
Any number of people know your pet’s name
If you still live in the same town, the name of the school you attended is not hard to guess.
Come up with a list of fake data to plug into these kinds of questions.
Your mother’s maiden name? Give them her middle name, or “no mother” - anything but public record.
Pet’s name? born04/23/02
etc.
We old folks who have been using real data would have a hell of a time trying to remember which got the old data and which got the new, but for those beginning the trip…
I’m not participating in the thread because I’m smart enough to know what I don’t know. If this were a thread started by someone else, I would be following with interest but not attempting to contribute. I’m taking the same tack even though I’m the OP. But I’m reading all the posts, twice, and appreciate the contributions of those who know more about the subject than do I.
I can see that you are very cluey regarding this subject, so may I ask a question? When I enter the wrong password into my bank’s log in more than 5 times it closes down and I have to phone the head office. So how does a hacker enter 10 million attempts in 30 minutes and get away with it?
That’s already been answered. They’re not trying to log in, at least not until after they have the password. The assumption is that they’ve somehow gotten their own copy of the password file, and are attacking it entirely on their own computer (this actually happens fairly often).
Thanks treis for responding to my post. However I think you misunderstood what I was attempting to state briefly in my point#7. I know about hashes. I know what they do and what they are for.
The question I raised is exactly how secure is a password based on the now famous correcthorsebatterystaple method. My conclusion based on what I have read over the past couple of days is, not terrible but not quite as good as I thought. The vulnerability seems to be attacks based on combinations of words from a hacker’s dictionary. (This is not surprising since that is how the thing was created.)
What I was fishing for is an assessment of my current understanding by those in the know.
I base my thoughts on the correcthorsebatterystaple method primarily from this site which someone linked from another thread. It is well worth a read (twice). But here is a summary.
As an experiment, three computer gurus were given a list of 16000 hashes and the challenge of extracting as many passwords as possible as quick as possible. The most successful of the three achieved 90% hit rate in under 24 hours. Commenting directly on the correcthorsebatterystaple method he explains the technique used to crack the password, “momof3g8kids”.
Referring back to my list of 10, I would love some feedback on how well I understand the lay of the playing field.
So they can’t hack my password, they hack the banks. Doesn’t this become the banks problem? Apart from some inconvenience, why is it a big deal for me?
Also, I assume banks are not completely stupid and as someone else has pointed out, woudn’t they quickly realize that half of their customers sending their life savings to the Cayman Islands is very suspicious? In Australia it is so easy to collect CC details from people using ATM’s that all this fiddling about with hacking passwords is too much hard work.
Even a few days of sending out phishing emails would give them enough cash to keep them going for a long time.
No necessarily, since many people reuse their passwords they can hack some other site(like the Straightdope!) and try to use the passwords they obtain there to get into banks etc.
On a side note, why aren’t banks in the US using two factor authentication? Allowing access to bank accounts with just a password is piss poor security to begin with.
When I attempt to move money from my bank to a place I have never previously used they sms me a code number to confirm my transaction. So even if they got into my account there is no way they can transfer money out. I can’t imagine how a hacker can beat that system without also having my mobile in his hand.
Which means they(or at least your bank is) are using two factor authentication(at least for transfers).
Every time the topic of online banking and security comes up here people only talk about passwords, so I got the impression that was all that banks in the US relied on for security. Nice to see I was mistaken.
So “momof3g8kids” failed because, in this attacker’s dictionaries, it was merely a two-word phrase. The point of “correct horse battery staple”, diceware etc. is that you don’t need to use weird, hard-to-remember-and-type, symbols to make strong passwords. Merely concatenating enough simpler symbols works well, as long as they are random and hence unrelated. But two words isn’t really enough for important passwords.
Hence my caveat about being saved by length.
If this hacker used two words combined, might it not be reasonable to expect others might use three? Especially if this tactic gains popularity. After all, this particular hack used minimal computing power and only went for 24 hours.
Three words would take thousands of times longer, since even lists of common words could have thousands of entries. Four words would take millions of times longer.
If your bank account is hacked, that’s probably their problem. It’s more likely to be a problem if, for example, your accounts at PayPal, eBay or Amazon etc got hacked - because (depending on how these are configured) those may already have stored pre-authenticated access to your bank and/or spending cards - you might have difficulties there such as:
[ul]
[li]Convincing both eBay and your bank that the transaction was fraudulent[/li][li]Bank charges if overdrawn whilst sorting this all out (bank may not waive these if they didn’t cause the problem)[/li][li]PayPal may just shrug and turn its back on your problem (they have something of a reputation for not always reaching the right conclusion - and refusing to discuss a matter further once they consider it resolved)[/li][/ul]
“correct horse battery staple” is exactly as secure as Randall Munroe claimed it was, because he evaluated its security based on the assumption that crackers would be attacking it in exactly the way to which it is most vulnerable. It is, in principle, vulnerable to a dictionary attack, but it’d be a really long, slow dictionary attack, because it has four words in it, and because (this part is important) those four words are completely random. A phrase like “Mom of three great kids”, despite being five words instead of four, is considerably less secure, because it’s not random. You can easily imagine a smartphone keyboard auto-completing most of that, because when people talk about moms, they’re also often talking about kids, and moms usually think their kids are great, and three is a relatively common quantity of children.
(it shouldn’t need to be said, by the way, but just in case: When I say “correct horse battery staple” is secure, I mean other passwords constructed in the same way as that, not that specific password itself, which has now made its way onto all of the standard lists.)
Look at the ongoing Target incident. They initially reported that only the hashes of peoples’ PINs were stolen, not the PINs themselves (among a lot of other data). So anyone with a file of those plus the associated account info can run in their own free time hash cracking software to get the PINs. And since those are usually a lot easier to find (digits only), you should assume that pretty much those debit card accounts are compromised.
Note that this is just another example of the source of the data (Target) is not the same site as the eventual target (the banks).
Don’t assume the compromised site is the same as the later attack site.
Treis, thank you, thank you for your terrific explanation of how this whole business of passwords works. I read your post about four times (slowly) and I think I have a handle on it.
Got a question…
Is the same hash-generator (my term) used by every business that takes passwords? In other words, will the same password spit out the same hash to both Citibank and Amazon?
If so, doesn’t that mean that there is probably some giant hash-crackers’ translation dictionary out there that can translate millions of pre-cracked hashes without doing any of the work?
If not, how do the hash-crackers get access to, say, Citibank’s hash-generator in the first place?After all, without it how can they try all those attempts – 5,000 per sec, you said – to find matches between possible passwords and Citibank’s database of hashes (which, I realize are commonly leaked)?
Let me preface this by saying that I am not 100% sure about the details. Cryptography is very complex topic and very hard to do right. It’s a sure bet that if you try to write your own you will do something wrong and end up making a system that is not secure. So you just use the methods that very smart people have spent a lot of time working on.
But essentially yes, they will all use the same algorithm. But they aren’t just going to take your password and hash it. They will add something called a salt. So if your password is “a” they will add another string to it. In other words, I submit “a” and the string they hash is “a” + “9SDf834Scs”. Then, each time I log in I submit “a”, the server adds “9SDf834Scs”, calculates the hash, and then checks for a match. The stored hash of “a” will be different for Amazon, Citibank, Netflix, etc.
So it is true that our evil hackers need to know another piece of information, “9SDf834Scs”, before they can do anything useful.
There’s two ways to use the salt. I can randomly generate it for each user and store it in the database. Or I can use a master salt and use the same salt for each password.
Ultimately the problem is that the server needs to access this salt in plain text somewhere. If we stored the salt with the user, well then they have that immediately. If we have stored it somewhere else, then the question becomes how secure is that somewhere else? Clearly if we’ve already lost our entire database, then the answer is “probably not at all” and we can assume the hackers have our master salt.
This is exactly what the salt stops. But ultimately, it’s not much of a gain because calculating hash functions can be done so rapidly nowadays.
Let’s look at the ways Citibank can salt their passwords:
(1) They can use a master salt and use the same salt for each stored hash. In other words, every password will have “9SDf834Scs” added to the end before hashing.
If I have that master salt, I simply write my program to add “9SDf834Scs” to everything in my dictionary. If I don’t, then there’s one thing I can try. I can be sure some dumbass has used the word “password”, so I try “password” + random string until I find a match. Hopefully our master salt is something random enough that this will take billions of years before they find the match.
So in terms of security this either has (1) made it essentially impossible for hackers to get any passwords or (2) done virtually nothing at all, depending on if they have the master salt.
(2) They generate a salt for each user and store it in the database right next to the hash. Obviously if our hacker has the database, then they know each user’s salt so that doesn’t make our password more secure.
However, depending on what the hackers are trying to do, this may have helped us. If they are looking for a specific user’s password, then it has done nothing. They just run their program with that user’s salt and hope they find something. But generally speaking that’s not what they are doing. They are just looking for any match and they don’t care which user that match is for.
So let’s say they try “password”. Now, they going to have to do the calculation for each user. If we have 100,000 users, that is a somewhat significant burden, it’s going to take them ~100,000 times longer to try each password. If your password is really crappy, you’re still screwed. But if it’s the 100,000,000th combination that they will try, well, this might save your bacon.
“$2a” identifies the particular version of the algorithm used
“$10” is a value that identifies how random the hash should be*
“9EM3RUqrKVolYgsuoZQo3” is the salt
“uwtA2g1LDe5CKqBiep9FS4qB71.f.Gj6” is the value generated by the algorithm. This is the hash we are referring to, and ultimately what needs to match for a user to gain access.
So if evil hackers get access to my data base, they know what I use to generate my hashes. They know what the salt is for each user. And they know what the hash is to compare to.
If you are wondering why this is here, it is for automated testing and it controls how long a password takes to generate. Basically, if I am writing something like the SDMB I will write a ton of automated tests. Each time these tests run, the database is wiped and then everything necessary for the test is created. So let’s say I am writing a thing to test sending a private message, my code will look like:
Create User1
Create User2
Log in as User1
Navigate to Send Message
Send Private Message To User2
Log in as User2
Test to see if User2 has a message
So anytime I change something, I run my tests to make sure I didn’t break anything.
Now, when I am in production I want really secure passwords. Since users don’t get created very often, I don’t care if my server takes a second to generate a password hash. On the other hand, if I am running 600 tests, I don’t want to waste 10 minutes waiting on password generation. Since this is development/testing, I don’t care if the passwords aren’t secure.