I'm creating a script to detect weak passwords within a MySQL database. Which method would work the best?
I've been researching a few methods, but can't seem to decide which one would offer the best results with the best performance. I currently have the following methods in mind:
Extract passwords, and perform a dictionary attack on each.
Still extracting passwords, but to a file and use a tool like Hydra.
Perform a regex matching, that hits on basic passwords.
Please note that all passwords in the database is encrypted with a md5 hash.
Related
So I've been studying this concept of length extension attacks and there are few things that I noticed during my study about it which are not very bright to me.
1.Research papers are explaining how you can append some type of data to the end and make newly formed data. For example
Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege
(notice 2 waffles). My question is if a parser function on the server side can track duplicate attributes, could then the entire length extension attack be nonsense? Because the server would notice duplicate attributes. Is a proper parser that is made to check any duplicates a good solution versus length extension attacks? I'm aware of HMAC approach and other protections, but specifically talking just about parsers here now.
2.Research says that only vulnerable data is H(key|message). They claim that H(message|key) won't work for the attacker because we would have to append a new key (which we obviously don't know). My question is why would we have to append a new key? We don't do it when we are attacking H(key|message). Why can't we rely on the fact that we will pass the verification test (we would create the correct hash) and that if the parser tries to extract the key from it, that it would take the only key in the block we send out and resume from there? Why would we have to send 2 keys? Why doesn't attack against H(message|key) work?
My question is if a parser function on server side can track duplicate attributes, could then the entire length extension attack be a nonsense?
You are talking about a well-written parser. Writing software is hard and writing correct software is very hard.
In that example, you have seen an overwritten attribute. Are you able to say that a good parser must take the last one or the first one? What is the rule? There can be stations that the last one must be taken! That is an attack that can be applied or not. This depends on the station. If you consider that the knowledge of the length extension attack goes back to 1990s, then finding a place applicable to this should amaze someone!. And, it is applied in the wild to Flickr API in 2009, after almost 20 years;
Flickr's API Signature Forgery by Thai Duong and Juliano Rizzo Published on Sep. 28, 2009.
My question is why would we have to append new key? We don't do it when we are attacking H(key|message). Why can't we relay on the fact that we will pass verification test (we would create correct hash) and that if parser tries to extract key from it, that it would take the only key in the block we send out and resume from there. Why would we have to send 2 keys? Why doesnt attack against H(message|key) work?
The attack is a signature forgery. The key is not known to the attacker, but they can still forge new signatures. The new message and signature - extended hash - is sent to the server, then the server takes the key and appends it to the message to execute a canonical verification, that is; if it does the signature is valid.
The parser doesn't extract the key, it already knows the key. The point is that can you make sure that the data is really extended or not. The padding rule is simple, add 1 and fill many zeroes so that the last 64 (128) is the length encoding (very simplified, for example, the final length must be multiple of 512 for SHA256). To see that there is another padding inside you must check every block and then you may claim that there is an extension attack. Yes, you can do this, however, the one of aims of cryptography is to reduce the dependencies, too. If we can create a better signature that eliminates the checking then we suggest to left the others. This enables the software developers to write more secure implementation easily.
Why doesn't attack against H(message|key) work?
Simple, you get the extended message message|extended and send the extended hash
H(message|key|extended) to the server. Then the server takes the message message|extended and appends the key message|extended|key and hashes it H(message|extended|key) and clearly this is not equal to the extended one H(message|key|extended)
Note that the trimmed version of the SHA2 series like SHA-512/256 has resistance to length extension attacks. SHA3 is immune to it by design and that enables a simple KMAC signature scheme. Blake2 is also immune since it is designed with the HAIFA construction.
Every now and then I come across applications that force you to change passwords once in a while. Almost universally, they have this strange requirement for the new password: it has to be "significantly" different from your previous password(s).
While at first this sounds logical, next thing I think is: how do they do that? Do they store my passwords in plain text? I would have accepted the answer that they do, if it wasn't for the fact that these are kinds of applications that pretend to care about security so much they force you to change your password if it is expired! Microsoft Exchange is one example of this.
I'm not very good at cryptography and hash functions, so my question is this: Is it possible to enforce this kind of policy without storing passwords in plain text?
Do you know how this policy is implemented in real world applications?
UPDATE: An Example.
I was recently changing my Microsoft Exchange password. I only use Web Access, so it might be different a little -- I have no idea.
So, it forces me to change my password. What I do sometimes is I change it to something new and then change it back almost immediately. The freaky part is that It did not allow me to even change it back because of this. I tried changing it a little, by adding a letter in front of it or changing one symbol -- no luck, it was complaining.
With a typical hash, the best you can do is see if the new password is exactly equal to previous ones. You can break the password into multiple hashes in order to get more flexible with comparison, for example 3 hashes:
Alpha characters only
Numeric characters only
All other characters
You could for example require all the hashes to change to be accepted, to prevent users from just changing their password from SecretPassword01 to SecretPassword02.
A cryptographic expert may weigh in here on if this could be made as secure as a single hash.
NOTE that this is not as secure as a single hash, so before you go implementing this, make sure you have really done your research.
When changing password you're usually asked for the old one to confirm your identity. It's then trivial to compare the old one and the new one to see how much they differ. TBH I don't know how to compare to several previous passwords without storing them, but that's getting into the territory of ridiculous policies anyway.
I was thinking of an efficient way to add quarantining abilities to my antivirus application:
copy the file into a specified directory and change its extension to none (*.).
save the file's binary code in an XML database.
Which way is better?
However, I have no idea how I will recompile the binary code once the user wants to restore the file.
A way to do this is to encrypt the binary file using an encryption engine and moving it into a quarantine folder, you could create a random password and encrypt the file with that password and store it somewhere (that password could also be encrypted with a master key). That is probably the easiest way of quarantining. To unquaranine, just write the complete opposite of the quarantining code. Enumerate the files into a list and filter it out, then when the user clicks on an item and presses unquarantine, it calls the unquarantine function with the filepath as the variable.
If I had to do this (and again, I wouldn't want to be in this situation in the first place, per my comment), I would use an in-process database engine with native support for encryption and large-format binary data. I think sql compact or sqlite both fit this.
I would not use xml, because it's plain-text and the binary data could be easily extracted, and I would not just change the extension, because the file could still easily be executed. Neither are much of a quarantine.
Note that the renaming option is probably the most "efficient" of what I've seen discussed so far, but when dealing with security software correctness should always be your first concern over efficiency. There are times when you can compromise correctness for performance (3D game rendering software does this all the time, to great effect), but security software is not in this category.
What you can do is optimize later. For example, anti-virus engines use heuristics (rules of thumb that will only hold most of the time) to make their software faster, they do this in a way that favors false positives that must then be more-closely checked rather than potentially missing a threat. This only works because the code that more-closely checks each item was written and battle-tested first.
I'm thinking of hashing user passwords with two different salt strings, one stored in the code which is the same for all users and another stored in the database for which each user has their own unique value.
Would this be more effective than simply storing the values in the database?
Any advice, opinions appreiated.
Thanks
The effect is miniscule if anything at all. Consider that a static, hard coded salt can be viewed as nothing more than an alteration to the hashing algorithm - it happens exactly the same way every time, so it may as well be considered part of the algorithm.
But the purpose of the salt is to create some randomness that is similar to extending the (minimum) strength of the password, for the purpose of making offline cracking (including rainbow tables) more resource intensive (non-rainbow-table cracking will require more CPU time, and rainbow tables will require all salts for all strings).
The only way that you'd get any value from this is while the static salt is unknown - the equivalent to the algorithm being unknown. If your binary or your source is available to the attacker, then reverse engineering will demonstrate the algorithm and the hard coded salt.
And if this issue goes public, you will probably have to deal with flack from many security enthusiasts who believe that anything not perfect is completely broken, even though your product already does the right thing and the additional step is just useless.
And, of course, you'll have to deal with maintenance issues of having a static salt - backwards compatibility and bug fixes around the hashing code can be a pain.
The very small benefit of static keys (or salts) is simply not worth the cost. Always make keys and salts dynamic.
I need to provide some passwords, API keys and similar sensitive data in my code. What are best practices in that regard? Hard-coded? SQlite? Some cryptographic framework?
Like the others said, you can't both secure an API key and use it in your app. However, you can do simple obfuscation relatively easy and if the payoff to the cracker is low then you may not get burned.
One simple technique is to break your API key into several sub-strings. Make sure you put them in your code in some random order. For instance, if your API key is 12345678901234567890 you might break it up into 5 sub-strings like this:
static char *part1 = "12345";
static char *part5 = "7890";
static char *part3 = "890123";
static char *part2 = "67";
static char *part4 = "456";
If you run /usr/bin/strings on the resulting binary then you should not see the API key in order. Instead you'll see the API substrings in the order listed in your C file. With 5 substrings like this, that is 5*4*3*2*1=120 permutations. If you break it into 13 substrings you're looking at over 6 billion permutations.
However, that won't stop someone who knows what they're doing from getting your API key if they want it. Eventually you'll have to combine the strings together and pass it to one of your methods, at which point a cracker could use a debugger to set a breakpoint and inspect memory.
Use the Mac OS X Keychain:
Keychain Services Reference
Mac Dev Center: Security Overview
Update:
If your goal is to conceal information from your end users, then I'm not aware of a built-in way to do this.
Hard-coding is a start, but a user with a debugger can read the string out of your binary. To combat this, I've heard of developers that store the data as many separate strings and then combine them at the last minute. YMMV
You can use anyone of the posix compliant C cytographic libraries but as noted above anyone with the skills to crack your code can defeat the encryption by finding the key.
There are a few tricks you can use to slowdown a cracker: (1) Use gibberish names for classes, methods and variables to obscure the code handling encryption e.g. -(void) qwert asdf:(NSString *) lkj; (2) Put in duplicate routines and branches that don't actually do anything. (3) Hide data in unexpected place such as within images.
To add to the direct answers: It's all for naught if you don't use a secure method of transport, such as TLS or SSH. If you're sending the reconstituted API key in clear text, it's not hard for someone to use something like Wireshark or tcpdump (or, a bit more difficultly, a customized router) to capture it after it leaves your app.
If whatever API you're using doesn't offer a method of encrypted access, then there's nothing you can do about that (besides ask for one), but if it does, then you should use it.
You can not secure them. You can only try to hide them so it's not too obvious.
Security by obscurity that is. But I don't think there is a way to keep someone who is willing to get his hands dirty from finding them.