One simple trick for passwords the big companies don't want you to know about!

[Beamin]

Heres a n00b question but how do you hack into an account if you only get 3 or 5 tries then you are locked out for 24 hours or until you reset it? That seems like it would solve the brute force and dictionary problem.

[golden_labels]

Reverse brute-force.

Attacks aimed at specific average Joe are movie fiction. Unless you are a high profile target or have been chosen for some specific reason, nowadays no one cares about your particular account. The same goes for attacks based on knowing the probable password from a leak or phishing: this is done en masse.

Also, simply imposing per-account limits alone is a great way to DoS your own service. The attacker just needs to use a few arbitrary wrong passwords on any account in your service and suddenly no one can log in. With all the additional fun in the call center and support tickets.

[T3sl4co1l]

Yeah, most people use shitty passwords.  So, when another hundred million accounts get leaked, hackers can solve for a good percentage of the passwords; but never all of them.

Say the leaked information takes the form of username + hashed password pairs.  You don't know the passwords, but you can test various hashes against various passwords, and various salting methods, and pretty quickly find some matches out of the huge database you're checking against.

Often, the account name/e-mail is concatenated with the password, ahead or after.  Usually some "salt" is added somewhere as well.  Which may be just a constant string, or it may be a sequence number, or a random number, and it may be in whatever format (decimal, hex, base64, ASCII..).  If it's absent, or constant, that's easy to figure out -- when the passwords you discover always contain a common substring, you just write that into your rainbow table tool and vastly improve the speed of discovering passwords.  If it's random, that makes your job a lot harder because you need to figure out what random formula they used.  It can't be true random of course, it has to be paired with the user somehow -- it could be a hash of the username, or account opening date, or etc.

Once you get a few matches, you'll probably identify some patterns and can patch up the search method, greatly speeding up the process.  You grab a dictionary of millions of likely words, and set some patterns (lowercase, CamelCase, RandOM CaSE?), substituting vowels with numbers or punctuation, inserting random numbers in the string, etc.), and start hashing combinations and checking them against the database.

It's very difficult to crack a single password.  You don't know if it's simple or complex, short or long, language based (and which language(s), as discussed above), or full random.  You can check the likely candidates in shorter lengths, and exhaustively check short ones (up to 6 characters or so).

But multiplied by 10^8 or so accounts, the chance of finding a match is very good, and once you've found a few and figured out the salting method, you can just let it run.  Crack rates of 80%+ are common, and it's very likely that you can find some juicy content behind those accounts (if you were so inclined, that is).

Tim

[apis]

Heres a n00b question but how do you hack into an account if you only get 3 or 5 tries then you are locked out for 24 hours or until you reset it? That seems like it would solve the brute force and dictionary problem.

You don't. Consider bank cards, it's often protected by only a 4 digit pin code = 10000 combinations. If you could try 1000 combinations per second you could brute force that in 10 seconds. But usually they confiscate the card after three incorrect attempts, so you have to guess right in the first three attempts out of 10000 possible combinations. That is considered safe enough for everyone's bank accounts.

On the internet it's a bit different. Since most websites doesn't require a physical token to login (like the atm card) anyone can try to login to any account. Locking the account after a few incorrect attempts would let any kid to lockout all the users from a service by just trying a few random passwords (denial of service attack). The server can and should rate limit the login though. If you only allow one attempt per minute (as opposed to 1000 attempts per second) you make brute forcing much harder. The server can also use software that detects brute force attempts and blocks such ip-adressers. So there are many things you can do to improve security, but the end user doesn't have any control over that (and many websites have really poor security).

The problem today is usually not that peoples accounts gets hacked by brute forcing. (I'm referring to non critical, low security website accounts, like a forum login, not the admin password to your server or to your bank account or a presidential candidates email. If you have a paypal account for example you need to use a really good password.) The big systemic problem is that people use the same password more than once. When the login information leaks from some of the websites you use (that is inevitable), hackers use those list of usernames and passwords to automatically attempt logging in to other accounts. If a person used the same password for their gaming forum that leaked (for example) as they do for facebook and paypal, they will have a problem. If you used different passwords it only affect the site that was hacked. (Haveibeenpwned was supposed to show that passwords leak. You can see if your login information is available in one of the many freely circulated password list. But just because haveibeenpwned doesn't list you doesn't mean your account information isn't out there, it's just not in one of the easily accessible lists that any script kiddie can get hold of.)

Passwords are supposed to be "encrypted" (hashed) on the server so that even if the login information leaks the hacker can't see the passwords. If everything is done correctly on the server and the users have chosen good passwords (so they can't break the "encryption" used to protect the password list), stolen login information would be useless. But you can't trust that the websites store passwords safely. Even big websites are known to have really bad security, some use bad methods for protecting the password (md5) some doesn't bother to protect the passwords at all! Some websites (or an employee with access to the password list) might even be selling your login information to make some extra cash. I.e. even if you use really good passwords you have to assume they will leak.

The brute forcing of passwords usually refers to password lists that get leaked. Since they are often encrypted the hacker might have to break that encryption (i.e. the hashing) to get the passwords. If people have used bad passwords, and or the websites poor security practice, it is easy to do that. You can't rate limit that since the hacker controls the whole process, so a hacker might be able to try millions of passwords every second.

Anyway, this get's pretty complicated quickly and there are lots of caveats, so if you need to secure something important you really should get professional help. For non critical stuff, one of those free and open source password managers looks like a convenient option.

TL;DR: whatever you do, never use the same password twice.

[golden_labels]

Beamin:
As for apis comment: hashing is not encryption⁽¹⁾. With proper security practices passwords are not encrypted — they are not stored at all. What is stored is a value derived from the password, which has a property of being very costful to be turned back into any matching password⁽²⁾ — not to mention the original one. This feature, which would not be possible with encryption, is the crucial part of the security mechanism. No matter what information the attacker acquires — even all of it — they shouldn’t be able to cheaply obtain the password. When you enter a password to a [properly secured] service, they calculate that value from your password and only that is compared to what is stored in the database.

Encryption is not suitable for that purpose. Even if you do not know the key or even the algorithm itself(!), the passwords may still be recovered — even the lengthy ones⁽³⁾. Usually it is very expensive, but sometimes — paired with other information — it is surprisingly easy. As a very prominent example let’s take the famous Adobe Crossword: a leak of 150M encrypted passwords from Adobe. In this case the problem of finding the passwords was so trivial, that you may try doing that yourself, because the way encryption works produced a kind of a crossword (hence the name of the leak) with the associated hints suggesting the value . XKCD 1286 “Encryptic” visually explains how this can be extended to be used with longer passwords. Along the ECB penguin this is one of the most amazing cryptofail examples, which can be understood by people normally not associated with computer science or security.

So what should be used instead of encryption? While historically hashes were advised, this is suggestion outdated by a decade. The systems, which still use hashes, will probably hold a bit. But this is no longer the right solution. And it isn’t important if you use MD5 or SHA3. What should be used are KDFs (Key Derivation Functions). While, strictly speaking, KDFs and hashes are approximately equivalent⁽⁴⁾, in practice the terms are used to refer to functions with a bit different characteristics. Hashes are designed to use possibly little resources; KDFs are meant to be very resource hungry. If you want to understand why, consider that with proper software and hardware you may calculate between tens of millions (a decent PC, using CPU alone) to trillions⁽⁵⁾ (specialized hardware) of hashes per second. For comparison the design of KDFs puts a very strong limitation on how many of them can be calculated: if you wish, down to a dozen passwords per minute⁽⁶⁾. And it’s not easy to circumvent that limitation with FPGAs or even ASICs. Examples of such functions are scrypt, bcrypt or PBKDF2.

____
(1) While in this context we’re implicitly assuming cryptographic hashes, in fact hashing alone is not even a part of cryptography: they just have a common part.
(2) There may be infinitely many inputs that match any such value. Which leads to an interesting effect: there are many passwords that can be used to log-in to your account.
(3) Yet non-dictionary passwords are prohibitively expensive to be extracted this way.
(4) Hash functions were used as KDFs, and KDFs are formally producing a hash.
(5) Short scale; that is 1e+12.
(6) Though you do not want something that extreme in an online service, obviously.

[apis]

Password hashing isn't really encryption no, which is why I put the word encryption in quotation marks (and wrote hashing in parentheses for those who did know what it was). Most people have an understanding of what encryption is but not necessarily hashing. I hope people still got the basic idea, the password gets scrambled so it's hard to figure out what it is. The better password you choose and the better the hashing algoritm the harder it is to figure out.

Key derivation functions like PBKDF2 (although not what it was intended for) is sometimes used for password hashing, but it not ideal either. And while commonly recommended bcrypt might turn out to be too vulnerable as well. There was an attempt to come up with a better algorithm a few years ago through an open competition, similar to how NIST have come up with their recommendations in the past, called the Password Hashing Competition: https://password-hashing.net.

But I wouldn't recommend any particular function here. As I said, this gets complicated quickly and there are lots of pitfalls, don't take advice from an anonymous internet forum if you need to protect something that is valuable.

[golden_labels]

People considering switching to a password manager may wish to read the “Before you use a password manager” article lately mentioned by Schneier. It discusses risks involved in using a password manager, as well as approaches that are providing no gain.

[orion242]

Seems like fairly weak reasons to avoid PW managers.

If you reuse the same PW everywhere...you must have the capacity to remember one...

If you do reuse that one PW everywhere, well its all eggs in one basket isn't it.  Any single breach on multiple sites could be a complete day wrecker.

If you have malware on your machine....your 100% pwned already.

Good PW managers fix any flaws in near real time and only store encrypted blobs.  Minor risk compared to the PW reuse IMO.

To each his own.

[orion242]

Something to think about with PW reuse.

https://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/

And with SIM swapping seemingly trivial and prevalent these days, 2FA over SMS is pretty crap as well.

[golden_labels]

Seems like fairly weak reasons to avoid PW managers.

Uhh… in the initial version of my post I’ve urged people to read beyond the first paragraph. It seems I shouldn’t have removed that request. :|

The article is not suggesting avoiding password managers. It discusses common pitfalls and mistakes, which average person may encounter when first facing that technology. People are only people and human factor must be taken into account. I am and — until the solution is widely considered wrong — I will promote the use of password managers, criticize using bad passwords or ridicule security theater. But I will not tell my mother to jump into the topic headlong. Password managers are undoubtfully the best available solution, but you still need to learn how to use them properly. And the article shows the potential problems and provides a quite safe path to including password manager in your security policies.

[Mr. Scram]

People considering switching to a password manager may wish to read the “Before you use a password manager” article lately mentioned by Schneier. It discusses risks involved in using a password manager, as well as approaches that are providing no gain.

Common sense, really. Although some people seem to have more trouble with common sense than others, so spelling it out probably doesn't hurt. 

[Beamin]

Well it seems all my efforts to protect my data were in vein. Today in the mail I found out some scum bag collection company that had a years old 50.00$ medical bill I didn't even know I had. had all my info  stolen. Info including social security  their data was breached as determined by "an independent third party compliance firm". I can't stand these companies that pay fractions of a cent on the dollar for old debt then ruin your credit even after you or your insurance paid it. Since this is ambiguous I am thinking a $4999.99 small claims law suite against them where it will cost them more to fly out a lawyer to my state then just pay the amount. I have done about 10 small claims and they are ridiculously easy to win if you put a few hours into typing up the 12pt times new roman double spaced paper work. Sick of these companies. The letter outlines a free credit report with 24 months of credit monitoring! Wow they certainly are making this right considering having your identity stolen will cost you thousands and over a hundred hours of phone calls and letters in a BEST CASE scenario. I know they sold my phone number from the dates and times they got my info.  More then likely they were being cheap with the security of their site, after all paying extra for proper security doesn't benefit them in the remote chance this will happen..

[Mr. Scram]

Without commenting on this specific case, that's why you don't want your data to roam freely and in innumerable databases. If there is no data it can't get leaked.

[apis]

Even if some company doesn't collect your data the government does (and they can tap your connection wherever they find most convenient). There is no way to avoid it except legislation and people have voted again and again for more mass surveillance so not sure there is much one can do about it.

[Jookia]

Aren't you still just using a single secret across all websites?