Jason Cooper

tor presents itself as a SOCKS proxy, so I would read up on using a SOCKS proxy from python.

Are they doing this via 802.1x? If so then you don't necessarily need to add your machine to the domain you as you may be able to use wpa supplicant to handle the authentication. You would still need to authenticate to the domain at some point though (unless your IT are allowing certificate authentication and give you a certificate for your machine)

The line for /f "skip=1 tokens=2 delims==." %%A in ('wmic os get lastbootuptime /format:value') do set BootTime=%%A is just to put the output of the wmic command into the BootTime environment variable, so the value of 20160104102930 is correct. You then nee to parse it. When you do set BOOTyear=%BootTime:~-4,4% set BOOTmonth=%BootTime:~-8,2% set BOOTday=%BootTime:~0,2% set BootTimeFin=%BOOTyear%%BOOTmonth%%BOOTday% you are setting BOOTyear to be the last 4 characters (2930) as you are asking it to start 4 characters from the end of the string and take the next 4 characters. You would want the -4 to be 0 to get the correct year. You are making the same sort of mistakes with BOOTmonth and BOOTday. Try converting it with the following set BOOTyear=%BootTime:~0,4% set BOOTmonth=%BootTime:~4,2% set BOOTday=%BootTime:~6,2% set BootTimeFin=%BOOTyear%%BOOTmonth%%BOOTday% If you want to get a better understanding of how substringing environment varaibles works in batch then try reading http://ss64.com/nt/syntax-substring.html

Try something like for /f "skip=1 tokens=2 delims==." %%A in ('wmic os get lastbootuptime /format:value') do set BootTime=%%A

As the other Cooper wanted to see more Perl the other day (Ok, he probably didn't want to see more, but as he mentioned it I have to provide some). #!/usr/bin/perl use strict; use warnings; use constant RANDOM_STRING_LENGTH => 17; my @alphabet = ('A' .. 'Z', 'a' .. 'z', 0..9); my $alphabetLength = scalar @alphabet; my $randomString = ""; for (my $i = 0; $i < RANDOM_STRING_LENGTH; $i++) { $randomString .= $alphabet[int(rand() * $alphabetLength)]; } print "$randomString\n";

Here is a C version. #include <stdio.h> #include <stdlib.h> #include <time.h> #define RANDOM_STRING_LENGTH 17 #define MAXIMUM_ALPHABET_LENGTH 255 int main(int argc, char** argv) { char alphabet[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"; char randomString[RANDOM_STRING_LENGTH + 1]; int i; int alphabetLength; alphabetLength = strnlen(alphabet, MAXIMUM_ALPHABET_LENGTH); srand(time(NULL)); for (i = 0; i < RANDOM_STRING_LENGTH; i++) { randomString[i] = alphabet[rand() % alphabetLength]; } randomString[i] = '\0'; printf("%s\n", randomString); return EXIT_SUCCESS; }

If you've got your program output from wmic in an environment variable (%X% in the example) then you can use something like: set lastBootUpTime="%X:~06,2%/%X:~4,2%/%X:~0,4% %X:~8,2%:%X:~10,2%"

Back in the day, when I was learning COBOL as part of course I was taking, the tutor told me that the menu system on course work was excellent. I didn't have the heart to tell him that the menu system wasn't implemented in COBOL and instead was just a batch file that then ran the relevant COBOL programs. Sure do, if you look at quite a few languages you'll find it (though they don't like to talk about it). The best thing about GOTO of course was the feeling you got when you discovered GOSUB and realized that you'd never need to use GOTO again.

From a nostalgia point of view, I like BASIC. It was were I started to learn programming, as it was the language the home computers at the time booted up into. I think that was part of the beauty of the language and also its curse. A lot of BASIC programs were people learning how to program. Hence the quality of the code was poor (go back an look at the early programs you wrote when learning to program and imagine if their quality was used to form an opinion of the language being used). While the quality of these programmers later code was generally a lot better, their later code was quite often Assembler not BASIC (you could do a lot in BASIC back then, but to get real speed you had to drop down to a lower level language). Quite a bit later, along came Visual Basic which was a chance to improve people's impressions of the language. Unfortunately it was presented to people as an easy way learn programming, except quite often you found that they didn't so much learn to program, as to draw forms and add components to them. Which resulted in a lot of people who thought they had mastered programming, when they hadn't, tarnishing the languages reputation again. I suspect that there are a lot of programmers out there like me who view BASIC as being where their journey started and look back on it fondly, but won't be choosing it for their next project.

No, "Secure Erase" is a command in the ATA protocol that will securely erase your ATA device. For old hard disks a single pass overwrite was good enough to remove data. But with modern SSDs a single overwrite won't get all the blocks in the device, as their wear leveling technology means that your most commonly used data will end up being left in the set of spare block on the device. The "Secure Erase" command, when used on an SSD, will simply set every bit in each block to 1 guaranteeing that everything is erased. This also has a performance benefit as your suggestion of setting everything to 0 means that the SSD would have to erase every block a second time when it next needed to write to it. A "Secure Erase" however, would leave all the bits at 1 which means that any value could be written to the block without having to erase it first.

It has been a while since I've needed to wipe a drive, but have you tried something like HDDerase that will use the secure erase command on ATA drives. Much faster than DBAN and should do a better job on SSDs (as DBAN will be caught out by their ware-leveling algorithms).

It could be that you're using the wrong quotes. The example you have in your post works, but if you're copying it by hand it's easy to use an apostrophe (') when it should be a back-tick (`). The good news is that in this case you don't need the quotes at all, you can simply use: CREATE TABLE counter (counter int(9) NOT NULL default 0); You'll also notice that I've dropped the TYPE parameter from the end of the line as MyISAM is usually the default engine type, you can check if this is the case in your MySQL instance with: SHOW ENGINES;

Look in your sql dump and see if it contains some "create database" statements? if not then you'll need to create the databases in MySQL before loading the dump. After that you should just be able to load it with the command line client Assuming that you want to load it as MySQL's root user then you'll want to use a command like this: (-u parameter is the user and -p indicates that you want to be prompted for a password). mysql -uroot -p < dumpfile.sql As to your original errors about not having enough space on your drive even though you were only using 11%, did you check how many inodes you had free? as running out of inodes can be reported as no space on the device in some situations. You can check your inode usage with df: df -i

Have you considered using MySQL's full-text search functions [https://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html]?

Have you looked at TFTP [Wikipedia entry, RFC]? It's a lot simpler that other file transfer protocols (which will make it slower), but there are plenty of standalone clients about.

Most password hashes stored in a database will be using a standard hashing algorithm (SHA-512, SHA-256, MD5, etc. Note MD5 should be considered a poor choice these days) and will either indicate it in the hash some how. for example in a Linux shadow passwd file hashes starting with $1$ are using MD5, those starting with $5$ are SHA-256 and those starting with $6$ are SHA-512. Failing the hashes indicating what they are then the next logical place to look would be the source code, finding the line that says hash=sha256(password+salt); is much easier and quicker than trying to figure it out from a plaintext/ciphertext comparisons. This leads onto the question of why would developers make it so easy for you to identify the hash being used, the answer is simply that it shouldn't matter that you know what type of hash is being used. The algorithm isn't the secret part, the password is. If the password it too simple or short then the hashing algorithm used is irrelevant as it will quickly be brute forced. On the other hand, if the password is long and complex enough then cracking it would take too long, even with knowledge of the hash, salt and and hashing algorithm. Once the need to keep the algorithm used secret is dismissed as worthless, then actually indicating the type of algorithm used gives the developers power to respond to issues that arise. E.g. If an algorithm is becoming a security concern then you can add a modern hashing algorithm to be used when setting new passwords and keep the old algorithm for verifying older accounts, effectively phasing out the old algorithm over time. You could even update the users hash to new algorithm then next time they successfully login.

"Always use parameterized queries" is high up on my list of good habits a programmer should have. Just like "Changing the sa account password on the database from the default" is high up on my list of good habits DBAs should have

(Note any figures in this post aren't exact, the're just approximations) That's correct. A plaintext and hash look up table can take up a lot of room as each hash will be 128bits (md5) or 256bits (sha256) in size. That would result in your look up table for md5 taking up about 50GB and the sha256 version taking up about 100GB. These days this sort of storage size id available on SSD's so you could create a very fast look up table your word list, now back when rainbow tables were popular storage space was a lot smaller, and 50GB was a significant amount of space to sacrifice for a simple look up table. Now consider what would happen if instead of just your word list you wanted to cover 90% of possible 8 character passwords consisting of numbers, uppercase and lowercase letters? Well for an md5 you'd be looking at 3,000TB or space requirement and for sha256 you'd need about 6,000TB, even with today's storage surplus we can't get near to that (government agencies probably have the resources, but your average technical person won't). With a rainbow table you can set your chain length to be something your computer can calculate in a set period, let's we can calculate a chain with a length of 1,000,000 in a minute, so we choose a chain length of 1,000,000. Now the rainbow table will only need to store an one entry for every 1,000,000 hashes. This brings our space requirements for md5 down to a tiny 3GB and sha256 down to 6GB at the expense of taking up to one minute per hash being cracked. The initial state is simply that when using a rainbow table to crack a hash you need to know what value to start your hash chain with. The wikipedia entry for rainbow tables is a good place to start. As to where to start, I would suggest that initially you look at creating a simple password hash pair lookup table and try it with subsets of your dictionary. Once you've got that done you have a good understanding of the limitations and then you can revisit rainbow tables.

To add to the other Cooper's answer, here's the basic theory of rainbow tables: Seed your current hash with a known value. for 1 to X { Store the current hash in the rainbow table for 1 to Y { Generate a password from the current hash Hash the password and set the result to be the current hash. } } Store the current hash in the rainbow table The X value controls the number of hash chains you want to include in your rainbow table and the Y value controls the lengths of those hash chains. To decrypt a hash with the final rainbow table you take the hash, generate a password from it and then calculate that password's hash. If this new hash isn't present in your rainbow table then repeat the process. Keep repeat untill you either get a hit in your rainbow table or you have repeated it more than Y times. If you've repeated the process more than Y times then you haven't got the password in your rainbow table. Assuming that you got a hit from your rainbow table then you simply take the previous entry to the one you found in your hash table and start the process of generating passwords from the hash, and then a hash from the password. As each hash is generated you compare it against the hash you want to decrypt and when you hit it you'll have the password that generated it. As you can see rainbow tables are very different to a precomputed hash value look up table. The rainbow table takes up less space but at the cost of having to do more calculations when decrypting a hash value. Now the real issue here is that both rainbow tables and a precomputed hash value look up table are only worth anything if the hash doesn't include salt (or only includes very small quantities of salt). A salt is simply a random value that is stored with the hash and used to alter the way the password is hashed (e.g. added to the end of the password before hashing). If a salt is used you would need to precompute every hash + salt combinations. Note every bit of salt added doubles the number of the hashes you would need to precompute and store, so even a small about of salt can render precomputation impractical. Are rainbow tables completely worthless these days? No, but once you've generated ones for the usual hashes without salts (md5, sha1, sha256, etc.) then you're done, and I suspect you will rarely use them.

Does it stay at 20 for wireless connections but drop down to 16 when monitoring, or does it also drop down to 16 when you're using it for normally? (I'm wondering if it is possible a setting in your crda settings, you may want to investigate that).

What happens if you try to set your txpower to 20 after starting wash? Does it allow you to increase the power or does it limit you back down to 16?

The script was only looking for interfaces whose name starts with wlan, so a mon interface wouldn't be caught. Try this slight tweak to the script, that'll set the txpower for an interface to 20 if its name starts with either wlan or mon. (note the additional line in the case block) #!/bin/sh # Set txpower to 20dbm for wlan0 # Note this is written from memory so will need debugging!! # catch all wlan and mon interfaces and set their txpower (if using bash you could # switch this to an if using [[ and wildcards). case "$IFACE" in "wlan"*) iwconfig $IFACE txpower 20 ;; "mon"*) iwconfig $IFACE txpower 20 ;; esac exit 0

Depending on when it is being reset to 16dbm you may find that you need to put it in a script that runs when you bring up your wireless interface. e.g. for Debian based distros putting the following in an executable script in your '/etc/network/if-up.d/' directory, or if you find you need to run it just before your interface comes up then put it in your '/etc/network/if-pre-up.d' directory. #!/bin/sh # Set txpower to 20dbm for wlan0 # Note this is written from memory so will need debugging!! # catch all wlan interfaces and set their txpower (if using bash you could # switch this to an if using [[ and wildcards). case "$IFACE" in "wlan"*) iwconfig $IFACE txpower 20 ;; esac exit 0

Simple Answer HTTP proxies proxy HTTP requests, while SOCKS proxies proxy socket connections. In a bit more detail A HTTP Proxy will only proxy connections that use the http protocol. A SOCKS proxy is operating at a lower level and so an application, which supports SOCKS proxying, can use it to proxy a connection. Tor uses SOCKS because it is opens up the range of applications that can use it (IRC, SSH, etc).

I wasn't suggesting it for every user, I was just pointing out that if you are worried about sites allowing weak versions of SSL/TLS then you can set your own minimum limit. you can use the "--cipher-suite-blacklist" parameter list the cipher suites you want to block (though I'll admit it ain't pretty and that you wouldn't want to use it if you can avoid it). The best way I can see to tackle this problem for public websites will be from a different angle. That being the major search engines adjusting their rank algorithms to take the site's protocols settings into account (e.g. Site X ranks higher than Site Y because it was limited to supporting had TLS1.1 and above, while Site Y still supported SSLv3). In fact Google started taking https into account in their rankings last August, so if they push this factor a bit harder we may see more sites moving to https and getting their encryption up to scratch.