quinta-feira, setembro 07, 2017

ThisIsMyPasswordForNatWest: "KALI LINUX - How to crack passwords using Hashcat - The Visual Guide" by Taylor Cook

Yep, most of our supposedly easy-to-remember-hard-to-crack strategies fall pretty quickly when we're informed that there must be a symbol - but not that one, that one, that one, or that one - and there must be a capital letter and there must be a number, oh and sorry your password is now too long. So now we need to remember our standard phrase AND the fact that for THIS website we couldn't use that symbol so we had to put in another and we had to stop after 6, 8 or 10 characters which meant we had to move the number to the front...

Passwords should never be stored as plain-text, but as a big long hash. So 'ThisIsMyPasswordForNatWest' becomes 'a64b8d3190050e4600ed3352cb05e5fb9a54c6dc' under a hashing system called SHA1 for instance, and you can't take that hash and reverse it and get the password. A per-account string of random characters should be added to the user's password too - this alone makes it virtually impossible to crack a password. So long as no website stores your password as plain-text then you're in the clear.

The problem is that you can't trust websites to not store passwords as plain-text, and you have no idea if a website is there just to suck up people's passwords and password strategies. Or even if a company has a website and just one developer decides to make copies of submitted passwords or figure out people's password strategies.

Password strategies also rely on not being popular too - if enough people use the same prefix/suffix, or used the same 'Nellie, the elephant packed her trunk' passphrase but substitute a single word, then it just becomes another strategy that a hacker can add to their brute-force attack.

The Key is: Do not trust websites to store your passwords as hashes. Passwords should never be stored as plain-text, but as a big long hash. 

Assuming it is constructed with alphanumeric characters accessible directly from the keyboard, your 15-character string has about 15^98 possibilities. There are around 400K words in the Portuguese language alone (I don’t know the number for the English Language). A properly constructed 4-word passphrase has a minimum 4^400K possibilities, and the points about sophisticated dictionary attacks and common phrases and other things one's read on Wikipedia (aka the internet's largest honeypot for armchair know-it-alls) count for nothing if the passphrase itself doesn't follow language syntax. Even if you knew the exact number of words and characters in the passphrase, it would still be quicker on average to alphanumeric brute force than it would to use a dictionary attack. I'll grant you that in the real-world people don't choose good passphrases. They choose easy to remember stuff that makes a logical statement or sentence, or some Shakespearean guff or a line from their favourite movie or song. In that sense your logic sort of works, i.e., if we're going to recommend any "system" to the masses, then yours might be the better one to recommend. (Even that is debatable, as the weak link is still the fact that you have people choosing for themselves. Even you with your vast knowledge went straight for some well-known footballing dirge as an example.) However, don't try to tell those of us who know better that the mere existence of obvious exceptions and shortcuts to cracking poorly chosen or common phrases makes a dictionary-based passphrase less secure than 15 characters chosen from a "dictionary" of 98.

Another piece of advice: Serious hackers don't attack login pages (which usually have some sort of login rate limiting in place), instead they use some sort of social engineering attack to get inside the company’s network and get hold of the user database. The passwords in these databases are stored in encrypted form, but now they can test passwords using their own hardware and without any rate limiting. Using cheap graphics cards and rainbow tables to attack the most common hashing algorithms, they can test billions of password combinations a second. It's only relevant to attacks where the attackers have direct access to the user/password database and the passwords have been safely stored. That said, there have been cases where a site has not been secured against brute forcing.
Corollary of this is, of course, that an attacker brute-forcing your password is often not a problem unless it is used elsewhere (or permits privilege escalation) because the ability to brute-force the password requires the attacker to have already breached the website that password is for.

Bottom-Line: password reuse is a bigger problem than individual password security. Use a password manager and you fix both.

4 comentários:

Book Stooge disse...

What is a password manager? And why are they more secure? Aren't they just another app to get hacked, but with tons of passwords stored within?

I have no knowledge of these types of things, so my questions are born from a complete data void...

Manuel Antão disse...

A password manager is an application where your are stored inside an encrypted database (the way I described in the post) that you control, on your own system, and are never synced or uploaded anywhere unless you want to take them from machine to machine. The best are also a portable, meaning it’s super easy to take with you and use on multiple computers, even if that machine is locked down and all you have is a thumb drive. It has its own password generator, to help you change passwords and make sure every one of them is unique and strong.
When/If the attacker gets his hands on your database, you want to make it as painful as possible to retrieve those passwords using a brute-force attack. Hashing passwords will not make your information any more secure, but it will perform damage containment in the event of a breach. It all depends on the algorithm used to hash the passwords by the application. If it uses Sha-2, you're probably safe; an effective attack has yet to be demonstrated against it. That means SHA-2 is generally recommended for secure hashing.
Bottom-line: Use a strong random number generator to create a password of 16 bytes (letters) or longer; Feed the password into the PBKDF2 algorithm; Use HMAC-SHA-256 (a Sha-2 flavour) as the core hash inside PBKDF2. If you use a good password manager everything will be taken care of for you.

Book Stooge disse...

Do you have any recommendations for a good pwm app?

Manuel Antão disse...

I've been using KeePass for a long time (and it's free). It's suits my computer idiosyncrasies.