Russion hackers get 1.2 billion usernames/passwords

[DrPizza]

ModeratorProgramming would take 165 quadrillion years to crack with a typical PC.

MarkbnjModeratorProgramming would take 170 octillion years.

Unless Markbnj was using the same password at multiple sites, and one of those sites stored it in plain text, and that site was hacked. In that case, that password would become part of a dictionary attack.

Dictionaries only work when there is no mechanism that locks out accounts for repeated failed password attempts. So a computer can't hammer Facebook.com with a million different password combinations over 20 minutes to break into your account because the Facebook server knows what is up.

Maybe I misunderstand this, but I think it's backwards; I thought the hackers use dictionaries to try to result in a hashed password that matches the hash that they have gotten a copy of. That is one direction (hashing) is easier to do than the other direction (unhashing). I'm under the impression that it's sort of a trap-door function, that is, mathematically, one direction is easier than another. E.g., multiplying two very large prime numbers can happen in far less than a second. However, factoring the product of those two prime numbers into the two primes can take a hell of a long time.

 

[Mark R]

How do these guys crack the password belonging to a given user name ?

I mean, for example the forum allows 5 retries for entering password and user name. Then the account belonging to the user name(If it is correct) gets blocked. So, there is a timeout that must pass in between entering passwords to prevent from being blocked and locked out.

The server stores the password in the database, and the database gets compromised.

In this particular attack, the hackers used SQL injection, to cause the servers to return the list of usernames and passwords.

Because the password file/table is such an obvious high-value target, it is very strongly recommended that the passwords not be stored as is, but instead the hash is stored. This way, if the hash is compromised, there is no simple way to reverse the hash process and recover the password.

Except that doesn't really work these days. You can build a dictionary of "likely" passwords and their hashes. The hackers can then lookup the stolen hashes in their dictionary.

To really foil that the recommendation is to store a "salted" hash. In this case, a random string is stored with the user name, and added to the supplied password before hashing. So, the server might store "user:BillG1; random:hgfws9rgb123kdyhf23bkivi823; hash: <hash of hgfws9rgb123kdyhf23bkivi823!ReallyStrongPa$$w0d!>"

The presence of a random salt for each user means that it is not practical to use pre-calculated dictionaries for bulk cracking.

However, it is still possible to brute force individual passwords one at a time. You simply compute a ton of hashes based on "likely" passwords until you find one that matches. Not really practical on a CPU, but technology moves on.

Remember, hashing is a easily parallelizable problem. GPUs are thousands of times faster than a CPU. FPGAs are multiple orders of magnitude faster than GPUs. I wouldn't be surprised, if there are even now ASICs in use by forensic services, data recovery companies, government black op units, etc. Remember that bitcoin mining is basically just brute-force "hash reversal", so there are hugely efficient, hyper-optimized GPU and FPGA code readily available for SHA256 (which is a hugely popular password hashing algorithm).

Because of the ready availability of ultra-fast hashing technologies, best practice is to use a special ultra-slow, high-resource function instead of a conventional hash. PBKDF2, bcrypt and scrypt are examples of these - scrypt in particular was specifically designed to be hard to parallelize due to massive RAM and RAM bandwidth requirements. Because of this, it is relatively slow on GPUs, and impractical on FPGAs (a top end GPU would likely only be able to do 50 khash/s in scrypt at its minimum recommended difficulty level - you could brute force the easiest passwords with a dictionary, but anything more is utterly impractical. By contrast $1000 worth of FPGAs running SHA256, would likely be getting close to 5 Ghash/s range).

 

[William Gaatjes]

Unless Markbnj was using the same password at multiple sites, and one of those sites stored it in plain text, and that site was hacked. In that case, that password would become part of a dictionary attack.

Maybe I misunderstand this, but I think it's backwards; I thought the hackers use dictionaries to try to result in a hashed password that matches the hash that they have gotten a copy of. That is one direction (hashing) is easier to do than the other direction (unhashing). I'm under the impression that it's sort of a trap-door function, that is, mathematically, one direction is easier than another. E.g., multiplying two very large prime numbers can happen in far less than a second. However, factoring the product of those two prime numbers into the two primes can take a hell of a long time.

That is a good point. Trying to replicate the result instead of decrypting.

http://en.wikipedia.org/wiki/Rainbow_tables

Any computer system that requires password authentication must contain a database of passwords, either hashed or in plaintext, and various methods of password storage exist. Because the tables are vulnerable to theft, storing the plaintext password is dangerous. Most databases therefore store a cryptographic hash of a user's password in the database. In such a system, no one&#8212;including the authentication system&#8212;can determine what a user's password is simply by looking at the value stored in the database. Instead, when a user enters his or her password for authentication, it is hashed and that output is compared to the stored entry for that user (which was hashed before being stored). If the two hashes match, access is granted.

 

[William Gaatjes]

The server stores the password in the database, and the database gets compromised.

In this particular attack, the hackers used SQL injection, to cause the servers to return the list of usernames and passwords.

Because the password file/table is such an obvious high-value target, it is very strongly recommended that the passwords not be stored as is, but instead the hash is stored. This way, if the hash is compromised, there is no simple way to reverse the hash process and recover the password.

Except that doesn't really work these days. You can build a dictionary of "likely" passwords and their hashes. The hackers can then lookup the stolen hashes in their dictionary.

To really foil that the recommendation is to store a "salted" hash. In this case, a random string is stored with the user name, and added to the supplied password before hashing. So, the server might store "user:BillG1; random:hgfws9rgb123kdyhf23bkivi823; hash: <hash of hgfws9rgb123kdyhf23bkivi823!ReallyStrongPa$$w0d!>"

The presence of a random salt for each user means that it is not practical to use pre-calculated dictionaries for bulk cracking.

This i can imagine. :thumbsup:

However, it is still possible to brute force individual passwords one at a time. You simply compute a ton of hashes based on "likely" passwords until you find one that matches. Not really practical on a CPU, but technology moves on.

Remember, hashing is a easily parallelizable problem. GPUs are thousands of times faster than a CPU. FPGAs are multiple orders of magnitude faster than GPUs. I wouldn't be surprised, if there are even now ASICs in use by forensic services, data recovery companies, government black op units, etc. Remember that bitcoin mining is basically just brute-force "hash reversal", so there are hugely efficient, hyper-optimized GPU and FPGA code readily available for SHA256 (which is a hugely popular password hashing algorithm).

Because of the ready availability of ultra-fast hashing technologies, best practice is to use a special ultra-slow, high-resource function instead of a conventional hash. PBKDF2, bcrypt and scrypt are examples of these - scrypt in particular was specifically designed to be hard to parallelize due to massive RAM and RAM bandwidth requirements. Because of this, it is relatively slow on GPUs, and impractical on FPGAs (a top end GPU would likely only be able to do 50 khash/s in scrypt at its minimum recommended difficulty level - you could brute force the easiest passwords with a dictionary, but anything more is utterly impractical. By contrast $1000 worth of FPGAs running SHA256, would likely be getting close to 5 Ghash/s range).

Amazing.

http://en.wikipedia.org/wiki/Cryptographic_salt

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.

A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication while defending against compromise of the plaintext password in the event that the database is somehow compromised.

Cryptographic salts are broadly used in many modern computer systems, from Unix system credentials to Internet security.

http://en.wikipedia.org/wiki/PBKDF2

 

[Exophase]

How do these guys crack the password belonging to a given user name ?

I mean, for example the forum allows 5 retries for entering password and user name. Then the account belonging to the user name(If it is correct) gets blocked. So, there is a timeout that must pass in between entering passwords to prevent from being blocked and locked out.

Typically , online banking allows for 3 login retries before the account belonging to the username(If correct) gets blocked. Here there is also a time out delay between wrong logins.
I think that if you use a wrong username and password for online banking, that the online banking website starts logging the ip from the (possible) perpetrator and other data that might be important.

But how can you crack a password if you have only a limited amount of retries ?

I can imagine that if you have a zipfile with a password protection that you can try as long as you like, unless the winzip (Or 7zip) program also blocks attempts to enter the password after a given amount of retries.

You're right, these days no one will let you try any meaningful number of passwords at a login, and even if they did it'd be heavily bottlenecked by the interface.

These days it comes down to cracking the password after already having a hash of the password offline, with a weak hash that's easy to compute.

 

[SunnyD]

Maybe I misunderstand this, but I think it's backwards; I thought the hackers use dictionaries to try to result in a hashed password that matches the hash that they have gotten a copy of. That is one direction (hashing) is easier to do than the other direction (unhashing). I'm under the impression that it's sort of a trap-door function, that is, mathematically, one direction is easier than another. E.g., multiplying two very large prime numbers can happen in far less than a second. However, factoring the product of those two prime numbers into the two primes can take a hell of a long time.

You are correct. The dictionary is a list of known passwords and their known hashes. The MO is breach, analyse against a dictionary for known matches, extract, exploit. Those anti-knock defenses won't stop the hackers when they already know the password on the first attempt.

Basically, as I said earlier, all of these breaches serve to only grow the dictionary, especially when one site's compromised password database also happens to include the ability to easily extract the plaintext passwords to make the hackers' job easier.

Brute force is only a means of last resort, typically reserved only for high value targets.

 

[darkewaffle]

Unless Markbnj was using the same password at multiple sites, and one of those sites stored it in plain text, and that site was hacked. In that case, that password would become part of a dictionary attack.

Well, in a way, yes. But good crackers aren't stupid people, if they knew that they got hold of the hashed AT forum passwords they might consider also making a list of all the user names and adding them to their dictionary. Or since it's AT they might make a list of tech related terms to add to their list, or maybe run a text analysis on AT articles or forum posts and add the top 100 most frequently mentioned terms or most commonly matched words/phrases to their list.

Maybe I misunderstand this, but I think it's backwards; I thought the hackers use dictionaries to try to result in a hashed password that matches the hash that they have gotten a copy of. That is one direction (hashing) is easier to do than the other direction (unhashing). I'm under the impression that it's sort of a trap-door function, that is, mathematically, one direction is easier than another. E.g., multiplying two very large prime numbers can happen in far less than a second. However, factoring the product of those two prime numbers into the two primes can take a hell of a long time.

Correct. The guessword is ran through the hash method and then compared to the hash found in the compromised list. If it matches, the guessword is the password the hash conceals.

As Mark R said, a useful protection against cracking is simply using a hash algorithm that's so resource intensive that it bottlenecks the number of guesses that can occur per second significantly. It's not a perfect solution as hardware will probably outpace those hangups in a few years, but it's an effective obstacle.

 

[Albatross]

i have 32 character passwords and up from KeePass,but if sites dont use prepared statements it doesnt matter.

 

[Exophase]

It's not a perfect solution as hardware will probably outpace those hangups in a few years, but it's an effective obstacle.

I don't know, there are performance parameters you can be dependent on that haven't improved a lot in the past several years, like memory latency.

 

[Markbnj]

Dictionaries only work when there is no mechanism that locks out accounts for repeated failed password attempts. So a computer can't hammer Facebook.com with a million different password combinations over 20 minutes to break into your account because the Facebook server knows what is up.

Except that in this case the hackers have a file with lots of hashed passwords in it (I assume, for the sake of clarity; it may also include some plain-text passwords). So all they have to do is figure out the hashing algorithm (there are only three or four in common use), then run hashes against likely words until they hit a value in the file. At that point they know the user id and the plain-text password.

 

[DrPizza]

Dictionaries only work when there is no mechanism that locks out accounts for repeated failed password attempts. So a computer can't hammer Facebook.com with a million different password combinations over 20 minutes to break into your account because the Facebook server knows what is up.

You're assuming that they are targeting a specific individual. Let's say hackers got all of the passwords from Anandtech, in hashed form. They run a dictionary attack on their own computer - that is, they try 100's of thousands of passwords using the same hashing, and compare the outputs to the stolen hashes. Let's suppose your password is password123. After trying password, and thousands of other passwords, they try password123, and the hash matches yours. Now they know your password is password123. At that point, they can attempt to log in as slayernine at gmail, hotmail, aol, bank accounts, etc., all automatically, using your username and password. They're not going to assume there's an account for slayernine at gmail, and try a million passwords. They're going to assume there's an account somewhere else with that username and password. Or, maybe password123 matched exophase. In that case, they're attempting to log in elsewhere with exophase & that password. In addition, they can log in as you here, and see what other information they might gather to come up with other possible account names. Suppose you had a PM from a FS/T deal you did, and you gave your real name (John Doe) on the address to ship something to. Bam, now we can try JohnDoe, JDoe, etc., on thousands of other sites, using your password.

I think the recent data was that around 40% of people use the same password on multiple sites (I find that to be lower than I expected). Once you have a username and password connected to it, it's the low hanging fruit.

-----

edit: that brings up an interesting thought - I think it's 3 or 5 login attempts before you're locked out at many sites. BUT, I think that's 3 or 5 login attempts for a particular account; not by IP address.

Experts, wouldn't limiting the login attempts per IP address be a lot more secure? (which is the case on these forums - is it the case at sites like Gmail?)

 

[Mark R]

Experts, wouldn't limiting the login attempts per IP address be a lot more secure? (which is the case on these forums - is it the case at sites like Gmail?)

It would provide additional security against password guessing attempts.

However, it would likely cause significant problems where IP addresses are shared. The US is rather unusual in that most ISPs provide a unique IP address to each customer, not necessarily a static IP, but while customer A has IP address W.X.Y.Z, no other customer can have that IP address.

On mobile networks, and on wired networks in many countries, ISPs use a mega NAT (called carrier grade NAT) to put hundreds or thousands of customers on a single external IP address simultaneously. Effectively, the ISP runs a NAT router, and each individual customer gets an internal IP (like each device on a home-grade network).

At work, all web traffic goes via a corporate web proxy at head office (not just at the branch office), as a result thousands of people share the same IP address. I frequently find that I can't log into many important sites, because they have banned the IP address due to excessive wrong login attempts (probably acutally just 2 or 3 people trying to log in before they've had their morning coffee).

 

[Markbnj]

Experts, wouldn't limiting the login attempts per IP address be a lot more secure? (which is the case on these forums - is it the case at sites like Gmail?)

More secure at a meta-account level, certainly, where someone might be trying multiple user identities and passwords.

But server-side protection is no protection against this specific incident, since these bad actors will have the correct user id and password before attempting a logon (they hope, and in many cases they'll succeed).

 

[Ben90]

ModeratorProgramming would take 165 quadrillion years to crack with a typical PC.

Absolutely false. Two words back to back with no other modifications is going to be one of the first checked. Literally seconds.

 

[John Connor]

Read this on USA Today on the kiosk at chili's yesterday. Why the fuck don't they list the hacked websites? This is why you ENCRYPT the fucking database asshole!

 

[mmntech]

Read this on USA Today on the kiosk at chili's yesterday. Why the fuck don't they list the hacked websites? This is why you ENCRYPT the fucking database asshole!

Yeah, what worries me the most is not knowing. What do they have to hide?

LastPass is a big boon but I always go but the rule that nothing is un-hackable. Especially when someone is determined to get it. Only computer savvy people know that stuff exists though. Most people want something that's easy to remember. That's why they reuse passwords a lot. Makes security very difficult. Problem is a lot of businesses dealing with e-commerce aren't taking it seriously. Or at least they weren't prior to the Target breech.

A lot of these Russian hacker groups are probably state sponsored as well, with near unlimited resources at their disposal. Don't think for a second that the NSA isn't pulling the same shenanigans either.

Some good security news though, proving that nothing is truly un-hackable. CryptoLocker got pwned by white hats. They've figured out how to analyse locked files and provide the correct key to unlock a victim's content. A service which is being provided for free. 1.3% of victims apparently did pay up. Which seems quite low, but it's estimated the group behind it may have made $3 million off the scam.
http://arstechnica.com/security/2014/08/whitehats-recover-victims-keys-to-cryptolocker-ransomware/

 

[HOSED]

What disturbed me when I changed ~20 passwords today was some sites only allow apha numeric passwords, some allow a few special characters, others limit you to 12 characters max ...
All of my banking sites allow up to 32 alpha numeric + special.
I change all of mine every 2 months or when alerted by a thread like this.
Thanks to all here for the very informative thread and putting my mind at ease!

 

[DaveSimmons]

FYI, an article explaining why this is probably just FUD, courtesy of Fark:

http://www.theverge.com/2014/8/6/5973729/the-problem-with-the-new-york-times-biggest-hack-ever

TL,DR:
- they bought bunches of old stale passwords from other hacking groups
- the user-password combo from a 2-year old hack that you read about 18 months ago is nothing to worry about unless you ignored the warning back then and use the same password everywhere

 

[SKORPI0]

http://www.holdsecurity.com/news/cybervor-breach/

Anyone know the credibility of this company? :\

 

[MarkXIX]

For all we know what's really going on is that they've compromised the network or systems along the way to be able to capture data in transit and they're going to capture everyone changing their passwords and hope for the best.

It's counter intelligence.

I am fairly confident I've done all I can on my most critical accounts to prevent compromise and defend against it if they do get in.

Anyone these days who does not choose the options for multi-factor authentication, e-mail and text alerts to account changes, and choose strong passwords at this point are setting themselves up for failure.

Also, just read an article on NBC News website that suggested using Facebook authentication across all accounts that offer it. Sure, use a single password on one of the largest targets on the internet and while I'm at it share all my information with that one organization so when they fall, they truly have everything on me. Nope, nope, nope, nope....

 

[Jaskalas]

No more passwords. We need DNA sample systems built into our phones and PCs..its the only way

A password that cannot be changed? That's a terrible idea.

 

[rh71]

nvm

 

[John Connor]

Also, just read an article on NBC News website that suggested using Facebook authentication across all accounts that offer it. Sure, use a single password on one of the largest targets on the internet and while I'm at it share all my information with that one organization so when they fall, they truly have everything on me. Nope, nope, nope, nope....

Yeah, that really pisses me off. "Use facebook to login." No thanks dumb ass I don't want you seeing my account. But I only use my first and middle name on facecock. If it weren't for my friends and family I wouldn't have the fucken thing.

 

[Markbnj]

A password that cannot be changed? That's a terrible idea.

Not to mention DNA is easy as hell to get.

 

[Miramonti]

This is me hijacking my account, posting as a russian hacker.