As the name implies, this should be an excellent starting point for the subject topic, in this case Passwords. While I make every effort to be thorough and hit every aspect, there are times that I inadvertently omit things or skip them due to scope, time, length or applicability. Email any questions you have about this or any other topic to blog@advancedpersistentsecurity.net
This blog aims to tell you Most of What You Need to Know about Passwords. This is from both a personal and a commercial perspective meaning that it can be applied in both settings. Disclaimer: I am in no way, shape, or form - past or present, compensated to endorse any solutions or software mentioned throughout this blog post.
Most of What You Need to Know: Passwords - The Beginning
We all use passwords in our daily lives: for social media, at work, at home, smart phones, voicemail - the list goes on. We are constantly told about how to make them more secure, but I have found much flawed logic in what many people say. In doing further technical research for my own career advancement and in doing more academic research in the social engineering field, I felt compelled to write this blog post.
What are passwords?
Passwords or passphrases are alpha-numeric characters and symbols in an order that (in theory) should be challenging yet memorable and should change from time to time. They are used to authenticate you, in other words: prove that you are who you say you are (again, in theory). Authentication is based upon these three tenets - Something you:
- Know (a password, PIN, or pass phrase)
- Are (Biometrics: your eye [retina or iris], fingerprint, typing behavior, voice)
- Have (A physical token or card)
When you only use one of the three, it is called single factor authentication. When you use more than one tenet, it becomes multi-factor authentication (MFA) or 2-factor authentication (2FA) or 3-factor authentication (3FA). Someone can easily steal something you know via asking, social engineering, torture, or other deception. They can steal something you have with ease as well. It is significantly harder to steal your biometrics. Conversely though, when they're stolen, they're gone for good. NOTE: I know of 0 documented cases of the theft of biometric data.
How do passwords work?
In a traditional and most simplistic sense, a system or application will prompt the user for the password and compare it to the known password in the database. This is done without hashing (more on that in a bit) and is the most non secure method after no password at all. In more complex systems (basically anything after the year 2000), the password is hashed, so the administrators cannot readily see what the password is (Note: they could still steal the hash and do a "pass the hash" attack, but that is uncommon). Hashing (also called digesting) is the means of using an algorithm to convert a string of any size to a predetermined size based on the algorithm. Examples of hashing algorithms are MD-5 (Message Digest version 5; which was thought to be secure until the past few years), Secure Hashing Algorthm (SHA; which is a 'fast algorithm' and can be susceptible to attack [below]), or BCrypt/Blowfish. I purposely omitted SCrypt due to many serious vulnerabilities. Of these algorithms, they have various sizes:
- MD5 is 128 bits long and considered depricated
- SHA-1 is 160 bits long and considered depricated
- SHA-256 is 256 bits long
- SHA-512 is 512 bits long, thus the strongest on this list
- Blowfish is a variable cipher of 32 to 448-bit key length with a 64-bit block size
I used "samplepassword1" (without the quotes) as a password. I passed it through a few hashing algorithms. Here are the outcomes:
- MD5: 62d3e77c26c8fb4221d08656e6d64aba
- SHA-1: 7d48a74c0733b2e88931063910df1b9a9c12686e
- SHA-256 (aka SHA-2): 1bd425392451454c7cc56fc754a5da9514a9919b25a05a937d68bdbd8a6354be
- SHA-512: ba874a2c8e0a664ce6d0b9a02fc9439aeb58e83e888fb83c8dd1e9488607defb99381e82de941e1f5a50c35fcc85ba430ffdbc2577d92f0b646a1442be7fe9e5
- Blowfish: $2a$07$3WAAFcnb9LTQAjoE6mGUUOk46YKHZNJVfvg3X8QDLcIwU3D5QdlbG
It will require more processing power to "crack" the SHA-512 because the string is longer and there are 36 (a-z; 0-9) possible values for each character. Compare it yourself here (Note that it is the SHA-256 site; but you can try it across all of them by editing the URL). It will take even more RAM and processing power to crack the BCrypt/Blowfish hash, since it is a collection of systematic "rounds" of hashing.
About Windows Passwords
Windows stores the passwords for the Windows Operating System in the SAM (System Account Management) database (typically in the C:WindowsSystem32config directory). Operating systems after Vista use the NT LAN Manager (NTLM) storage method, where previous versions used the LAN Manager (LM) method. The LM method broke passwords up and stored them separately. A password with less than 14 characters, it appended "404EE" to the end. If the password was 14 characters, it stored it directly. If it were 15 characters or more, it hashed it. This is why some places require 15+ character passwords. NTLM is not much better, but it is less obvious. An attacker could use a bootable USB device and Kali Linux (a hacking/penetration testing operating system) with the chntpw software to get access to the file and either crack the password, disable the password, or change the password. This is why physical access is important.
Using chntpw in Kali Linux to interactively reset or disable any or all Windows passwords - WITHOUT a Windows Admin password
Mimikatz
Options contained in Kali Linux for Mimikatz
There is another brutal tool out there to target Windows systems, namely those before Windows 8.1. This tool is known as Mimikatz. It is used as a tool to extract Windows passwords from LSASS (which places the passwords in unencrypted form in memory). Mimikatz uses C and C++ calls to pull these from memory and display them to the attacker. Two scenarios of user are as such:
- An attacker gains Admin or SYSTEM access to a Windows system using a variety of tools or techniques (either remote or physcially in-person). The attacker runs mimikatz.exe with the sekurlsa.dll file loaded and gains the proper access.
- Alternatively, the attacker could be sharing the desktop with someone using administrative credentials or talk the victim through it using a phishing attack.
Regardless of the attack scenario, the possibilities are vast. The attacker must know the architecture (32 or 64 bit; which is not hard with a good port and/or vulnerability scanner) can do some of the following:
- [Obviously] observe the password in plain text in memory
- Pass the Hash attack
- Create a Kerberos "Golden Ticket"
- Export Certificates
Example of the use of Mimikatz to crack a password
Offensive Security has an excellent Mimikatz tutorial!
Linux (Non-Windows) Passwords
Linux has had growing pains like Windows. Previously, the passwords were stored as hashes in the /etc/passwd file with the username, ID, and group. Since the file has to be world readable for the system to work, it was easy to exploit. The new answer is to put hashes of the password in the /etc/shadow file. /etc/shadow is only readable to root (admin). If someone can get root privileges on a Linux system, they can use the unshadow command to make a new file akin to the old /etc/password and use software like Hashcat or John the Ripper to crack the password. Below is a set of screen shots showing the process: Note: I created these three users with the following passwords below:
- test1 = password
- test2 = P@ssword
- test3 = P@ss12word
Based on the /etc/shadow output, I see $6 in the string, which tells me that this is stored using SHA-512.
Here, I get the /etc/passwd portion for the test users
Then I get the /etc/shadow portion for the test users
I run unshadow and pipe it out to a file
I run John the Ripper to crack the passwords
LOOK! There's one!
The other two will eventually come in time. The length of time will vary for both based on processing power, quantity of processors, quality of processors, RAM, GPU, and the complexity of the passwords. test2 will be cracked before test3. The only exception would be if I were using a word list with test3's password in it from a dump like LinkedIn, MySpace, etc. For this, I used the common (and giant) rockyou.txt word list; it has some mutations and numbers in it, but is generally limited. Instances like this are better use cases for hashcat over John the Ripper.
How to be secure and still use passwords
Password Redemption
So now that I have (potentially) terrified you about the damage to be done to passwords, I will shed some hope upon you. Despite everything that I demonstrated above, passwords, when implemented correctly, are still the best option. Why? They are less expensive than physical mechanisms (generally speaking) and they're typically less invasive than biometrics.
Mimikatz Protection
Protecting yourself against Mimikatz is tricky. At one point, the thought was to use Kerberos, but now Mimikatz can attack it. One thought is to restrict the algorithms using Group Policy (GPO) to use non-reversible encryption and AES, Install KB2871997, Restrict Administrative Accounts (do not allow everyone to be an admin, regardless of how easy you think it makes things), and enable verbose logging. This is a noisy process, if the security monitoring team is looking for this, it can be minimized. Finally, implement MFA.
MFA Options
As I stated above, you can mix a password with a token and/or biometrics as Multi-Factor Authentication (MFA). Note: Using 2 passwords does not constitute MFA. I have assembled a couple of options for using MFA. These are not universally supported, but they're useful when they are. Both of the technologies below rely on you to have physical custody of your phone. Okay, you can have someone read you the Google Authenticator code (if quick enough), but not Clef.
Google Authenticator
Google Authenticator is available for Android and iOS. It functions similarly to an RSA SecurID token except it's on your phone instead of a separate physical device. When you go to log in, you enter your username and password, then you enter the code from Google Authenticator. Note: you must set up Google Authenticator BEFORE the first use and the authenticator will use numerous "seeds" so you'll have different codes for different assets at the same time. These codes are only good for a short period of time. While I have experienced it with the RSA SecurID but not Google Authenticator, it may be possible to add a "salt" to the the Google Authenticator (an online search was inconclusive) which would put a static string (number or text) at the beginning of the entered string (Example 1234515462) using the top example for Google Authenticator. Although not observed publicly yet, Google Authenticator does rely on a mathematic algorithm thus it can be broken at some point.
RSA SecurID
Password Vault Software
This is my personal favorite part of this blog post after the password cracking piece. There are several password management fault tools out there. Because they're software, there is a possibility of flaws in the code of the software that would lead up to any or all of a target user's passwords being compromised. There are three main software applications for accomplishing this:
- 1Password: Offers a free (limited feature) and paid ($64 perpetually for full feature) version. Offers a business version. Android and iOS applications.
- LastPass: Offers a free (limited feature) and paid ($12 per year for full feature) version. Offers a business version. Android and iOS applications.
- KeePass: I am not linking this of my own volition; from industry research, it seems as if this software has too many flaws leading to password compromise and the parent company does not seem to be in a hurry to fix them, thus rendering the software dangerous.
What You Need to Know About Password Management (Vault) Software
Like anything else, it can be exploited. I saw a video about a year ago about a man who visited DefCon and asked to be fully hacked as a proof of concept. The attacker was able to completely steal his life because he was able to get his Password Vault master password during a phishing attack. Below, I detail the key points of the software:
- Set the master password as a pass phrase or another otherwise memorable but long password. Change it every 60-180 days based on your own appetite for risk.
- Set the master password to contain all 4 type faces: UPPERCASE, lowerCASE, $ymbols, and Numb3r5.
- Because you do not have to remember the passwords yourself, NEVER re-use passwords; use the password generator.
- Configure the passwords to be as long as possible (you won't have to remember them; you'll either inject the password using the browser add-on or copy and paste it into the field).
- I have found the sweet spot to be around 24 characters, but I know of people who use 35-40. Your only limitation here is what the applications and websites have set as a maximum.
- Make sure to configure the password generator to use more than 2 symbols
- This can cause a headache because some sites and applications filter out characters like ' - < > / # for other security reasons
- Make sure you save the passwords
- Consider using both LastPass and 1Password and having one save your password reset "answers" (If you don't use real answers).
- When setting up your logins, disable auto-complete. Read why here!
- You'll still need to change your passwords for sites and applications (non-master password), but not quite as frequently, maybe annually.
Conclusion
In conclusion, passwords may not be perfect for securing you and your data, but it seems to be better than the other options in terms of invasive nature and cost. While there will always be a threat; THERE IS NEVER AN ABSOLUTE SOLUTION, so in keeping that in mind, know there are real risks out there. There are options to add layers of security to your password. You should NEVER and I mean NEVER share your password. Change your passwords often and use tools like MFA and Password vaults and you should be okay. If you are told you're part of a breach or you find it on a site like Have I Been Pwned? it is easier to change one password than all of them.
About the Author
Joe Gray is the Founder of Advanced Persistent Security. He is a native of East Tennessee. He joined the U.S. Navy directly out of High School and served for 7 years as a Submarine Navigation Electronics Technician. Since leaving the Navy, Joe has lived and worked in St. Louis, MO, Richmond, VA, and Atlanta, GA. His primary experience is in the Information Assurance (IA) and Cyber Security compliance field. He has worked as a Systems Engineer, Information Systems Auditor, Senior UNIX Administrator, Information Systems Security Officer, and Director of IT Security.
Joe’s undergraduate and graduate degrees are also in Information Technology (with focus in Information Assurance and Security) from Capella University, where he graduated Summa Cum Laude for both degrees and completed some Graduate coursework in Business Intelligence. He also is a part-time (Adjunct) Faculty at Georgia Gwinnett College and at Gwinnett Technical College.
Joe holds the (ISC)² CISSP-ISSMP, GIAC GSNA, GCIH, CompTIA Security+, CompTIA Network+, and CompTIA A+ certifications. In his spare time, Joe enjoys reading news relevant to information security, blogging, bass fishing, and flying his drone in addition to tinkering with and testing scripts in R and Python.
When Joe is not contributing blog posts to AlienVault and all the exciting other things he does in his biography, he maintains AdvancedPersistentSecurity.net which includes a blog maintained by Joe and his colleagues. He also has a podcast called "Advanced Persistent Security" that can be found on most major platforms such as iTunes, Google Play, and Stitcher as well as at the direct link. Guests of the podcast thus far include Georgia Weidman, Frank Rietta, Tracy Z. Maleef, and Justin Seitz.