I loved this blog by “No Bugs” Hare about Password Hashing and thought it's a great read for developers. Read it and enjoy! Here are some of the main highlights I took away ...
- What is hashing? It's a one-way transformation. It's NOT encryption. You cannot decrypt a hashed password if done correctly.
- Why do it? If an attacker gains access to your password table, you want to prevent him from gaining access to all user passwords.
- Can hashing be done wrong? If it's simple hashing, an attacker can create a dictionary of all possible passwords (or at least the most common) and do a lookup to see if any of your users have those passwords.
- What is salt? If my password is 'abc' and so is yours, salt will make the hash different. Thus dictionaries aren't helpful now because the password 'abc' can become many different hashes.
- Can a salted hashed database be cracked? Yes, if an attacker gets your database and has all your hashes and salts, he can take it to his lab and still try to guess every possibility for that salt.
- What makes offline cracking harder? There are 2 answers mathematically speaking. Long passwords. Slow hash functions. The amount of time to do an offline brute force increases based on those factors.
Also, don't forget that even if you properly hash and salt your password database, an attacker can get a password from other methods. Make sure passwords are passed over encrypted protocols (like HTTPS) at all times so they can't be sniffed out. Implement a strong password recovery solution so that an attacker can't just reset or recover a password. Implement employee training to educate them against phishing and credential harvesting attacks.
And of course you've heard that passwords may not be the way of the future. A better solution is perhaps something like 2-Factor authentication that requires 2 things to login such as a password & a token from your iphone.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Showing posts with label Hash. Show all posts
Showing posts with label Hash. Show all posts
Wednesday, April 20, 2016
Tuesday, April 28, 2015
Hashes Are Insufficient for Blacklisting
You may be familiar with hashing tools like md5deep which allow you to generate a hash, or unique identifier, of a file. This is very useful for whitelisting files (only allowing your employees to install and run programs from a defined list). This is also very useful in validating that the file you currently posses is the exact same file that the author originally created.
Hashing is also commonly used in blacklisting programs (preventing employees from running specific programs). Hashing definitely has value and plays a good role in blacklisting. For example, if there is a common public commodity malware that all the script kiddies are just grabbing off the internet and using to infect victims, you can hash that malware, toss the value into your AntiVirus tool, and it'll quarantine/detect that file and prevent it. So hashing is great for blacklisting those well known, seen before, popular variations of malware. It's also good for example if a specific malware has just attacked your network, and it's now spreading and you need to find our where is is, where it has been, etc. You'd hash the file and search your network for that hash value on shared drives, workstations, etc.
But you should know that hashing should not be trusted as your only method of blacklisting. Why? Because hashing gives a unique identifier for a specific variation/version of a file. But if any little thing in that file changes, such as a version number, a comment, the order of the code, the amount of white space, or the actual code itself, they will all generate a brand new totally different hash. Why does that matter? I'd like to show you a very simple example.
Let's say I'm a bad guy and just wrote some malware that I send out in phishing emails and if opened, drops a batch file on your c drive, messes with your notepad.exe , and executes the batch file.
Now if I were the AntiVirus signature writer, I found this malware in the wild, I'd hash the batch file ( 1b0679be72ad976ad5d491ad57a5eec0 ) , and every time any other victim executed this malware, the hash would be found, detected and quarantined. Great!
But if I were any sort of experienced malware write, I'd add at least 1 additional step. Instead of just messing with notepad.exe , I'd also make sure that my batch file is dynamic and looks different every time. How would I do that? One simple way would be to just add a random number in a comment to each batch file.
By doing so I have just guaranteed that every time my malware executes it generates a brand new unique Hash. Now adding the hash of the malware to the AntiVirus signature is no longer useful, because the hash will change every time it executes. Oops.
Now my example was written in C# and batch files, but please realize this concept could be applied to anything, including Powershell scripts, VBA Macros, executables, etc. It could also be applied to phishing email attachments (perhaps send out each attachment as a slightly modified versions, maybe linking the modification to the user's email address).
That's where Behavior Based detection, Hueristic Based detection, IoCs, etc. have started to come into play, because Hashes cannot be your only method of blacklisting.
Happy hunting.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Hashing is also commonly used in blacklisting programs (preventing employees from running specific programs). Hashing definitely has value and plays a good role in blacklisting. For example, if there is a common public commodity malware that all the script kiddies are just grabbing off the internet and using to infect victims, you can hash that malware, toss the value into your AntiVirus tool, and it'll quarantine/detect that file and prevent it. So hashing is great for blacklisting those well known, seen before, popular variations of malware. It's also good for example if a specific malware has just attacked your network, and it's now spreading and you need to find our where is is, where it has been, etc. You'd hash the file and search your network for that hash value on shared drives, workstations, etc.
But you should know that hashing should not be trusted as your only method of blacklisting. Why? Because hashing gives a unique identifier for a specific variation/version of a file. But if any little thing in that file changes, such as a version number, a comment, the order of the code, the amount of white space, or the actual code itself, they will all generate a brand new totally different hash. Why does that matter? I'd like to show you a very simple example.
Let's say I'm a bad guy and just wrote some malware that I send out in phishing emails and if opened, drops a batch file on your c drive, messes with your notepad.exe , and executes the batch file.
Now if I were the AntiVirus signature writer, I found this malware in the wild, I'd hash the batch file ( 1b0679be72ad976ad5d491ad57a5eec0 ) , and every time any other victim executed this malware, the hash would be found, detected and quarantined. Great!
But if I were any sort of experienced malware write, I'd add at least 1 additional step. Instead of just messing with notepad.exe , I'd also make sure that my batch file is dynamic and looks different every time. How would I do that? One simple way would be to just add a random number in a comment to each batch file.
By doing so I have just guaranteed that every time my malware executes it generates a brand new unique Hash. Now adding the hash of the malware to the AntiVirus signature is no longer useful, because the hash will change every time it executes. Oops.
Now my example was written in C# and batch files, but please realize this concept could be applied to anything, including Powershell scripts, VBA Macros, executables, etc. It could also be applied to phishing email attachments (perhaps send out each attachment as a slightly modified versions, maybe linking the modification to the user's email address).
That's where Behavior Based detection, Hueristic Based detection, IoCs, etc. have started to come into play, because Hashes cannot be your only method of blacklisting.
Happy hunting.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)